Requirements Traceability Matrix: Tracing from Requirements to Test Cases
The Requirements Traceability Matrix (RTM) is one of the most underrated — and most often abandoned — deliverables in requirements analysis. The IIBA BABOK treats requirement tracing as a core business analysis practice. It answers one simple but important question: is every requirement actually implemented, verified, and easy to locate when a change happens?
What is a Requirements Traceability Matrix
At its core, the RTM is a two-dimensional table that maps requirements to downstream artifacts. The most common mapping chain is:
Business requirements → Functional requirements → Design/technical solution → Test cases → Acceptance results
It provides traceability in two directions:
- Forward traceability: starting from a requirement, confirm it is covered by design and by tests. It answers "was this requirement built and tested?"
- Backward traceability: starting from a test case or defect, find which requirement it relates to. It answers "what is this test actually verifying?"
When both directions exist, you get what BABOK calls completeness checking: no unimplemented requirements, and no test cases without a source.
Typical RTM columns
A practical RTM does not need to be complex. At minimum it should include:
| Column | Description |
|---|---|
| Requirement ID | Globally unique number, e.g. REQ-001 |
| Description | One-line summary of the requirement |
| Source | Interview, survey, PRD, or change request |
| Priority | Matches your requirement prioritization frameworks |
| Design/implementation | Module, interface, or design document |
| Test case ID | The cases covering this requirement |
| Test result | Pass / Fail / Blocked |
| Status | Not started, implemented, verified |
For site-building and SaaS teams, use numeric IDs such as REQ-001 instead of long titles, so they are easy to reference in test reports, defect tickets, and commit messages.
A Filled-in Example
Columns are clearer with a concrete example — a simplified login-and-payment scenario:
| Requirement ID | Description | Source | Priority | Design/Implementation | Test Case ID | Result | Status |
|---|---|---|---|---|---|---|---|
| REQ-001 | User can log in with email + password | PRD v1.2 | High | auth-service /login | TC-001, TC-002 | Pass | Implemented |
| REQ-002 | Support third-party WeChat QR login | Interview | Medium | auth-service OAuth | TC-003 | Pass | Implemented |
| REQ-003 | Unauthenticated users cannot access orders page | Security review | High | middleware auth | TC-004, TC-005 | Fail | Implemented |
| REQ-004 | Refunds allowed within 24h after payment | Change request CR-08 | Medium | order-service | TBD | Not run | In progress |
Note that REQ-003 shows a failing test and REQ-004 has empty test cases — those two rows are exactly what a review meeting should discuss. Filtering out empty cells and failures gives you a ready-made risk list.
How to build an RTM
- Start from your requirements list. Number every requirement in your PRD or backlog and add it to the matrix.
- Fill in the implementation column during design. Every time a module design is done, go back and mark the requirements it covers.
- Bind test cases to requirement IDs. Each case should trace to at least one requirement — the same idea as user stories and acceptance criteria: acceptance criteria define the verifiable boundary of a requirement.
- Review empty cells at checkpoints. Any requirement with no design or no test cases is either not done yet or a hidden risk.
Value for change management and regression testing
The RTM is most valuable when requirements change. When a stakeholder requests a change, the matrix answers three questions quickly:
- Which design modules are affected?
- Which existing test cases need regression?
- Does the change conflict with other requirements?
Combined with requirements change management, this reduces the risk of "fix one thing, break another." In the AI era you can turn key requirements into automated checks with an evaluation dataset, so the "test result" column becomes a continuously running check instead of manual entry.
A concrete example: suppose the business asks to change "refunds within 24 hours of payment" to "refunds within 7 days." Against the matrix, you spot within seconds that it affects the refund module in order-service, the four cases TC-007 through TC-010, and the content requirement behind the homepage refund-policy copy. The regression scope shrinks from "full manual testing" to "one module plus one content slot" — potentially from two days of work to half a day, and the review meeting no longer decides what to test by guessing.
Getting started in small teams
Small teams do not need complex tools — a shared spreadsheet with filters and status colors plus a weekly review is enough. The key is maintaining bidirectional traceability: before launch, verify every requirement has a test; after launch, verify every test has a source requirement. For more, see product validation and user testing and the business analyst guide.
16IDC perspective
For teams building websites, SaaS products, or AI applications, the value of an RTM is not process compliance — it is that traceability equals fixability. When something breaks in production, being able to locate in one table which requirement, which code, and which tests are involved, within 30 seconds, beats any post-mortem.
Source: https://www.iiba.org/business-analysis-body-of-knowledge/