Requirements traceability matrix
A requirements traceability matrix (RTM) is a table that maps each requirement to the test cases that verify it, and often to their results. It shows which requirements are covered, which have failed and which have no test at all. Rows are normally requirements, and the columns carry test case IDs and status.
The longer version
A small matrix has a row per requirement. REQ-12, 'a user can reset a password by email', is linked to test cases TC-40 to TC-43, with a status column showing which passed in the latest run. A requirement row with no test case is an untested requirement. A test case that traces to no requirement is either checking something nobody asked for, or it points at a requirement missing from the list.
Direction matters. Forward traceability follows a requirement to its tests, and sometimes on to design and code, and it answers whether everything asked for has been checked. Backward traceability follows a test or a piece of code back to the requirement that justifies it, and it answers why that item exists. A bidirectional matrix carries both.
Maintenance is the cost. A matrix kept in a spreadsheet drifts as requirements change and tests are renamed. Teams that keep it current generate it from their tools, linking stories or requirements to test cases in the test management system or the issue tracker, so the table is a report and nobody edits it by hand. It turns up in regulated work, where an auditor may ask for evidence that each requirement was tested.
Traceability coverage, the count of requirements with at least one linked test, is a different measure from code coverage. A requirement with one linked test is traced, which does not mean it is well tested.
Common questions
What is the purpose of a requirements traceability matrix?
A traceability matrix shows that every requirement has a test and every test has a reason. A reader can see gaps in coverage, find which tests a changed requirement affects, and give an auditor evidence of what was verified.
What are the types of traceability?
Forward traceability maps requirements to the tests and work items that deliver them, and backward traceability maps tests or code back to requirements. A bidirectional matrix supports both, which suits change impact checks and audits.
What columns should a traceability matrix have?
A matrix usually has a requirement ID and description, a source, a priority, linked test case IDs, the latest result and often defect IDs. Design or code references can be added where an audit or a change review needs them, and fewer columns are easier to keep correct.
Is a traceability matrix still used in agile teams?
Agile teams usually trace user stories and acceptance criteria to tests inside their issue tracker or test management tool and keep no standalone document. Teams in regulated industries still produce a matrix for audit, generated from those links.
How is a traceability matrix related to test coverage?
The matrix is the record that lets a team report requirements coverage, meaning how many requirements have at least one test. Test coverage in the code sense measures what the tests execute, and a linked test does not prove a requirement is well tested.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.