Traceability

Requirements traceability is the ability to follow a requirement backward to the need or constraint it serves and forward to the design choices, tests, and evidence that address it. NASA’s requirement-writing checklist asks that each requirement be uniquely referenced, bidirectionally traceable, and accompanied by an intelligible rationale including its assumptions.

One requirement, followed both ways

Take a branch-isolation requirement for an invoice lookup. Backward, it traces to the need that clerks see only permitted records and to the organization’s access policy. Forward, it traces to tests on the search screen, direct record lookup, export, cached answers, and error messages, each with a pass or fail result, and to the security owner who judges them. If the access policy changes, the affected tests can be found; if a test fails, the need it protects is visible.

NASA’s checklist connects requirements to higher-level requirements or the agreed mission or system scope. Bidirectional traceability means being able to follow a relationship in either direction. It does not require people to enter the relationship twice: a tool can store a parent–child relation once and derive both the parent’s children and the child’s parent. People still have to establish and review whether that relation is meaningful. Reverse navigation then helps identify what a changed requirement could affect.

Stable identifiers let other documents refer to a requirement unambiguously. NASA also calls for an intelligible rationale and explicit assumptions. The link identifies the source or parent; the rationale explains why this requirement follows from it and under what conditions it applies. Both are needed when later readers assess a change.

An identifier such as “R3” is a label inside one document that makes those links easy to write down. The label proves nothing about the requirement’s correctness; the links and the evidence do the work.

What traceability exposes

A requirement without an explicit parent needs an explanation, not automatic rejection. It may follow from the agreed scope, a design decision, or established practice. NASA recognizes self-derived requirements and calls for concurrence at the appropriate higher level. Record the derivation, assumptions, and approval so that it can be distinguished from an unsupported preference or a gap in the need statement. A requirement with no test or evidence is in the unknown state, however confident the sentence sounds. When a requirement changes, the record shows why, who approved it, and which candidate options and tests are affected, so a relaxed condition cannot slip in unnoticed after results are seen. Where the change is architectural, that record is an architecture decision record.

The same word is used for a different idea in data work: data lineage traces where a dataset came from and how it was transformed. Requirements traceability links statements of need to evidence about a solution. Both answer “where did this come from?”, about different objects.

References:

• NASA: How to write a good requirement
• NASA: Technical requirements definition
• NASA, Requirements Management