Requirements traceability matrix (RTM): template and example

Published 18 October 2026

A requirements traceability matrix (RTM) is a table that links each requirement to where it came from and to what shows it was delivered — the work built for it and the tests that check it. Read across a row and you see whether one requirement was built and tested; read down a column and you see what was missed, and what was built that nobody asked for. Below is a template for Excel or Google Sheets, a filled-in example, and what to do when the spreadsheet stops keeping up.

I understand the need for traceability but the implementation in my company is just terrible. We have super expensive systems that are very tedious to use. The processes are slow and clunky. There must be a better way.

— Hacker News, in an Ask HN thread on tracking requirements, 2022

What a traceability matrix is for

• Coverage: every agreed requirement has work and a test.
• Scope: every piece of work answers to a requirement — anything that does not is scope nobody agreed.
• Impact: when a requirement changes, you can see which work and which tests were built on it — the first step of a change impact analysis.
• Proof: for a client, an auditor or a regulator, what was agreed, built and tested.

Impact is the use that needs the links kept current. A commenter on systems engineering described requirements at two levels “traced to each other so that if one changes, the other gets flagged as needing attention” (r/systems_engineering, 2025).

What is traced to what, and where the links are kept, belongs in the requirements management plan.

The template

One row per requirement. The columns:

Paste this header into the first row of a sheet:

ID,Requirement,Source,Version,Work items,Tests,Result,Status

Requirements traceability matrix example

From a customer portal’s invoicing feature:

What it shows:

• FR-015 was built, and its test fails: not ready for acceptance.
• FR-021 was agreed and nothing has been built for it yet.
• UI-12 was built without any requirement behind it. Either someone agrees it now, or it is scope creep.

Forward, backward and bidirectional traceability

The example above uses both directions: the empty cells in FR-021’s row are a forward gap; UI-12’s missing source is a backward one.

How to create a traceability matrix in Excel or Google Sheets

1. Give every requirement a stable ID before the matrix exists. Without IDs there is nothing to trace.
2. One row per requirement, never one per document.
3. Fill the source column first. A requirement with no source is a question for the client.
4. Add the work items and tests as they are created, not at the end of the project.
5. Highlight empty cells with conditional formatting: they are the gaps.
6. Add a row for any work item with no requirement, like UI-12 above.
7. Record the version. When a requirement changes, change its version and re-check its work and tests.
8. Review it on a schedule — every sprint, or before every client review.

Traceability matrix in Jira and Azure DevOps

Jira links work items to each other, and an admin can add link types such as “tests” and “is tested by”. Keep requirements as work items or on Confluence pages, link the stories and test cases to them, and export a filter for the matrix. Test management apps for Jira add their own coverage and traceability reports. More on setting Jira up for this in managing requirements in Jira.

Azure DevOps links requirements to test cases, bugs and code changes. Its documentation says “A fundamental aspect of requirements traceability is association of the requirements to test cases, bugs, and code changes”, and its Requirements quality widget lists each requirement with its test pass rate and failed tests, and shows requirements that have no test (Microsoft Learn).

In both, a link points at a work item as it is now, not at the version of the requirement a test was written against.

Traceability matrix in agile

In agile the chain is shorter: story, acceptance criteria, tests. If the backlog links each story to its tests, those links may be all the matrix a team needs. A matrix earns its place when someone outside the team needs the proof — a regulator, an auditor, or a client paying for the work: “Any client who doesn’t want traceability is a concern IMO” (r/projectmanagement, 2026).

Where the spreadsheet breaks

The matrix is kept by hand, and it is only as current as the last person who updated it. One commenter’s routine: “After EVERY meeting I send out an email with decisions and requirements to the entire team … I copy and paste this into a Word table in the Requirements Traceability Matrix and Decision Log” (r/businessanalysis, 2024).

• Nothing flags a change. When a requirement’s wording changes, its row does not tell the tests written against the old wording.
• It is a copy. The requirements live in one place, the work in another, the tests in a third; the matrix is a fourth that has to be kept in step with all three.
• It answers “now”, not “then”. Which version of the requirement did this test check? The sheet keeps only what it says today, unless you keep its history too.

Use it anyway when proof is needed; it is better than nothing. Keep the review schedule, and treat an empty cell as a question for this week, not the end of the project. When requirements drift from the work, the matrix is one of the places it shows — see spec drift.

Where Specroot fits

This is the problem Specroot works on: traceability kept by the links between requirements, work and tests themselves rather than by a sheet updated by hand, so a change shows what it touches. Specroot for agencies and consultancies.