Aerospace Systems Engineer

2003

Structured Requirements Writing

Structured Requirements Writing

Michael J LaRue

My rationale begins with the working definition that I have adopted for word “requirement’ as it pertains to system specification.


Paraphrased from DeMarco (Structured Methodologies, Yourdon Press) - A requirement is a mandatory testable attribute of a system that must be implementable and testable. The ideal form of a requirement is “Upon INPUT or TRIGGER, the system shall STRONG VERB resulting in OUTPUT (must be testable, an “on flag” or “SOME VALUE IN SOME UNITS&rdquoWinking or OBSERVABLE BEHAVIORAL RESPONSE under STATED CONDITIONS (as needed).” Furthermore the requirement should be clear, readable and unambiguous, and preferably written in a structured syntax such as Structured English. Structured English is defined in the DeMarco book, but I have pretty much paraphrased it here.


Ultimately a requirement represents the establishment of a test point that will be a measure of acceptability of the system being delivered. There is no value to testing to a capability - the system either demonstrates the behavior when the prompting conditions are met or it does not.


The phrase shall be capable of fails in that it is not a strong verb, it detracts from clarity and ultimately does nothing to enhance testability. How do you test a capability? I think it is unproductive to test for a capability. Why not just specify the mandatory, testable behavior that must occur, and be clear about when (under what conditions) the BENAVIOR or OUTPUT must be manifest?


The challenge of systems engineering is to clearly capture the mandatory behaviors and outputs and to be clear about stating the associated conditions.