The requirements traceability matrix has a bad reputation, and it is earned. In most organisations it is a spreadsheet built for an audit, accurate on the day it was made, stale by the following week, and consulted by nobody who is actually delivering anything.
That is a failure of implementation, not of the idea. The idea answers questions teams ask constantly and usually answer by guessing.
The questions it exists to answer
- Is this requirement tested at all? Not how many tests exist, but whether any of them verify this specific agreed behaviour.
- If this requirement changes, what breaks? Which stories, tests, and defects are now describing something that is no longer true.
- This test failed. What does it cost us? Which requirement is at risk, and is it one that matters.
- Can we release? Which agreed criteria have passing evidence and which have none.
Every one of those gets asked in a normal week. Without traceability they are answered from memory, and memory is confidently wrong at exactly the moments it matters.
What to link
The temptation is to link everything to everything. Resist it: a matrix with too many relationships is unreadable, and unreadable is functionally the same as absent.
The chain that carries the most information is short:
- Requirement to acceptance criterion. The agreed contract, broken into checkable statements.
- Acceptance criterion to test case. The evidence that the criterion holds. This link is the one most often missing, and its absence is what lets a project report full coverage while leaving agreed behaviour unverified.
- Test case to execution result. Evidence with a date. A test that exists but has never run proves nothing.
- Execution result to defect. What failed and what is being done about it.
Four links. From any point you can walk in either direction, which is what makes the four questions above answerable.
Requirement to test is common. Acceptance criterion to test is rare, and it is the one that matters. A requirement with three tests can still have two of its five agreed criteria completely unverified, and only the finer link reveals that.
Coverage that means something
Once the chain exists, coverage stops being a single number and becomes a set of questions with different answers.
| Measure | What it tells you | Worth reporting? |
|---|---|---|
| Requirements with any test | Whether anything is completely unverified | As a floor, yes |
| Acceptance criteria with a mapped test | Whether the agreed contract is verified | This is the real number |
| Criteria with a passing recent result | Whether the evidence is current | Yes, near release |
| Test count | Volume of work | No |
Reporting test count as coverage is the most common way a green dashboard hides an untested critical path.
Why it dies, and how to stop it
Traceability matrices die for one reason: maintaining them is separate work whose benefit lands on somebody else, later. Under deadline pressure that combination loses every time.
There are only two durable fixes. The first is to generate the links as a by-product of doing the work, so that writing a test against a criterion creates the link rather than requiring a second step. The second is to make the matrix the thing people actually use to answer the four questions, so that letting it rot has an immediate cost to the person letting it rot.
A matrix maintained solely for an auditor will be maintained solely before an audit. That is not a moral failing, it is an incentive structure.
Key takeaways
- Four links carry most of the value: requirement, criterion, test, result, defect.
- Criterion-level linking is what reveals unverified agreed behaviour, requirement-level linking hides it.
- Test count is not coverage and reporting it as coverage conceals risk.
- A matrix maintained as separate work will not survive the first deadline.
A reasonable starting point
If you have nothing today, do not begin by retrofitting the whole backlog. Take the next requirement that enters development and trace only that one, properly, all four links. Then the next.
Within a few iterations you will have live traceability on the work that is actually moving, which is the work the questions get asked about. Retrofitting history is almost always wasted effort, because nobody asks the four questions about requirements that shipped last year.