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.
How to create a requirements traceability matrix
Build it one requirement at a time, in the order the work happens.
- List the requirement and its acceptance criteria. Give every criterion a stable ID, such as ac-1, so tests and results can point at it.
- Map each test case to the criterion it is designed to test. One row per case and criterion. A case that tests two criteria gets two rows.
- Add a row for every gap. Agreed behaviour with no test case, and open questions with no criterion yet, get their own rows with no case. These rows are the point of the matrix.
- Record where each mapping came from. Rows exported from a tool and rows assembled by hand deserve different levels of trust.
- Record results only after a run. Enter the status, the date and where the evidence lives. Until a case has run, it stays not executed, whatever the plan says.
- Link failures to defects. A failed result gets a defect ID and a status, so the matrix shows what is at risk and what is being done about it.
Then read coverage in two layers: planned coverage, meaning a criterion has a mapped test, and executed coverage, meaning it has a recorded result. The gap between the two is what a release decision needs to see.
A free RTM template with a worked example
Requirements traceability matrix template (Excel), pre-filled with the refund example used across the Academy guides. It includes the matrix, a coverage summary calculated by formulas, instructions for completing it, and 30 empty rows for your own requirements.
The example is illustrative, and the workbook says exactly where each value comes from:
- Exported from ReqLens. Test case IDs, titles, types, priorities and criterion links are copied verbatim from the TestCraft export of the 12 approved refund cases. Those cases were reviewed by an AI assistant for a demonstration, not by a person.
- Summarised. Criterion descriptions are summaries of the elaborated requirement, not its verbatim text.
- Manually assembled. Three open-gap rows, for partial refunds, concurrent requests and payment gateway timeouts, were transcribed by hand from the gaps ReqLens flagged. No criterion or test exists for them yet.
- Not executed. No tests were run, so every result reads "Not executed" and every defect reads "Not recorded". The template contains no real passes, failures or defects.
A few rows from the matrix:
| Criterion | Test case | Type | Mapping source | Execution | Defect |
|---|---|---|---|---|---|
| ac-1 | TC-001 Verify customer can initiate refund for eligible card payment within 30 days | Happy Path | Exported from ReqLens | Not executed | Not recorded |
| ac-1 | TC-013 Verify system rejection of refund request for orders outside the 30-day window | Boundary | Exported from ReqLens | Not executed | Not recorded |
| ac-4 | TC-014 Verify refund request for amount exactly at approval threshold | Boundary | Exported from ReqLens | Not executed | Not recorded |
| Open gap | None: behaviour when the payment gateway times out is not defined | Manually assembled | Not executed | Not recorded |
In the coverage summary every criterion shows planned coverage and none shows executed coverage. That is an honest picture of a suite that has been designed but not yet run, and exactly the distinction a single coverage percentage hides.
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 criteria have planned test coverage | 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. The first of those questions to come up is usually what a requirement change affects; see requirements change impact analysis.
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.
To see how ReqLens keeps these links as the work happens, read about requirements traceability in ReqLens, or see how the AI test case generator links each generated case to the criterion it is designed to test.