Checklist
Specify what happens when the happy path cannot complete
If failure behavior is unspecified, the implementation will invent it.
When it fits
- Requirements describe successful behavior but leave invalid input, timeout, partial failure or recovery undefined.
When to avoid it
- Do not enumerate every imaginable failure. Prioritize credible and consequential modes using risk and operational evidence.
Checklist
- Invalid input
- Dependency unavailable
- Timeout or duplicate event
- Partial completion
- Retry/rollback rule
- Visible error or alert
- Recovery confirmation
Why it matters
List consequential failure conditions and define the required response: reject, retry, queue, rollback, preserve partial state, alert, ask for correction or degrade safely. Include what the user or operator can observe and how recovery is confirmed.
An example
A batch update requirement defines whether valid rows commit when one row fails and what reconciliation output identifies the rejected records.
Check your result
At least the important failure modes have an expected state and recovery path, not only an error message.
Keep this limit in mind
- Do not enumerate every imaginable failure. Prioritize credible and consequential modes using risk and operational evidence.
Evidence and sources
NASA's requirements checklist emphasizes clarity, one thought per requirement, completeness, explicit assumptions, consistency, traceability, feasibility and verifiability.
The checklist is for systems engineering; smaller tasks can apply the principles proportionally.
Appendix C: How to Write a Good Requirement · Requirements validation checklist
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