Protocol
Choose the verification method while the requirement is still editable
A requirement that cannot be verified cheaply enough may be badly shaped for the project.
When it fits
- A requirement looks precise on paper but nobody knows how compliance will actually be shown.
When to avoid it
- Verification planning does not guarantee the criterion represents real user value; validation of the underlying need is separate.
Why it matters
For each important requirement, decide whether evidence will come from test, demonstration, inspection, analysis or another defined method. Identify needed environment, data and threshold. If verification is impossible or disproportionate, rewrite the requirement or surface the cost before build.
Steps
- The project can describe how a reviewer will decide pass/fail and what evidence will be retained.
An example
A throughput requirement is tied to a load test with a reference dataset and clear percentile threshold instead of the phrase 'handles peak volume.'
Check your result
The project can describe how a reviewer will decide pass/fail and what evidence will be retained.
Keep this limit in mind
- Verification planning does not guarantee the criterion represents real user value; validation of the underlying need is separate.
Evidence and sources
NASA guidance warns against unverifiable terms such as easy, fast, adequate or user-friendly unless they are translated into criteria that can be tested, demonstrated, inspected or analyzed.
Qualitative goals can still be useful during discovery when they are explicitly treated as goals rather than acceptance requirements.
Appendix C: How to Write a Good Requirement · Verifiability/Testability
NASA recommends identifying a verification approach for requirements and keeping each requirement uniquely identifiable with a definitive source.
The appropriate verification method and documentation depth depend on risk and project scale.
Appendix D: Requirements Verification Matrix · Requirements Verification Matrix