A requirements traceability matrix (RTM) is a table that links each requirement to where it came from, how it is designed, where it is built and how it is tested. Each row follows one requirement from its source to its test, so you can answer two questions at any moment: "is everything we promised actually built and tested?" and "why does this piece of code exist?"
Below: what an RTM contains, the types of traceability, a copy-paste template, a worked example, how to build one step by step, and why most of them go out of date.
What is a requirements traceability matrix?
Requirements traceability is the ability to follow a requirement forwards and backwards through the life of a project. An RTM is the document that records those links. It is usually a spreadsheet, though it can live in an issue tracker or a requirements-management tool.
It exists to catch two kinds of problem. A requirement with no test is a promise nobody is checking. A piece of work with no requirement is scope nobody asked for. The matrix makes both visible, because the gap shows up as an empty cell.
You will see it most in regulated or contract-driven work, such as medical devices, automotive, aerospace and government projects, where you may have to prove that every requirement was implemented and verified. It is just as useful in a startup, in a lighter form, because the failure it prevents is common: a requirement that quietly fell out of the build.
What are the types of traceability?
There are two directions, and most matrices record both.
- Forward traceability follows a requirement towards the work that satisfies it: requirement, then design, then code, then test. It answers "has every requirement been built and tested?"
- Backward traceability follows work back to the requirement behind it: test, then code, then design, then requirement, and finally the source such as a stakeholder or a regulation. It answers "why does this exist?"
- Bidirectional traceability is both at once, which is what a well-kept RTM gives you.
A related distinction is horizontal and vertical. Vertical traceability links across levels of detail, from a business need down to a test. Horizontal links relate things at the same level, such as one requirement that depends on another.
Requirements traceability matrix template
Here is a template you can paste into a spreadsheet or a markdown file. The columns are the ones that do the work. Add more only if someone will use them.
| Req ID | Requirement | Source | Priority | Design ref | Implementation | Test case(s) | Status |
|---|---|---|---|---|---|---|---|
| R-001 | <one testable statement> | <stakeholder, doc or regulation> | Must / Should / Could | <design doc or page> | <module, PR or ticket> | <test IDs> | Not started / In progress / Built / Verified |
What each column is for:
- Req ID. A stable identifier that never changes, even if the wording does. Everything else points at this.
- Requirement. One testable statement. If it contains "and", it is probably two requirements.
- Source. Where it came from. This is what makes backward traceability possible, and it is the column teams skip most often.
- Priority. Must, Should or Could, so a gap in a Must stands out.
- Design ref. The design document, page or schema table that addresses it.
- Implementation. The code module, pull request or ticket.
- Test case(s). One or more test IDs. An empty cell here is the thing the matrix exists to expose.
- Status. Where it stands now.
A requirements traceability matrix example
Here is a filled-in example for the share-link feature of a freelance feedback app, where clients leave comments through a link without creating an account. The IDs, tickets and tests are illustrative.
| Req ID | Requirement | Source | Priority | Design ref | Implementation | Test case(s) | Status |
|---|---|---|---|---|---|---|---|
| R-001 | A designer can copy a share link for a project | Story US-12 | Must | share_links table |
PR #88 | T-101 | Verified |
| R-002 | A share link opens the feedback board without login | Story US-12 | Must | Page /share/:token |
PR #91 | T-102 | Verified |
| R-003 | A share link expires after 30 days | Client interview, 14 Oct | Must | share_links.expires_at |
PR #94 | T-103, T-104 | In progress |
| R-004 | An expired link offers a way to request a new one | Story US-13 | Should | Page /share/:token (expired state) |
none | none | Not started |
| R-005 | A designer can revoke a link before it expires | Open question OQ-2 | Could | none | none | none | Not started |
Reading it takes ten seconds. R-004 has no implementation and no test, which is fine because it is not started, but it is a Should, so it will be picked up soon. R-005 traces back to an open question, not a stakeholder, which tells you it is a guess that has not been confirmed. And working backwards from PR #94 you can see why it exists: it satisfies R-003, which came from a client interview. That is the "why does this exist?" question answered by a table.
How to build a requirements traceability matrix
- Collect the requirements and give each a permanent ID. Pull them from the PRD, user stories or contract. If you do not have a clean list yet, write one first. What is a PRD and how to write user stories cover that step.
- Make each requirement testable. If you cannot say how you would check it, it is not a requirement yet. Acceptance criteria are the usual way to do this, and each criterion can become a test case.
- Record the source. A name, a document, a date. Do this while you remember.
- Add design references as the design takes shape: pages, components, schema tables.
- Link implementation by putting the requirement ID in the branch name, pull request or ticket, so the link is created as a side effect of the work.
- Link tests by putting the requirement ID in the test name or tag.
- Review gaps on a schedule. Filter for Must requirements with an empty test cell. That filter is the point of the whole exercise.
The two steps that make or break it are 5 and 6. If linking a requirement to its code or test takes a separate manual step, it will be skipped under deadline pressure, and the matrix will decay.
Traceability matrix in agile
A common objection is that a traceability matrix is a waterfall artifact. In an agile team it looks different but the need is the same. The usual mapping is:
- the requirement is a user story,
- its acceptance criteria are the testable conditions,
- the implementation is the pull requests that reference the story,
- and the tests are the automated or manual checks that reference each criterion.
You may never open a spreadsheet. Your backlog tool, your repository and your test runner already hold the links if you use IDs consistently. The matrix becomes a view over them rather than a document you maintain, and that is the version most likely to stay accurate.
Why traceability matrices go out of date
Most RTMs are accurate on the day they are written and fiction a month later. The reasons are predictable.
The links are manual. Every link is a cell someone has to remember to update.
The requirements change faster than the sheet. A new story is added, an old one is reworded, and the spreadsheet is the last place to hear about it.
Granularity drifts. Some rows are a whole epic and others are a single button, so the gaps you find are not comparable.
Nobody reads it between audits. A document that is only opened for an audit is only maintained before one.
The fix is to make the links part of the work: stable IDs, links created where the work happens, and the matrix generated from them. That is more reliable than any amount of discipline about updating a spreadsheet.
Requirements traceability matrix tools
A spreadsheet is enough for a small project, and it is the right place to start. Issue trackers such as Jira and Linear can hold the links natively if you use consistent IDs and link types. Regulated industries often use dedicated requirements-management tools because they need audit trails, baselines and sign-off. Choose by what you will have to prove and to whom. If nobody will audit you, the lightest option that keeps the links current is the best one.
VibeMap, which I build, takes the "links as part of the work" route for product specs: personas, features, user stories, acceptance criteria, pages and database tables are stored as linked records, each tracing to the one that justified it, so "which stories have no acceptance criteria?" is a question the data can answer rather than a spreadsheet audit. On Pro and above, a spec-coverage check runs as part of preparing a project for development. It is about the spec, though, not a replacement for tracing code and tests in a regulated environment. Spec-driven development explains the approach.
FAQ
What is a requirements traceability matrix?
A requirements traceability matrix is a table that links each requirement to its source, design, implementation and tests. It shows whether every requirement has been built and verified, and why each piece of work exists.
What is the definition of requirements traceability?
Requirements traceability is the ability to follow a requirement from its origin through design, implementation and testing, and back again. It lets you show that every requirement was met and that nothing was built without one.
What are the two main types of traceability?
Forward traceability follows a requirement towards the work that satisfies it, from requirement to design to code to test. Backward traceability follows work back to the requirement that justified it. A matrix that records both is called bidirectional.
What is an RTM with an example?
An RTM is a requirements traceability matrix. A row might read: requirement R-003, "A share link expires after 30 days", source "Client interview", implemented in PR #94, verified by tests T-103 and T-104, status "In progress". The matrix above has five such rows.
What should a traceability matrix include?
At minimum a stable requirement ID, the requirement, its source, and the tests that verify it. Most also add priority, a design reference, the implementation, and a status. Add a column only if someone will use it.
Do I need dedicated tools for requirements management?
Not for a small project. A spreadsheet or your issue tracker is enough if you use stable IDs. Dedicated tools earn their cost in regulated work where you need audit trails, baselines and formal sign-off.
Related reading
- What is a PRD?, where the requirements in the matrix usually come from.
- How to write user stories with INVEST, the agile form of a requirement.
- Acceptance criteria examples, the testable conditions each row points to.
- Given When Then examples, for turning criteria into test scenarios.
- Spec-driven development, for keeping the links between artifacts current.
Sources and further reading
- ISO/IEC/IEEE, 29148:2018 Systems and software engineering: Requirements engineering: the standard that treats traceability as a property of good requirements.
- Cucumber, Gherkin Reference: Given/When/Then syntax for turning criteria into tests.
- Mike Cohn, User Stories Applied: the story format used in the agile mapping above.
