Template
Trace a requirement to the reason and test that justify it
A requirement number is an address, not an explanation.
When it fits
- A requested change has unclear value, or nobody knows what will be affected if it changes.
When to avoid it
- A missing parent does not automatically make a derived requirement unnecessary. Review the rationale; a perfectly linked chain can still contain a mistaken assumption.
A template to use
Need or derived rationale: [reason]. Requirement: [requirement]. Design response: [design]. Verification evidence: [test]. Affected links if changed: [impact].
Why it matters
Connect the requirement to its parent need, design response and verification evidence. Read the chain in both directions: why does this feature exist, and how will this need be checked? Maintain the links when requirements change instead of keeping a traceability table that describes an earlier project.
An example
A reconciliation report traces to the need to detect missing relationships, a defined comparison rule and test cases containing deliberate omissions.
Check your result
A reviewer can move from the need to its test and back without an unexplained link.
Keep this limit in mind
- A missing parent does not automatically make a derived requirement unnecessary. Review the rationale; a perfectly linked chain can still contain a mistaken assumption.
Connected ideas
Useful withCheck that it meets the specification and solves the real problem
Evidence and sources
Requirements traceability links stakeholder expectations, requirements, design and verification artifacts so relationships and change impacts can be examined.
A link records an asserted relationship; it does not prove that the rationale is sound or the requirement is complete.
6.2 Requirements Management · Sections 6.2.1.2.2 through 6.2.1.2.4