Late in a project, someone asks: "Why does the system do that?" The question is usually asked by an auditor, a regulator, a new team member, or a senior stakeholder reviewing a completed implementation. The answer, if it exists, lives somewhere in a chain that runs from the original business need through a documented requirement through a design decision through a test case through a deployed feature. If any link in that chain is missing or undocumented, the answer is "we're not sure," which is not the answer anyone wanted and is not the answer the context requires.
Requirements traceability is the discipline of making that chain explicit and maintaining it through the life of the project. The artifact that records it is the Requirements Traceability Matrix (RTM). Like most BA tools, it gets dismissed as overhead until the moment it becomes essential, at which point the cost of not having it is much higher than the cost of building it would have been.
What a traceability matrix actually is
A Requirements Traceability Matrix is a table that links each requirement to every artifact downstream of it: the design element that implements it, the test case that verifies it, and the deployed feature that delivers it. It also links upstream: each requirement traces back to the business need or regulatory mandate that originated it.
The minimum viable version has five columns:
| Requirement ID | Requirement description | Business need | Test case(s) | Status |
|---|---|---|---|---|
| REQ-014 | System shall log all data export events with timestamp, user ID, and record count | GDPR Article 30 audit trail obligation | TC-031, TC-032 | Implemented, verified |
| REQ-015 | Export logs shall be retained for a minimum of 24 months | GDPR Article 30 audit trail obligation | TC-033 | Implemented, verified |
| REQ-019 | System shall notify the data controller within 72 hours of a detected breach | GDPR Article 33 breach notification obligation | TC-041 | In development |
A more complete version adds columns for the design decision that implements the requirement, the sprint or release that delivered it, and any change history (the original requirement and what changed it). The right level of detail depends on the project's compliance context, the likely audit demands, and the team's capacity to maintain the document. A RTM nobody updates is worse than no RTM: it becomes a false record.
The two failure modes it catches
Traceability is most useful not as a filing exercise but as a diagnostic: it surfaces two classes of problem that are expensive to discover any other way.
Scope creep without a requirement. A feature appears in the deployed system with no corresponding requirement in the RTM. This is scope creep, precisely: work that entered the project through a channel that bypassed requirements management. It isn't necessarily the wrong work. The feature may be genuinely necessary. But it wasn't analyzed, approved, tested against acceptance criteria derived from a requirement, or authorized as a change. If an auditor asks where it came from, the answer is "someone built it" rather than "here is the business need, the authorization, and the test." That gap has consequences in regulated environments, and it has consequences for project budget accountability in any environment.
Orphaned requirements. A requirement in the RTM has no corresponding test case, no corresponding deployed feature, and a status that doesn't explain why. This is a requirement that was agreed upon by the business and never delivered. The stakeholder who asked for it may have moved on, may have forgotten it, or may be about to ask why it isn't in the system. Orphaned requirements surface contractual gaps and scope omissions before they surface as complaints.
Traceability as change control
The RTM is not a document you build once and file. Its value comes from maintaining it through the project's change process. When a requirement changes, the change is reflected in the matrix: the original text is preserved (or accessible through version history), the change is dated, the reason is noted, and the downstream artifacts that are now out of date are flagged for review.
A requirement that changes without updating the RTM disconnects the chain. The test case that was written against the original requirement may now be testing something that no longer matches the specification. The design decision that implemented the original requirement may need to be revisited. If the matrix doesn't record the change, those disconnections are invisible until someone runs the test (and gets a result that doesn't match the system) or the audit (and finds a test case proving something the requirement no longer says).
The column I always add
Beyond the minimum five columns, the addition that earns its space most consistently is an evidence reference: a pointer to the artifact that proves the requirement was verified. Not just a test case ID, but a reference to the test execution record: the run date, the result, and where the evidence lives. A test case that was written but never run is not evidence of verification. A test case linked to a run record with a pass result is.
In compliance-driven environments (financial services, healthcare, public sector), the evidence reference is not optional: regulators and auditors are not interested in your test case. They are interested in the record that shows the test case was executed, against what version of the system, on what date, with what outcome, and who approved the result. The RTM that carries those references turns a compliance audit from a document retrieval exercise into a review of a complete, indexed record.
Traceability in agile contexts
A common objection to traceability in agile projects is that the overhead conflicts with the iteration speed the methodology is designed to enable. The objection has some merit when taken to extremes: a full formal RTM updated in every sprint planning session would be friction without proportionate benefit for a small team doing exploratory product work.
But traceability and agility are not inherently incompatible. The minimum viable version of traceability in an agile context is the link between user stories and test cases: each story has acceptance criteria, each criterion maps to one or more test cases, and the test cases are run against the story before it is accepted. That chain (business need, story, acceptance criterion, test case, verified delivery) is a lightweight traceability record that provides the core benefit without the ceremony of a formal matrix.
The question is not whether to trace requirements but how much formality the project context justifies. A system handling financial transactions in a regulated market requires a full RTM with evidence references and change history. A startup's internal analytics tool probably doesn't. The scaling factor is not the methodology: it's the audit exposure, the compliance obligations, and the consequences of being unable to explain why the system does what it does.
The day someone asks where a feature came from is not the day to start building the chain. It's the day to open the matrix and point.