Requirements Traceability Matrix (RTM): Template and Example

October 22, 2026 · 6 min read

A requirements traceability matrix (RTM) is a table that links every requirement to the things that come from it and the things that prove it: goals, design, tasks, test cases. Its purpose is to answer two questions at any moment: "why are we building this?" and "has everything we promised been built and checked?"

This page gives you a template to copy, a worked example, and a practical way to build one that does not go stale in a month.

What a traceability matrix is for

Requirements change, features get dropped, and tests get written for the wrong thing. A matrix makes those problems visible because every row has to connect in both directions.

It helps in four situations:

• A change is proposed. You can see which designs, tasks and tests it touches before you agree to it.
• Something is cut. You can see which goals lose coverage.
• Testing starts. You can see which requirements have no test yet.
• Someone asks why a feature exists. You can point at the goal it serves.

It is not a replacement for the requirements document itself. It is an index across documents, and it is only as good as the IDs underneath it. If your requirements do not have stable IDs yet, start there; the software requirements document template shows how.

Forward, backward and bidirectional traceability

There are three common types, and the difference is the direction you trace.

• Forward traceability starts at a requirement and follows it to design, build and test. It answers: "is this requirement covered everywhere it should be?"
• Backward traceability starts at a work item or test and follows it back to a requirement and a goal. It answers: "why does this exist, and is any of it gold plating?"
• Bidirectional traceability does both, and it is what most teams mean by an RTM. It catches orphans in either direction: a requirement with nothing built, and something built that no requirement asked for.

For a small project, a single table that you read both ways is enough. You do not need separate documents for each direction.

The traceability matrix template

One row per requirement. Start with the columns you can keep up to date, and add more only when someone will actually use them.

What each column is for:

• Req ID: a stable identifier that never changes and is never reused, even if the requirement is deleted.
• Requirement (short): a few words, with the full text living in the requirements document.
• Source / goal: the business goal or the person who asked for it. This is the column that powers backward tracing.
• Priority: one scheme, used everywhere.
• Design / diagram: the screen, flow, diagram or architecture decision that covers it.
• Work item: the ticket or task identifier.
• Test case: the test or acceptance check that proves it. Without this column the matrix cannot tell you what is verified.
• Status: a small set of values the team agrees on, such as not started, in progress, built, verified.

A short worked example

The example is invented, for a customer order portal.

Reading this matrix, you can see three things at once. REQ-3 has no test case yet, so it cannot be called done. REQ-4 traces back to a single customer's request rather than a goal, which is a prompt to ask whether it belongs. And no row connects to a goal that is missing from the table, which tells you the goals are covered.

How to build one

1. Give every requirement a stable ID. Everything else depends on this.
2. Link each requirement to its source. A goal, a stakeholder or a document. If it has none, ask why it exists.
3. Add the design reference once a screen, flow or decision covers the requirement.
4. Add work items as tickets are created. Use the ticket ID, not a description.
5. Add test cases and check for empty cells. Every empty cell in the test column is a requirement nobody has verified.
6. Review gaps on a schedule. Walk the empty cells before each release.

Keep the matrix at the level where it pays off. Tracing hundreds of tiny requirements by hand rarely survives contact with a real project.

Common mistakes

• Unstable IDs. If REQ-3 means something different next month, every link is wrong.
• Too many columns. Each one is a maintenance cost. Add a column only when somebody reads it.
• Built once, never updated. A stale matrix is worse than none because people trust it.
• Tracing wording instead of intent. The link is to the requirement, not to a copy of its text.
• No review of empty cells. The value of the matrix is in the gaps, not in the filled rows.

Spreadsheet or tool

A spreadsheet is a sensible start for a small project: one sheet, filters on status, and a rule that nothing is built without an ID. It strains when requirements change often, because you update links by hand in several places.

Tools that store requirements as linked records keep the matrix in step with the work, since the links are the data. Discovery Phase AI, for example, keeps links between requirements and goals, diagrams, decisions and roadmap milestones as part of the discovery document, and its impact check flags which parts of a project a change touches. You can see what such a project looks like in the example report, which uses an invented project. It does not manage test cases, so if you need full test traceability you will still pair it with your test tool.

For what to gather before you write requirements at all, see the discovery phase checklist, and for turning requirements into a defined scope, how to scope a software project.

The matrix is a small tool with one job: to make sure what you promised, what you built and what you tested are the same thing. Keep it small enough that people keep it true.