The Requirements Mess

“Ray” has a good comment over at NASA Watch on the NASA Commercial Crew requirements:

Oh I just cannot wait for these requirements to finally see the light of day. I am going to have a field day with them (because, of course, any requirements the GOV levies on commercial enterprises are subject to public comment). Without even reading them, just based on Wayne’s words and my knowledge of existing substandard NASA requirements (current human rating requirements is but one example), I can tell they are going to be a bunch of unsubstantiable doo doo.

I am just getting warmed up, but here are the first two issues I have for these requirements mongers:

1) How many of these existing requirements are actually validated? And if so, what are the principles against which they are validated (I hope someone answers this with a CFR citation!)
2) For all those requirements in this set that are not yet validated (a viable situation), I would hope that NASA will clearly and unambiguously identify each and every validation plan for each and every requirement levied.

My specialty over the last 10 years of my career is going into troubled programs and laying waste to all their BS, unverifiable, or outright wrong requirements. The best way to prevent such problems like this from happening is following model-based systems engineering principles, which I am pretty sure NASA has not done in this case. If they actually did, then when they release the requirements for public comment, they should also be expected to release the fully coherent operational, functional, and physical architecture models. If they do not or cannot, then all they are doing is politics, not engineering.

I will take this task on as part of my duty as an American engineer to make sure NASA is NOT permitted to make these kinds of mistakes in systems engineering that they have made before. It is well understood by professionals in systems engineering that each “shall statement” has a dollar amount attached to it. Many contractors use this as a metric (e.g. so many dollars for each well-formed, substantiated, and traceable requirement). When requirements are found that are not verifiable, not measureable, not coherent, or not traceable, the “cost fudge factor” on those requirements is usually somewhere around 4-5x that of a well-formed requirement.

What we are seeing here is the EXACT same problem that DoD has. It is the single biggest problem that government, overall, has that causes over budget and blown schedule technology programs. If We The People let this happen without a whimper, we deserve what we get.

Actually, I would go further. In order to figure out what the “shall” statement is going to cost, you have to look at the verification statement(s). In the last few years of my own curmudgeonhood, I will no longer accept a requirement without one (or more, if necessary). Because in my experience, the verification statements are the foundation for a test plan, and that’s where the costs of a program can really balloon. A requirement without a verification statement has no value, and isn’t a real requirement. I would also add that when I was working CEV (before it became Orion), NASA had imposed some truly ridiculous requirements on it (e.g., it had to survive a bird strike at 10,000 feet).

5 thoughts on “The Requirements Mess”

  1. In the last few years of my own curmudgeonhood

    Few? May they be many! Or are you referring to retirement? I hope that doesn’t mean we’ll have to miss out on the biting commentary.

  2. Hey, a Buzzard loping along in the cold air at Angels 10 just tryiing to cool off from the Florida heat, just minding it’s own business and BLAMMO!!!!

  3. If a requirement isn’t real (guessing yes from the discussion of cost) is it still an imposition?

    You still have to document that you comply with the requirement.

Comments are closed.