Blog
Requirements Traceability Matrix: Types, Example, Template
Abhilash
Published on
Table of contents
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
A requirements traceability matrix (RTM) links each requirement to the test cases, code and deliverables that build and check it. It’s been around for decades, but it matters a lot more now than it used to.
Here’s why. Requirements change every week, code gets refactored every day and more tests are written by AI. If you want your tests to keep matching what the business actually asked for, you have to keep those links up to date all the time, not once a quarter.
That’s why many teams are moving away from RTMs kept in spreadsheets, towards ones that live inside their test tools and update as things change.
In this guide, you’ll learn what an RTM is, the three types of traceability, which fields to include, a worked example you can copy, how to build one, which standards expect it, how it works across different ways of working, and how to keep it up to date.
What is a Requirements Traceability Matrix?
A requirements traceability matrix is a record of how each requirement connects to the work that delivers it. That usually means design, code, test cases and releases, though it can include more depending on your project.
It helps you answer four questions that are hard to answer any other way:
Which requirements have been built?
Which requirements have been tested?
What’s affected if a requirement changes?
Which requirement is this test actually checking?
Without an RTM, you can have tested software but no proof that it matches what was asked for.
The word “matrix” comes from when it really was just a table. These days, it’s often more like a network of links inside a test management tool, where each requirement connects to lots of work items and each work item can be traced back to its requirement. What matters is that the links exist and stay current, not what format they’re in.
Benefits of a Requirements Traceability Matrix
Benefit | How the RTM Helps |
|---|---|
Full test coverage | Every requirement is linked to its tests, so a requirement with no tests is easy to spot |
Knowing what a change affects | When a requirement changes, you can see every test, module and deliverable it touches, without working it out from memory |
Keeping scope under control | Every piece of work links to an approved requirement, so work outside scope shows up early |
Evidence for compliance | It shows which regulated requirements were built and tested, and how |
Testing by risk | You can focus testing on the requirements that matter most to the business |
Faster decisions | One shared source of truth replaces scattered knowledge about why things exist |
Why the RTM Matters More Than Ever
You might expect RTMs to matter less now that teams work faster. Agile, continuous delivery and AI coding all favour speed over paperwork, and an RTM can look like paperwork.
But three things have actually made traceability more valuable:
Requirements Keep Changing
They don’t get finalised before development starts anymore. Without traceability, you can’t tell which tests check the current version of a requirement and which check an old one.
Code Moves Faster
AI assistants and modern pipelines push code through faster than people can review it. Without traceability, you can’t tell which tests to rerun when a module changes.
Mistakes Cost More
Enterprise software handles customer transactions directly, so a missed requirement means a customer doesn’t get what they should. A test that no longer matches its requirement gives you false confidence without anyone noticing.
Traceability turns each of these blind spots into something you can see, so you can answer “what’s affected?” without starting from scratch every time.
The Three Types of Traceability
Type | Direction | Question it Answers | What it Catches |
|---|---|---|---|
Forward | Requirement to work | Has each requirement been built and tested? | Requirements with no tests, which are coverage gaps |
Backward | Work to requirement | Does each test, module or design actually serve a requirement? | Orphaned work, like tests checking behaviour nobody asked for, or code nobody remembers the reason for |
Bidirectional | Both ways | What does a change affect, and which requirement is at risk when a test fails? | Both of the above, and it’s the basis for impact analysis |
Most guides gloss over this, but forward and backward traceability catch different problems. Forward finds requirements nobody tested. Backward finds work nobody can explain. If you only keep one direction, you miss half the problems.
Keeping both takes more effort, but it’s the only way to stay honest about what’s been built, what’s been tested and what’s at risk when things change.
What Fields Should a Requirements Traceability Matrix Include?
Older RTM templates were built for 1990s projects. A modern RTM needs to track more, because the questions teams need to answer are bigger.
Field | What it Records |
|---|---|
Requirement ID | A unique, permanent ID, like R-101 |
Description | What the requirement says, in plain language |
Source | Where it came from, like a user story, regulation or customer request |
Version | Which version of the requirement this is |
Owner | Who’s responsible for it |
Priority or risk | How important it is to the business |
Status | Approved, in development, done or retired |
Design or code links | The design elements and code modules that deliver it |
Test case IDs | The tests that check it |
How it’s verified | Automated test, manual test, inspection or review |
Latest result | Pass or fail, on which build and when |
Coverage status | Covered, partly covered or not covered |
Open defects | Any bugs linked to it |
Release | Which release it shipped in |
A requirement counted as “covered” today needs to be covered properly: by current tests, against the current code, and tested more often if it carries more risk.
In a well-set-up test platform, these fields don’t all sit in one big spreadsheet. The links are stored as connections in a live database, and you see them as a matrix, dashboard or report depending on who’s looking.
Requirements Traceability Matrix Example
Here’s part of an RTM for the checkout and payment area of an online shop, using the most common fields.
A real RTM will have more columns, but this is the readable core most teams start with.
Req ID | Requirement | Priority | Status | Test Cases | Verified By | Latest Result | Coverage |
|---|---|---|---|---|---|---|---|
R-101 | Guest users can check out with a card | High | Done | TC-201, TC-202 | Automated test | Pass | Covered |
R-102 | Saved cards can be used at checkout | High | Done | TC-203 | Automated test | Pass | Covered |
R-103 | Discount codes apply before tax | Medium | In development | TC-204 | Automated test | Fail | Partly covered |
R-104 | Declined cards show a clear error message | High | Done | TC-205, TC-206 | Automated test | Pass | Covered |
R-105 | Card details are never stored in plain text | Critical | Done | TC-207 | Automated test and security inspection | Pass | Covered |
R-106 | Order confirmation email is sent within 5 minutes | Medium | Approved | None | Not yet | Not run | Not covered |
Read this as a health check, not just a record:
R-106 has no tests at all. It’s approved and has an owner, but nothing checks it yet. That’s exactly the kind of gap an RTM is there to catch.
R-103 is only partly covered because it’s still being built, and its one test is currently failing.
R-105 has two ways of being checked, because a regulated requirement often needs both an automated test and a manual inspection.
The useful part isn’t the tidy rows. It’s the rows that aren’t tidy, because those are the risks your team can now see and fix.
How to Build a Requirements Traceability Matrix in Five Steps
Step | What to Do |
|---|---|
1. Collect and settle your requirements | Pull requirements from every source, including specs, user stories, regulations, customer feedback and bug reports. Give each one a permanent ID and record its source, priority and owner |
2. Decide on your fields | Choose the fields based on the questions your team actually needs to answer, not just what a template suggests. Different industries care about different fields |
3. Link the work as you go | Link tests, code and designs to requirements as they’re created, not afterwards. That’s far easier than trying to piece it together later |
4. Agree when it gets updated | Decide what triggers an update, like a requirement changing or a test being added or retired. Doing it consistently matters more than doing a lot of it |
5. Use it in your regular meetings | Check it in sprint planning to confirm stories are covered, in release planning to check the release scope, and in retros to find gaps you missed |
Who Uses a Requirements Traceability Matrix?
An RTM isn’t just for QA, which is part of why it’s stuck around.
Role | How They Use It |
|---|---|
Test and systems engineers | To check coverage |
Project managers | To track scope and progress |
Business analysts | To make sure what’s delivered matches what was asked for |
Compliance and audit teams | As the evidence trail regulators expect |
Because everyone looks at the same information from their own angle, nobody ends up keeping a private version of the truth.
Spreadsheet RTMs vs Living RTMs
In the past couple of years, plenty of QA teams have found that a spreadsheet RTM looked after by one person just can’t keep up. Three things break it:
Spreadsheet RTM | Living RTM | |
|---|---|---|
Volume | Fine for hundreds of requirements, unmanageable for thousands | Handles thousands, because links are kept automatically |
Speed | Updated weekly, so it’s always behind daily code changes | Updates within minutes of a change in the source system |
Connections | Sits on its own, cut off from your pipeline, issue tracker and test tools | Connected to your requirements tool, test platform, version control and issue tracker |
Asking questions | You read through rows | You ask a question and get an answer straight away |
Ownership | Usually one person | Shared, because it updates as everyone works |
With a living RTM, requirements stay in your requirements tool, tests in your test platform, code in version control and bugs in your issue tracker. The RTM is just the set of links between them, kept up to date automatically. That means you can ask things like:
Which requirements have no tests?
Which tests still check behaviour a requirement no longer asks for?
What would be affected if this requirement changed?
And when a requirement changes, the test platform can show which tests are affected. When a test fails, you can see which requirement is at risk.
How the RTM Supports Risk-Based Testing
Risk-based testing means focusing your testing on what matters most to the business. Running every test on every change is too slow, and picking a random subset is too risky. Risk-based testing picks the tests that protect the business and accepts a small risk on the rest.
You can’t do that without an RTM, because you need answers to questions like these:
Which requirements matter most to the business?
Which tests check those requirements?
Which of those tests have failed before?
Which requirements were affected by recent code changes?
Which tests need to run in the next release to cover the riskiest requirements?
With a living RTM, you can answer these in seconds. Without one, you can’t really answer them at all. So if you want to do risk-based testing, set up your RTM first.
Our guide to risk-based regression testing goes deeper into scoring requirements by risk and choosing which tests to run.
RTM in Waterfall, Agile and Regulated Projects
Way of Working | How the RTM is Used |
|---|---|
Waterfall | Requirements are set up front, and the RTM follows them through design, development, testing and release. It’s checked at each phase gate so nothing gets lost between stages |
Agile | The RTM changes every sprint, linking user stories to acceptance criteria and tests, and showing which backlog items still need tests during sprint planning |
Hybrid and regulated Agile | The RTM provides the audit trail that pure Agile often lacks, so teams can deliver in sprints and still give regulators the evidence they expect |
Whichever way you work, the RTM does the same job: it shows what’s been built, what checks it and what’s at risk when something changes.
RTM and Regulatory Compliance
For many teams, compliance is the main reason the RTM exists. In aerospace, defence, medical devices, automotive and similar industries, you have to prove to regulators and auditors that every requirement was built and tested, and the RTM is how you show it.
Standard | Where Traceability Comes In |
|---|---|
DO-178C | Airborne software. Requires traceability between requirements, code and tests |
IEC 62304 | Medical device software. Requires traceability between requirements, design, risk controls and testing |
ISO 26262 | Automotive functional safety. Requires traceability across safety requirements, design and verification |
FDA QMSR (21 CFR Part 820) | Medical devices. Design controls expect design outputs to trace back to design inputs, with verification and validation records |
ISO 13485 and ISO 9001 | Quality management. They expect documented design and development controls, and an RTM is a common way to show them |
FDA 21 CFR Part 11 | Electronic records and signatures. It doesn’t require an RTM, but if your RTM is an electronic record in a regulated process, it needs proper audit trails and access controls |
In each case, the RTM connects requirements to the tests and results that check them, so an auditor gets a clear line of evidence instead of a pile of separate documents.
Living RTMs matter even more here. Evidence that’s a cycle behind is a risk in itself.
When links are kept up to date and tied to versions, you can show exactly which version of a requirement each test checked in each release, which is precisely what auditors ask for.
Compliance and Risk Matrices
There are two specialised versions of the RTM worth knowing:
Compliance matrix: maps each clause of a regulation to the requirements that meet it and the tests that check them, so auditors can follow the evidence clause by clause.
Risk matrix: links possible risks to the requirements that reduce them, so every major risk has a planned, built and tested safeguard. It supports methods like Failure Modes and Effects Analysis (FMEA), and can include a risk priority number based on how severe and how likely each risk is.
Both use the same links as your RTM, just viewed from a different angle, which is easy to do when your RTM is live and searchable.
Common RTM Problems and How to Fix Them
Problem | What Happens | Fix |
|---|---|---|
Links drift out of date | A requirement changes but its tests don’t, so they end up checking a version that no longer exists | Automate linking |
Orphaned work | Tests and code pile up with no link to a requirement, and nobody remembers why they exist | Run regular checks for unlinked work |
False sense of coverage | Every requirement has a test, but some tests are too shallow to really check it | Set rules for how thoroughly a requirement must be tested, not just whether a test exists |
Version mix-ups | Links point to the latest version, which may not be what shipped in a past release | Tie links to specific versions |
Nobody uses it | The RTM is kept up to date but never used in planning or triage, so it becomes paperwork | Build it into the meetings where decisions get made |
One owner | One person keeps it running, then leaves, and it falls apart | Share ownership across the team |
RTMs and AI-Written Code and Tests
AI-written code and tests make the RTM both harder to keep up and more important.
It’s harder because AI produces far more code and tests than people can link by hand, so a manual RTM falls behind straight away.
It’s more important because AI mistakes can be subtle. An AI-written test can look right and claim to check a requirement without really checking it. AI-written code can look like a finished feature without actually meeting the requirement. The RTM helps catch these mismatches when reviewers can’t check everything.
The practical answer is to use automation for the links too. Let AI draft the links between requirements and work, and have people review those links instead of creating them all from scratch. That keeps your RTM current at AI speed, with human judgement where it counts.
How Virtuoso QA Keeps Your RTM Up to Date
In Virtuoso QA, traceability is part of how tests are built, not a separate spreadsheet you update later.
Requirements and tests linked from the start: Touchstone reads your specs, user stories and policy documents, drafts requirements with a citation to the exact source, and builds journeys from the approved ones. The link from source document to requirement to test exists from day one.
Changes flagged automatically: when you upload a revised document, Touchstone flags the requirements it affects, and any journeys built on an out-of-date requirement get flagged too. That keeps link drift from building up.
Named, versioned approvals: every requirement and test is approved by a named person, with each version recorded, so you can show which version of a requirement a test checked in a given release.
Failures you can trace: because each journey is linked to the requirement it checks, a failed run shows which requirement is at risk, alongside screenshots, logs and the failing step.
Test fixes that keep links intact: when a screen changes, Virtuoso QA suggests fixes for your team to approve, and the test keeps its link to the requirement throughout.
Connected to your pipeline: tests run from Jenkins, Azure DevOps or GitHub Actions, with results linked back to Jira, so a change or failure shows up against the right requirement.
When an auditor asks which requirements were tested in a release and who approved the tests, Virtuoso QA’s release evidence gives you that list, version by version.
Related Reads
Requirements Traceability Matrix FAQs
Is an RTM Still Relevant in Agile?
How Do I Create a Requirements Traceability Matrix?
What Columns Should an RTM Contain?
Which Compliance Standards Require Traceability?
What Is the Difference Between an RTM, a Compliance Matrix, and a Risk Matrix?
Written by
Abhilash
Industry Analyst, Test Automation
Abhilash tracks how AI is reshaping software testing, from pairwise coverage to regulatory accountability, and writes research-led pieces that cut through vendor noise with numbers.
