Stop 03 · Requirements Analysis & DocumentationTopics · 6/10

Requirements Traceability Matrix (RTM)

In short

Three months into a project, someone asks 'Why are we building this?' or 'Was this ever tested?' A traceability matrix answers both in seconds, without anyone digging through old emails.

A document tracking each requirement from its origin through design, development, and testing — ensuring nothing gets lost or forgotten, and providing a clear audit trail when questions arise.

The purple blob holds a parcel with a tracking tag beside a small conveyor of boxes.

Think of it like this

Tracking a courier parcel

Every courier parcel gets scanned at pickup, at the hub and at delivery. If it goes missing, you know exactly where it was last seen. An RTM scans every requirement the same way: from business need to design to test.

Watch it happen

Tracing one requirement end to end

BR-01

FR-1.1

SCR-04

TC-11

Release

1/5BR-01: 'Customers must see their refund status without calling support.'

The big ideas

What you need to know

Forward and backward

Forward: is every requirement designed and tested? Backward: does every feature come from a real business need?

Find gaps early

A requirement with no test case, or a feature with no source requirement, shows up as an empty cell.

Impact of change

When a requirement changes, the RTM shows which designs and tests must change too.

A spreadsheet is enough

Many teams keep the RTM in Excel or Sheets. Tools like Jira can link stories to tests as well.

See it in code

Walk through the code

text

1Req ID | Source   | Design | Test case | Status2BR-01  | Ops head | -      | -         | Approved3FR-1.1 | BR-01    | SCR-04 | TC-11     | Passed4FR-1.2 | BR-01    | SCR-04 | TC-12     | Failed5FR-2.1 | BR-02    | API-07 | (none)    | At risk6FR-3.1 | (none)   | SCR-09 | TC-20     | Question

1/4Columns go from origin to proof: source, design, test and current status.

A tiny RTM. Each row links a requirement to where it came from, how it's designed and how it's tested.

Save yourself the pain

Common mistakes

Oops

Building the RTM once at the start and never updating it.

Do this instead

Update it whenever requirements, designs or tests change. A stale RTM is worse than none.

Oops

Tracking so many columns that nobody fills them in.

Do this instead

Start with ID, source, design, test and status. Add columns only when someone needs them.

Your mission

Build an RTM in Sheets

~30 min

Quick check

Your RTM shows a feature with no linked business requirement. What does that suggest?

Go deeper

1Build a simple RTM linking 5-8 requirements to their source, design, and test case.
2Learn why an RTM is especially valuable in regulated or compliance-heavy industries.
3Practice updating an RTM as a requirement changes mid-project.