This past week I have been reviewing the NASA Systems Engineering Handbook.  As I read through it I was struck by their description of the requirements writing process.  With this post, I will share a few thoughts.

Requirement inputs

In the diagram that follows they call out four inputs to the requirements writing process.  Two out of the four are frequently missed in the development of requirements. “Baseline enabling support strategies” and “Measure of effectiveness”

From the NASA document:

Baselined Enabling Support Strategies: These describe the enabling products that were identified in the Stakeholder Expectations Definition Process as needed to develop, test, produce, operate, or dispose of the end product. They also include descriptions of how the end product will be supported throughout the life cycle.

What makes this unique?  By looking at the enabling products it expands the requirement writing to the system level.  E.g. the requirement is not an individual part, it can leverage existing infrastructure.

Measures of Effectiveness: These MOEs were identified during the Stakeholder Expectations Definition Process as measures that the stakeholders deemed necessary to meet in order for the project to be considered a success (i.e., to meet success criteria).

What makes this unique?  Writing test criteria is standard for requirements (or at least it should be.)  What is unique is explicitly calling out the stakeholder requirements of success in a defined and agreed upon document.  Note, the stakeholder requirements are not how the requirement document will present the requirements.

Requirement metadata

The metadata associated with requirements is often overlooked (or ignored in the  tools that support it.)  The intent behind the metadata is to

1. Make maintenance easier
2. Support traceability
3. Support project planning

The table above provides insight in how the objectives can be met.  First, by providing ownership information it supports the maintenance objective by removing the question of whom to contact when there are questions on the requirements.  Second, traceability is explicitly called out in this table.

Finally the project planning aspect.  In explicitly specifying the verification method, lean and level better estimates of the time required for validation can be assigned.

Validation of requirements

The final aspect I want to comment on, though the whole document is worth reading, is the validation of requirements

The NASA document defines 6 aspects for validating the requirements.  What is significant is that they explicitly defining validation of requirements as a step in the development process.  Multiple times in this Model-Based Design blog I have stressed the importance of using simulation to quickly detect design errors.  However, no amount of simulation can find an error if the requirements are not correctly defined.

Final thoughts

Go take a look at the NASA systems engineering document.  It is well worth the read.