Requirements traceability matrix: what it is and how to build one
A requirements traceability matrix maps each requirement to its tests, results and defects. The columns to include, a worked example and how to keep it current.
A requirements traceability matrix (RTM) is a table that maps every requirement to the test cases that verify it, the latest result of each test and any open defects. It answers two questions before a release: is every requirement tested, and is every tested requirement passing?
Why traceability matters
Testing produces a lot of results, but stakeholders ask about requirements: Can customers sign in with biometrics? Are transfer limits enforced? A requirements traceability matrix (RTM) translates one into the other. It is also the first document auditors ask for in regulated industries, because it proves that every stated requirement was verified.
The columns to include
| Column | Example | Purpose |
|---|---|---|
| Requirement ID | MOB-R4 |
Stable reference used everywhere |
| External ID | MB-201 |
The ticket in your product tracker |
| Requirement | Transfers respect limits and require confirmation | What was promised |
| Linked test cases | MOB-C21, MOB-C22, MOB-C25 |
Forward traceability |
| Latest results | Pass, Fail, Pass | Evidence from the most recent execution |
| Status | Failing | One verdict per requirement |
| Open defects | MOB-BUG2 |
What blocks it |
A worked example
| Requirement | Cases | Latest results | Status |
|---|---|---|---|
| New customers can open an account in under five minutes | 4 | all passed | Passing |
| Identity is verified before the first transfer | 4 | 1 failed | Failing |
| Customers can dispute a transaction | 0 | – | Not covered |
| Statements are available for seven years | 4 | 2 passed, 2 untested | Partial |
Reading it takes seconds: one requirement is safe, one is broken, one was never tested and one is half-verified.
How to derive a requirement’s status
Use rules simple enough to explain in a meeting. These are the rules TestPlum uses:
- Not covered: the requirement has no linked test cases.
- Failing: any linked case’s latest result is failed or blocked.
- Passing: every linked case’s latest result is passed.
- Partial: some linked cases passed, none failed, some are not yet executed.
- Untested: linked cases exist but none has a result.
“Latest result” matters: a case that failed last week and passes today should count as passing.
Coverage is not the same as quality
Requirement coverage is the share of requirements with at least one linked test. In the example above, three of four requirements are covered: 75%. That says nothing about whether they work; only one of the four is actually passing. Report coverage and status side by side.
Find the orphans
Traceability works in both directions:
- Forward: requirement → tests → results. Finds requirements nobody tests.
- Backward: test → requirement. Finds tests that verify nothing, which are either missing a link or no longer needed.
Both kinds of orphan are worth a review before every major release.
Keeping an RTM current
A spreadsheet RTM is out of date the moment someone records a result. To keep it trustworthy:
- Link tests to requirements in the test management tool, not in a separate document.
- Compute status from recorded results, never by hand.
- Use the requirement’s external ID so it can be matched to your product tracker.
- Export or print the matrix for sign-off rather than maintaining a copy.
TestPlum builds the matrix from live data, flags orphans and exports it to CSV. See requirements and traceability, or the release readiness checklist that uses requirement status as one of its checks.
Frequently asked questions
What columns should a requirements traceability matrix have?
At minimum: requirement ID, requirement summary, linked test case IDs, the latest result of each test, the requirement's overall status and open defects. Many teams add priority, owner and the external ticket ID.
What is forward and backward traceability?
Forward traceability follows a requirement to its tests and results, proving it was verified. Backward traceability follows a test or defect back to the requirement it belongs to, which reveals tests that verify nothing.
How do you calculate requirement coverage?
Divide the number of requirements with at least one linked test case by the total number of requirements. Coverage shows what is tested at all; requirement status shows whether those tests pass.