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.

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 with no parent is a hidden 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.

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. Examples here are illustrative.