Glossary · Testing fundamentals
Requirements traceability matrix
Also called: RTM, traceability matrix, requirement traceability matrix, requirements traceability
Definition
A table that maps each requirement to the test cases that verify it and their results, so gaps in coverage and the impact of changes are visible.
A requirements traceability matrix (RTM) links requirements to the tests that cover them, and often onward to execution results and defects. It answers two questions quickly: is every requirement tested, and if this requirement changes, which tests need updating? It is mandatory in regulated domains such as medical devices, aviation and finance, and useful anywhere coverage has to be demonstrated.
Example
| Requirement | Description | Test cases | Status | Defects |
|---|---|---|---|---|
| AUTH-01 | User can log in with valid credentials | TC-101, TC-102 | Passed | none |
| AUTH-02 | Account locks after 5 failed attempts | TC-103, TC-104, TC-105 | Failed | BUG-311 |
| AUTH-03 | Password reset link expires after 30 minutes | (none) | Not covered | n/a |
Reading it: AUTH-03 has no tests, which is a coverage gap. AUTH-02 is covered but failing, so it is a release risk tied to a specific bug.
Forward, backward and bidirectional
- Forward traceability: requirement to tests. Proves every requirement is verified.
- Backward traceability: test to requirement. Shows tests that verify nothing anyone asked for, which may be obsolete or may reveal a missing requirement.
- Bidirectional: both directions, which is what most auditors expect.
RTM vs code coverage
An RTM measures requirements coverage: whether each stated need has a test. Code coverage measures which lines or branches executed during tests. You can have 100% requirements coverage with poor code coverage and the reverse. They answer different questions and work best together.
Keeping it maintainable
A spreadsheet maintained by hand goes stale quickly. Most teams generate traceability from their tools instead: test cases tagged with story IDs in the test management tool, or automated tests annotated with the requirement key (for example a tag like @AUTH-02 in Playwright test titles or a JUnit @Tag), then a report joins them. The matrix is only as good as the discipline of tagging every new test.