Requirements definitions are the key to success in the design and development of any complex system.
The systems engineer needs to carefully elicit requirements from users and stakeholders to ensure the product will meet their needs.
The following provides a checklist to guide the collection and documentation of good systems requirements. It has been derived and reproduced with permission from the Requirements Experts.
Is each requirement…
Using the correct term?
Shall = requirement
Will = facts or declaration of purpose
Should = goal
Written in the
What format, using active rather than passive voice?
The system shall operate at a power level of…
The software shall acquire data from the…
The structure shall withstand loads of…
Using consistent terminology to refer to the product and its lower-level entities?
Free of typos, misspellings, and punctuation errors?
Compliant with the project's template and style rules, including page counts?
Is each requirement…
Clear and understandable?
Can only be understood one way?
Free from indefinite pronouns (e.g., this, these, it)?
Expressing only one thought per requirement statement?
Stated simply and concisely?
Stated positively as opposed to negatively (e.g.,
Located in the proper section of the document?
Defined at the correct level?
Are the requirements clear and unambiguous?
Can the requirement be misinterpreted?
Free of ambiguities? Examples of terms to avoid:
as appropriate …
but not limited to …
be able to …
be capable of.
Free of unverifiable terms? Examples of terms to avoid:
useable when required …
Free of implementation? Requirements should state WHAT is needed, not HOW to provide it (i.e., state the problem not the solution; ask,
Why do you need the requirement?).
Free of descriptions of operations? To distinguish between operations and requirements ask the questions: Does the developer have control over this? Is this a need the product must satisfy or an activity involving the product? Sentences like
The operator shall… are almost always operational statements, not requirements.
Free of To Be Determined (TBD) and To Be Resolved (TBR), values? Enter the current best estimate within brackets [value] in the requirement and state in the rationale why the value is still an estimate.
Complete with tolerances for qualitative values? Examples: less than greater than or equal to; plus or minus, 3 sigma root sum squares.
Accompanied by intelligible rationale, including any assumptions? Ask yourself: Can I validate, or do I concur, with the assumptions?
Traceable to requirements in the level above it? If it's at the top level, is it traceable to scope?
Identified with a verification method(s) (i.e., test, demonstration, analysis, or inspection)? Does a mean exist to measure its accomplishment? Can you state the criteria required for verification? Can compliance be verified?
Unique (as opposed to redundant)?
Consistent with other requirements (as opposed to conflicting)?
Are requirements stated as completely as possible? Have all incomplete requirements been captured [value]?
Have all assumptions been explicitly stated?
Are any requirements missing? Check for:
- environment (development, manufacturing, test, transport, storage, operations)
- facility (manufacturing, test, storage, operations)
- transportation (among areas for manufacturing, assembling, delivery points, within storage facilities, loading)
- appearance and physical characteristics
Are all requirements at the correct level (i.e., system, segment, element, subsystem) at which you are working?
Are requirements specified in an implementation-free way so as not to obscure the original requirements (i.e., do the requirements state
what and not
Are requirements specified on the product, not on an operator? Is this a requirement the developer has control over, something the product must do, or a quality it must have, rather than an activity involving the product?
Are the requirements stated consistently without contradicting themselves or the requirements of related systems?
Is the terminology consistent with the user and sponsor's terminology?
Is the terminology consistently used throughout the document?
Are the key terms included in the project's glossary?
Is each requirement needed? Is each requirement necessary to meet the parent requirement?
Is each requirement traced to a parent requirement?
Is allocation to the next lower level documented?
Is each requirement correct?
Are the requirements technically feasible?
Are all described functions necessary, and together, sufficient to meet the system needs, goals, and objectives?
Are all required performance specifications and margins listed (e.g., timing, throughput, storage size, latency, accuracy, and precision)?
Is each performance requirement realistic?
Are the tolerances overly tight? Are the tolerances defendable and cost-effective?
What is the worst thing that could happen if the tolerance was doubled or tripled?
Are all external interfaces clearly defined?
Are all internal interfaces clearly defined?
Are all interfaces necessary, sufficient, and consistent with each other?
Have the requirements for system maintainability been specified in a measurable, verifiable manner?
Are requirements written to be as weakly coupled as possible so that ripple effects from changes are minimized?
Are clearly defined, measurable, and verifiable reliability requirements specified?
Are there error detection, reporting, handling, and recovery requirements?
Are undesired events (e.g., single event upset, data loss or scrambling, operator error) considered and their required responses specified?
Have assumptions about the intended sequence of functions been stated?
Do these requirements adequately address the survivability after a software or hardware fault of the system from the point of view of hardware, software, operations personnel, and procedures?
Can the system be tested, demonstrated, inspected, or analyzed to show that it satisfies requirements?
Are the requirements stated precisely to facilitate specification of system test success criteria and requirements?
don't care conditions values explicitly stated? Correct identification of
don't care values may improve a design's portability.
Where applicable, are
don't care conditions truly
Don't care values identify cases when the value of a condition or flag is irrelevant, even though the value may be important for other cases.
For more information on writing good requirements, visit www.reqexperts.com.