Free Requirements Traceability Matrix (RTM) Template

This Requirements Traceability Matrix (RTM) template is used by business analysts to prove every requirement gathered from stakeholders is actually designed, built, and tested — with nothing lost and nothing added that was never asked for.

What Is a Requirements Traceability Matrix?

A Requirements Traceability Matrix links each individual requirement in both directions: backward to the business need or BRD section that justifies it, and forward to the design element, build task, and test case that verifies it was delivered correctly. The result is a single table a BA can use to answer two questions at any point in a project — has this requirement been built, and has it been tested — without chasing separate design docs and test plans to find out.

What Should an RTM Include?

• Requirement ID — a unique reference so it can be cited anywhere else in the project (design docs, test scripts, change requests)
• Requirement description — the actual requirement, in the same wording used in the BRD it traces back to
• Source — which stakeholder, workshop, or BRD section this requirement originated from
• Priority — usually MoSCoW (Must/Should/Could/Won’t), so scope trade-offs are traceable too
• Design/build reference — the design document, user story, or ticket that implements it
• Test case reference — the specific test case ID that verifies it, and its pass/fail status
• Status — where the requirement currently sits (not started, in design, built, tested, signed off)

Traceability Matrix vs Requirements Register — What’s the Difference?

These two get used interchangeably but answer different questions. A Requirements Register is simply the list of requirements — what was asked for, by whom, at what priority. An RTM takes that same list and adds the links in both directions: back to the business justification, and forward to the design and test evidence. A register can tell you requirements were captured; only an RTM can tell you they were actually delivered and proven — which is why sign-off conversations rely on the RTM, not the register alone.

Common Mistakes When Building an RTM

• Only tracing forward. Linking requirements to test cases but never back to the original business need makes it impossible to spot scope creep — features built that nobody actually requested.
• Treating it as a one-off artifact. An RTM finished at sign-off and never touched again is out of date the moment the first requirement changes. It needs updating alongside design and test work, not after the fact.
• No test case reference. An RTM that stops at “design reference” can’t actually prove a requirement was tested, which is usually the whole point stakeholders need it for at go-live.
• Wrong granularity. Too coarse (one row per feature) hides gaps; too fine (one row per trivial sub-clause) makes the matrix unmanageable. Match the grain of the RTM to the grain your test cases are actually written at.

What’s Included in This Template

• Pre-structured sections with guidance notes
• Worked examples from real BA projects
• Guidance for Agile, waterfall, and hybrid approaches
• Easy to adapt to your organisation’s standards

How to Use This Template

Set up the RTM as soon as requirements are first captured, not after design starts — retrofitting traceability onto requirements that already have no ID scheme is far harder than building it in from the start. Update it at every stage gate: when a requirement changes, when design starts, and when each test case is written and executed.

An RTM traces requirements captured in your Business Requirements Document through to delivery — every row should map back to a specific BRD section. Risks or open questions that surface while tracing requirements often belong in a RAID Log too, so they’re tracked with a named owner rather than left as a comment in the matrix.

Why Requirements Templates Matter

Consistent documentation is one of the most underrated BA skills. A well-structured document:

• Sets clear expectations from day one
• Reduces “we didn’t know that was in scope” conversations
• Creates an audit trail for decisions and changes
• Speeds up new team member onboarding
• Builds your credibility as a professional BA

Browse All Free Templates

Our free BA template library covers 15 core documents. For 175 practitioner-level templates covering the full BA lifecycle, see our BA Toolkit — Complete Pack. Free account required for the library, no payment.

Want to Master These Tools?

Templates are a starting point. Our BA training courses teach you how to apply them in real projects — with exercises, feedback, and examples from experienced BAs. Start with our free intro course.

Frequently Asked Questions

What is a Requirements Traceability Matrix used for?

It links each requirement back to the business need that created it and forward to the design and test case that proves it was delivered — so nothing is lost and nothing is built that wasn’t requested.

What is the difference between an RTM and a Requirements Register?

A register just lists requirements. An RTM adds links in both directions — to the business justification and to the design/test evidence — so it proves delivery, not just capture.

Does an RTM need to be updated throughout the project?

Yes — it needs updating whenever a requirement changes or a test case is written or run, or it quickly goes stale and stops being a reliable coverage record.

Benjamen Walsh

Founder, BBA Institute · Certified Business Analyst

Benjamen Walsh is the founder of the Better Business Analysis Institute (BBAI) and a practising business analyst with over a decade of experience delivering change across New Zealand and Australia. He has trained over 200+ business analysts through BBAI certification programmes and hosts The Better Business Analyst Podcast (138+ episodes). Benjamen works with organisations including Corporates, Consultancies, Non for Profits, Small Businesses and the New Zealand Government.

Connect on LinkedIn →