Inaugural post to this blog - Requirements 101

For maximum "auspiciousness", I'm typing these words at the stroke of midnight. Anyway, I want to welcome anyone with the temerity to find this post. What I plan to comment on and make note of (over time,; not all tonight!) are some common lessons learned in my systems integration work for various clients in different industries.

Originally, systems integration seemed to be the almost exclusive domain of heavy duty, capital-intensive programs in aerospace and defense. The Polaris and Minuteman missile systems come to mind. But if you look for it, you'll find (or at least will be painfully aware of its absence) the fundamental systems engineering & integration discipline across the board in projects large and not so large. So the bottom line is we've been at this for quite a long time and a reasonable person might expect that we're pretty good at it by now.

Well, I don't see that to be true. Just last week I was confronted with an ever expanding set of requirements for a back-up gas turbine powered electrical generator set. Some of these struck my as being pretty ad hoc and nebulous. In the interest of diplomacy (peace and harmony is in very short supply in this world lately), I thought to approach my concerns with my client a bit obliquely. Rather than jump into a debate/monologue about parent/child/orphan requirements (which we can talk about here in more length at a future time if comments indicate any interest exists), I asked a very simple question. Pointing to one requirement statement, I asked, "And how should we be looking to verify that we've satisfied this one?" Without much hemming and hawing even, the conclusion was that the requirement was impossible to verify in sort of a objective, quantitative sense. And here is the lesson learned for this evening:

If a requirement can't be verified by any of the usual and customary methods; i.e., inspection, test, demonstration or similarity, then really by definition it is not a true requirement. So, if we run into a "desirement" like, "The generator set shall spring to life with an authoritative yet mellow roar that reinforces the self esteem of the entire operating shift", we know some remedial work is in order.

A handy method I enforce to force the issue with such counterfeit requirements is to have everyone use an Excel spreadsheet as a pre-screen/entry form. It has fields for the requirement title and description, whether it is a parent or child, if it is explicit or derived, and what the proposed verification method is. The notes field can even capture pass/fail criteria if one is in a position for that sought of foresight. If you can't answer those questions pretty succinctly, reassess your requirement. Don't be surprised to discover that it's not a requirement at all, or perhaps is two, or three, or five rolled into one.

Failure to invest time to get the requirements picture straight, well documented, and agreed to by all the pertinent stakeholders is a prescription for long-term suffering, disappointed and angry customers, big cost surprises, bigger award fee shortfalls, and a bad reputation.

This is yet another systems integration task where doing it "the hard way" is really the easiest way to get the job done.

Tomorrow, I'll comment on the impact of the loss of NASA's Glory satellite due to a problem with the Orbital Sciences booster system on the overall status of commercial spaceflight.

A good night to all.