Start now
Back to Blog

Practical Guide•November 4, 2026•14 Min Read

Requirements Traceability Matrix: Template and Examples

Hand-drawn matrix details framing the title

A requirements traceability matrix (RTM) is a table that links each requirement to its source, planned work, verification check and result. Each row lets you ask where the requirement came from, how the team plans to deliver it, and what evidence shows whether it was verified. The U.S. Department of Health and Human Services describes traceability as tracking where each requirement is satisfied across the lifecycle, from stakeholder needs through design, coding, testing and implementation.

Below you will find the columns that matter, a worked example you can copy, and a routine for keeping the matrix current once the project moves.

TL;DR

  • An RTM maps each requirement forward to design, tasks and tests, and backward to the stakeholder need or contract clause that created it.
  • Start with a short core: requirement ID, source, description, status, deliverable or task, test and result. Add columns only when someone will use them.
  • Build it at project start, give it one owner, and review it at each phase gate or major review.
  • Empty cells show work to review. Filter the matrix for requirements without checks, then compare a full test inventory against requirement IDs to find tests with no link back.
  • The same logic works outside software: any project with a written scope can trace each scope line to a deliverable and an acceptance check.

Table of Contents

What a requirements traceability matrix does

A requirements list tells you what the client wants. A traceability matrix tells you what happened to each item on that list.

The Project Management textbook from Cleveland State University says teams use an RTM to link requirements to activities and deliverables and to show how requirements relate to each other. That in turn supports scope, change, risk, time, cost and communication management.

In practice, the matrix helps with four jobs:

  1. Coverage. See which requirements have planned deliverables and verification checks, and which still need them.
  2. Impact analysis. When a requirement changes, inspect linked tasks and tests before revising the plan or estimate.
  3. Accountability. Record an owner and status so the team can resolve open items at review.
  4. Audit evidence. The U.S. Department of Energy's software quality guidance treats the matrix as a way to show how and why a product satisfies its requirements.

For another discussion of test links, see this further reading on requirements traceability in UAT.

Forward, backward and bidirectional traceability

The three types differ only in the direction you trace.

  • Forward traceability starts at a requirement and follows its links to design, build and verification. A missing link prompts a coverage review.
  • Backward traceability starts at a deliverable or test and follows its link to the requirement behind it. An unmatched item prompts a scope or documentation review.
  • Bidirectional traceability does both. NASA's Software Engineering Handbook says it helps ensure that specified features are tested and also identifies tests that do not correspond to any requirement.

Choose the directions and detail your project needs. A small client project may use a simple spreadsheet; formal verification work may require more links and evidence.

What to include in your RTM

There is no single required way to represent the links. HHS states that no formal standard prescribes how a traceability relationship must be built, so stakeholders should agree early on what is traceable, which links are required, and who maintains them.

The Cleveland State chapter lists these fields as typical RTM content: requirement ID, associated or parent requirement ID, category, description, current status and status date, business rationale, project objective, WBS number, design ID, build ID, and test strategy or scenarios.

That list is a menu, not a mandate. Here is a way to sort it.

Column What it holds Keep it?
Requirement ID A unique, never-reused identifier Always
Source Stakeholder, contract clause, regulation or meeting Always
Description One testable sentence Always
Parent ID The higher-level requirement it comes from When you have tiers
Priority Must, should or could Usually
WBS or task ID The work package that delivers it Always
Design or build ID The artifact that implements it Software and technical work
Test ID The check that verifies it Always
Verification method Test, inspection, demonstration or analysis When verification is formal
Status and status date Where it stands and when that changed Always
Result Pass, fail or partial Always
Change reference The change request that altered it Whenever scope can move

The FAA's verification traceability guidance is a good model of a formal version. It specifies requirement ID and text, parent and higher-level traces, activity ID, test-case ID, verification method, run date and test result, with results recorded as Pass, Fail or Partial.

A requirements traceability matrix example

The table below is an illustrative example for a small web project: a client portal for a design studio. The IDs and values are invented to show the structure.

Req ID Source Requirement Priority Task ID Design ID Test ID Status Result
REQ-001 Client brief, section 2 Clients can log in with email and password Must T-12 UI-03 TC-001 Verified Pass
REQ-002 Kickoff meeting Clients can download approved proofs as PDF Must T-18 UI-07 TC-004 Verified Pass
REQ-003 Client brief, section 4 Clients can comment on each proof Should T-21 UI-08 TC-005 In test Partial
REQ-004 Change request CR-02 Proofs can be approved by two reviewers Could T-27 UI-11 None yet Designed Not run
REQ-005 Contract, clause 6 Portal pages load within the agreed time; threshold and test conditions to agree Must None yet None yet None yet Open Not run

Read it the way a reviewer would. REQ-005 needs a measurable response-time threshold and test conditions agreed with the client, as well as task, design and test links. REQ-004 has a task and design but no test. REQ-003 has a Partial result, so its remaining check stays open.

To trace backward, start with a separate inventory of all test cases and compare their linked requirement IDs with the matrix. A test with no requirement link deserves review: it may reflect a missing requirement, a general quality check, or work outside the agreed scope. NASA notes that one requirement may trace to several test procedures and one test procedure to several requirements. In a spreadsheet, use multiple IDs in one cell or one row per link, as long as the relationship stays clear.

How to create a requirements traceability matrix

The steps below follow NASA's guidance in SWE-052: create the matrix at the start, identify its elements uniquely, capture requirement sources, maintain it throughout, assign an owner, keep it electronic and sortable, and review it at major phases.

  1. Agree what is traceable. Decide whether you trace business needs, functional requirements, deliverables, tests, or all of them. Write the rule down in one paragraph.
  2. Collect requirements in one place. Pull them from the brief, contract, meeting notes and emails. Split compound statements so each row holds one testable item.
  3. Assign unique IDs. Never reuse an ID, even for a deleted requirement. Mark it withdrawn instead.
  4. Record the source. A requirement without a source cannot be defended in a change discussion.
  5. Link each requirement to deliverables. Connect it to a WBS item, task or design element. If the work is not planned yet, leave the cell empty on purpose.
  6. Link each requirement to verification. Name the test, inspection or acceptance check, and the method.
  7. Name an owner. NASA recommends assigning one team member responsibility for creating and maintaining the matrix. On a small team this is usually the project manager or delivery lead.
  8. Set a review rhythm. Check it at each phase gate, before client sign-off, and whenever a change request is approved.

Where to find a template

A template is a starting point. For another requirements-management reference to inspect, see the EPA's Requirements Management Procedure. Choose columns based on the links and evidence your own project needs.

In plain terms: copy the table above into a spreadsheet, delete columns you will not maintain, rename the rest to match your own vocabulary, and add a short legend at the top. Keep it sortable so you can filter by status, by owner, or by rows with empty test cells.

Freelancer filtering spreadsheet rows at a laptop

Keeping the matrix alive

A matrix is useful when its links reflect the current project. Three habits help:

  • Update when something changes. Record a new requirement, approved change or test result while the decision and evidence are at hand.
  • Record the change, not just the result. HHS lists requirement-change history among the things an RTM should provide, along with unique IDs, bidirectional links, allocation rationale, accountability and verification. Note the date, the reason and who approved it.
  • Treat empty cells as a to-do list. Filter for blanks before every review and assign the open links to an owner.

PMI contributor Orlando Marone makes a related point in his paper on requirement traceability: the matrix should point reviewers to evidence for each requirement across design, code and testing. It does not replace your quality processes. A row marked "verified" should link to something a reviewer can open.

Does an RTM work in Agile projects?

Yes, in a lighter form. Agile teams still need to know that each story ties to a need and that each acceptance criterion was checked. The difference is granularity and speed.

A practical Agile version looks like this:

  • The row is an epic or user story, with its ID from your backlog tool.
  • The source column points to the business goal or client request behind it.
  • Acceptance criteria describe the expected outcome; the test column links to checks actually run and their results.
  • Status follows the sprint board, so you are not typing it twice.

Avoid a separate document that needs hand-copying from the board. If your backlog tool shows stories, goals, checks and results together, a separate matrix may be unnecessary. Otherwise, a small spreadsheet can support sprint or release reviews.

Beyond software: tracing scope in creative and service projects

Traceability is usually taught with software and engineering examples, but the logic carries over to any client project with a written scope. A brand identity, a website build, an integration or a campaign can link commitments in a brief to deliverables and acceptance checks. Hours and price belong in the project plan and quote.

The mapping is straightforward:

Software RTM Creative or service project equivalent
Business requirement Client objective in the brief
Functional requirement Deliverable or feature in the scope of work
Design and build ID Task, phase or milestone
Test case Review check and recorded acceptance result
Change reference Approved change request

For example, a packaging studio could link a brief's print-ready label requirement to an artwork task and a recorded prepress review. A revision round is part of the workflow; the review result is the evidence to record.

If you are building that scope document, our scope of work template and guide to milestones and deliverables cover the front half of the chain. For the back half, change request templates with scoped estimates show how to price a change before it enters the matrix. Technical projects also benefit from a clear software integration scope and estimate, and a roles and responsibilities template settles who owns each row.

Our perspective

A useful RTM makes an agreement reviewable: you can point from a requirement to planned work and then to the check that confirms its outcome. For a small project, a maintained spreadsheet may be enough. Keep the matrix alongside the plan and quote so a change prompts a deliberate review of affected tasks, hours and price.

Roadbase can help with that planning step. Paste a brief or attach a PDF, then review and adjust an editable draft of phases, tasks, roles and estimated hours. Price those hours by role and review costs, expenses, contingency and target margin before exporting a proposal PDF. Keep requirement-to-check links and verification evidence in the matrix.

Turn a brief into a traceable, priced scope

Have a brief or notes ready to turn into a plan? Start with Roadbase: paste the brief or attach a PDF, review the draft phases, tasks, roles and hours, then adjust the quote and export a proposal PDF. Keep your RTM beside that plan so each requirement has its own delivery and acceptance trail.

Roadbase

See current options on the Roadbase pricing page. If you quote software work, our page on software consulting estimates and quotes shows how this applies to your projects.

FAQ

What is a requirements traceability matrix in simple terms?

It is a table that records where each requirement came from and links it to planned work, a verification check and the result. Missing links show what needs review.

Who is responsible for the requirements traceability matrix?

One named person should own it. NASA recommends assigning a project team member responsibility for creating and maintaining it. On small teams that is typically the project manager, business analyst or delivery lead, while others supply updates for their rows.

When should you create an RTM?

At the start of the project, as soon as you have a first list of requirements. NASA's guidance is to create it early and maintain it throughout, reviewing it at major phases or key reviews. Building it late means reconstructing links from memory.

How detailed should an RTM be?

Only as detailed as the people using it will keep current. HHS notes that stakeholders should agree early on what is traceable and which links are required. A small project may need seven columns; a regulated one may need verification methods, run dates and results.

Is a spreadsheet enough for an RTM?

For a short requirements list with a single owner, yes, if it is sortable and kept current. As requirements, tests and changes multiply, use a format that makes links and evidence easy to review.

Sources