Question
Trace every costly requirement back to the need it protects
Traceability is a reason chain, not a spreadsheet decoration.
When it fits
- A requirement adds complexity, performance cost or schedule risk and its necessity is defended mainly by history.
When to avoid it
- Not every low-level engineering constraint maps neatly to a user story; architecture, safety and legal parents are legitimate.
A question to ask
Which need or constraint requires this? · What is the worst credible consequence if we remove it? · Could a weaker requirement still protect the need?
Why it matters
Ask which higher-level need, user outcome, constraint or risk requires the statement and what would happen if it were removed or relaxed. Record that parent. Requirements without a defensible parent become candidates for deletion, downgrade to preference or further discovery.
An example
A strict retention rule is traced to a regulatory obligation; a separate seven-year internal copy turns out to be historical preference and is reconsidered.
Check your result
The requirement has a named parent need or an explicit decision to treat it as a preference rather than a must.
Keep this limit in mind
- Not every low-level engineering constraint maps neatly to a user story; architecture, safety and legal parents are legitimate.
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