·
8 min
Requirements Traceability Matrix: What It Is and What Goes In It
Roman Kirchmeier - Autemos
A requirements traceability matrix is a table that links every requirement to the test cases, test runs and defects that prove it was built. It answers the two questions an auditor always asks: is every requirement tested, and which requirement does this failed test belong to? In regulated industries the link is mandatory, in banking just as much as in medical devices. No standards body publishes a binding column template. Which columns you need depends on what the matrix has to prove.
TL;DR: A requirements traceability matrix links requirement, test case, test result and defect in one table. No standards body publishes a canonical column template. Regulators still demand the link: DORA Art. 24(6) requires financial entities to test all systems supporting critical functions at least yearly.
Figure 1: The traceability chain from requirement to defect, readable in both directions.
What is a requirements traceability matrix?
A requirements traceability matrix is the tabular view of the relationships between requirements and the artefacts that prove they were met. The ISTQB defines traceability as “The ability to identify related items in documentation and software, such as requirements with associated tests” (ISTQB Glossary). The matrix renders exactly those relationships as rows.
ISO/IEC/IEEE 24765:2017 describes traceability as a distinguishable link between two or more logical entities such as requirements, system elements, verifications and tasks (cited via t2informatik). For test work the consequence is simple: a requirement with no linked test case is a gap, and the matrix makes that gap visible.
A note on German terminology
German-speaking teams use two terms. The current ISTQB glossary headword is “Verfolgbarkeit”, defined as the degree to which a relationship can be established between two or more work products (ISTQB Glossar). “Rückverfolgbarkeit von Anforderungen” means the same thing in practice and appears more often in audit reports. Both are in common DACH use.
What goes into a requirements traceability matrix?
No standards body publishes a binding column set for requirements traceability. Neither ISO/IEC/IEEE 29119-3:2021 nor the FDA nor the ISTQB prescribes a canonical layout. Any template sold to you as “the correct one” is a convention. The cut depends on your industry, the standard you answer to and the purpose of the audit.
Figure 2: The six core columns with three example rows. The last row has no test case at all.
A practical minimum set has settled out across projects and carries most test management work:
Requirement ID: unique, stable, versionable
Requirement description: one line, phrased so it can be tested
Test case ID: one or several per requirement
Test status: passed, failed, blocked, not run
Defect ID: the link to the bug ticket
Coverage status: the derived verdict per requirement
Teams that need more depth add the source of the requirement, the design element and the verification method. Jama Software publishes an eight-column infusion-pump sample in that shape (Jama Software).
A worked example from a payment release flow
Requirement ID | Description | Test case ID | Test status | Defect ID | Coverage status |
|---|---|---|---|---|---|
REQ-PAY-001 | Payments above CHF 50,000 require dual approval | TC-PAY-011, TC-PAY-012 | Passed | none | Covered |
REQ-PAY-002 | The approving user must not be the user who entered the payment | TC-PAY-014 | Failed | DEF-2291 | Covered, defect open |
REQ-PAY-003 | Every approval is written to the audit log with user ID, timestamp and amount | TC-PAY-020 | Passed | none | Covered |
REQ-PAY-004 | If the approval service fails, the payment stays in status “pending” | TC-PAY-031 | Blocked (test environment) | none | Partially covered |
REQ-PAY-005 | Approval limits are configurable per role | none linked | Not run | none | Not covered |
The last row is the reason the matrix exists. REQ-PAY-005 has no test case at all. Without the table, that surfaces during the audit. Our article on linking requirements and tests with Xray in Jira walks through building these chains.
What do forward, backward and bidirectional traceability mean?
Forward traceability runs from the requirement to design, code and test; backward traceability runs from an artefact back to the requirement that justifies it. Microsoft puts it this way in the Azure DevOps documentation: “Requirements traceability is the ability to relate and document two or more phases of a development process, which can then be traced both forward or backward from its origin.” (Microsoft Learn, 2026).
Gotel and Finkelstein introduced this double direction at the first IEEE International Conference on Requirements Engineering in 1994, describing requirements traceability in substance as the ability to describe and follow the life of a requirement forwards and backwards.
Forward: requirement → test case → test run. Answers: is everything we asked for tested?
Backward: defect → test case → requirement. Answers: which business requirement does this bug hit?
Bidirectional: both directions maintained at once. This is what the safety standards ask for.
Which regulations require traceability?
Traceability is an audit requirement in at least five regulatory frameworks, and financial services is one of them. One point of accuracy first: DORA never uses the term traceability matrix and does not mandate one. Regulation (EU) 2022/2554 requires financial entities other than microenterprises, in Art. 24(5), to set up procedures and policies to “prioritise, classify and remedy all issues revealed throughout the performance of the tests”, plus internal validation methods that confirm all identified weaknesses, deficiencies or gaps are fully addressed (EUR-Lex, Regulation (EU) 2022/2554, 2022). Art. 24(6) requires the same entities to ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions.
Figure 3: Six frameworks require traceability. DORA never uses the term matrix.
Art. 24(5) is the strongest hook here. Prioritising, classifying and remedying every issue a test reveals, then evidencing the fix, needs exactly the link between requirement, test run and defect that a live traceability report produces.
Framework | Sector | What it requires |
|---|---|---|
DORA Art. 24(1), 24(5), 24(6) | Financial services (EU) | A testing programme, documented remediation of every finding, at least yearly tests of critical systems |
EU GMP Annex 11, Section 4.4 | Pharma and GxP | User requirements traceable throughout the life-cycle |
FDA Computer Software Assurance | Medical devices, production and quality system software | Risk-based evidence; supersedes Section 6 of the 2002 validation guidance |
IEC 62304 | Medical device software | Traceability from system and software requirements through tests and risk-control measures |
DO-178C | Aviation | Bidirectional traceability, depth scaling with the Design Assurance Level |
ISO 26262 | Automotive | Bidirectional traceability of safety requirements |
The EU GMP guide is short and unambiguous here: “User requirements should be traceable throughout the life-cycle” (Annex 11, Section 4.4, as reported by the ECA Academy). The FDA announced its final Computer Software Assurance guidance in the Federal Register on 24 September 2025 (Federal Register, Docket FDA-2022-D-0795).
Treat clause numbers for IEC 62304, DO-178C and ISO 26262 with care. IEC 62304 is commonly cited as subclause 5.1.1(c); the primary texts sit behind paywalls and the numbers circulating in secondary sources are not consistently verified. Our overview of testing in regulated industries and the piece on GxP testing and computer system validation go deeper.
Why do manually maintained matrices go stale?
A hand-maintained traceability matrix goes stale since every change to a requirement, test case or ticket needs a second manual edit in a file nobody owns. In her survey at ICSE FOSE 2014, Jane Cleland-Huang argues in substance that the cost of creating and maintaining trace links is high and that the link infrastructure erodes over a system's lifetime as practitioners stop updating links after changes.
Ruiz, Hu and Dalpiaz reach a similar conclusion in the Requirements Engineering journal in 2023. Their study, based on 55 survey participants and 14 interviews, describes traceability in substance as a sought-after yet often elusive quality in software-intensive systems, after decades of tooling research.
There is no number attached to this. We know of no study that measures how fast a spreadsheet matrix decays, and we will not invent one. The argument stays qualitative: a matrix somebody updates by hand shows the state of the last maintenance session, not the state of the last test run.
How do tools generate the matrix automatically?
Modern tools generate the traceability matrix as a report at query time from linked items, rather than storing it as a document. Xray's Requirement Traceability Report “enables you to follow the life of a Requirement in both forward and backward directions” and shows requirements across tests, test runs and defects (Xray documentation).
Figure 4: Five steps build the chain the tool generates the report from.
Azure DevOps links test results to work items automatically and surfaces a “Requirements quality” widget with pass rate and failed-test count per requirement, including the requirements that have no associated test at all (Microsoft Learn, 2026). Siemens Polarion ships traceability fields and gives LiveDocs paragraph-level unique IDs for ReqIF exchange; Siemens recommends making traceability part of the Definition of Done (Siemens). PTC's codebeamer renders “Traceability Matrix” and “Traceability Browser” live between tracker types (PTC).
Here is how the chain gets built in practice:
Create the requirement as a work item with a unique, stable ID.
Link the test case to that requirement, not just by naming it in the title.
Report automated test runs back to the test case, with timestamp and build.
Link defects to the failed run, not to the test case alone.
Generate the report at audit time and archive it as evidence.
Step 3 is where automation earns its keep. Autemos is an execution engine and not a test management tool: tests run there, and the results flow back through the Jira/Xray integration into the management layer where the matrix is produced. In client projects we see this hand-back as the point where traceability either holds or falls apart. The test workflows in Autemos show how those hand-offs are modelled; for evidence retention, read our piece on the audit trail in testing.
Frequently asked questions
Is a requirements traceability matrix legally required?
The matrix as a document form is required nowhere; traceability itself is required in several frameworks. EU GMP Annex 11 Section 4.4 asks for user requirements to stay traceable throughout the life-cycle, and IEC 62304, DO-178C and ISO 26262 require traceability for safety-related software. DORA does not use the word matrix.
How many columns does a requirements traceability matrix need?
As many as the audit purpose demands. Six columns (requirement ID, description, test case ID, test status, defect ID, coverage status) carry most projects. Safety standards add layers such as design element and risk-control measure. There is no canonical template from any standards body.
What is the difference between test coverage and traceability?
Test coverage measures a proportion; traceability shows a connection. A requirement can be linked and still be tested badly. The matrix answers whether a link exists; test coverage answers how thoroughly the thing was tested.
Is a spreadsheet good enough for a traceability matrix?
For a small, closed project, yes. Once requirements, test cases and tickets change weekly, the file shows the state of the last manual update. Xray, Azure DevOps, Polarion and codebeamer produce the same view live from linked items.
Who maintains the requirements traceability matrix in a team?
In a properly linked setup, nobody maintains it as a document. Responsibility sits with the roles that create the items: product owners for requirement IDs, test management for the test-case links, the pipeline for test runs. Our test management guide covers the role split.
Conclusion
A traceability matrix connects requirement, test case, result and defect, and it exposes gaps before an auditor finds them. The columns are convention; the link is obligation. EU GMP Annex 11 Section 4.4 asks for traceability across the life-cycle, DORA Art. 24(6) for at least yearly tests of critical systems, and the safety standards in medical devices, aviation and automotive ask for both directions at once. Put the production of the matrix into the tooling: generated at query time from linked items, the report shows the state of the last test run. Our article on test reporting covers how results from automated runs get back into the management layer.
Want your test results tied cleanly back to requirements? Talk to us.
