A requirements traceability matrix lists each requirement with the need behind it, who raised it and when, a named owner, the evidence that will prove it works, and its status. The rows to act on are the ones in conflict and the must-haves with no agreed acceptance evidence.
What a requirements traceability matrix is for
A traceability matrix connects each requirement to three things: the person who needs it, the owner who will accept it, and the evidence that will prove it works. Its real job is to show the rows where one of those links is missing, because those are the requirements that cause arguments at testing and go-live.
We recommend these columns:
| Column | What goes in it |
|---|---|
| ID | A stable identifier, never reused |
| Need | The business problem, in the words of the person who has it |
| Source | Who said it, where and when |
| Requirement | What the system must do, written so someone could test it |
| Priority | Must, Should, Could or Won't |
| Owner | The person who accepts it as met |
| Acceptance evidence | What will be shown to prove it works |
| Status | Proposed, Agreed, In conflict, Rejected or Changed |
| Decision note | Why it was agreed, rejected or changed, and by whom |
The free traceability matrix template has these columns, drop-downs, a count of conflicts and of must-haves with no acceptance evidence, and a completed example. No sign-up.
How to build one from interviews and workshops
- Write the need before the requirement. "Sales managers cannot see which deals are stuck" comes first. The feature comes second.
- Record the source every time. A name, a meeting and a date. A requirement nobody can trace is an opinion.
- Make each requirement testable. If you cannot say how it would be tested, it is not finished.
- Name one owner and their acceptance evidence. The person who will say "yes, that works", and what they need to see.
- Mark conflicts instead of averaging them. When two people want different things, both views stay visible until someone with authority decides.
- Keep rejected rows. With the reason and who decided. They preserve the decision if the same request returns.
A worked example
Illustrative: a CRM replacement at a made-up company.
A consultant runs interviews and a finance workshop, then builds the matrix. Six rows, 4 agreed, one in conflict and one rejected.
| ID | Requirement | Source | Priority | Owner | Status |
|---|---|---|---|---|---|
| R-01 | Show deals with no activity for 14 days on the pipeline view | Sales director interview, 3 Mar | Must | Sales director | Agreed |
| R-02 | Send won deals to billing with customer, price and terms | Finance workshop, 5 Mar | Must | Finance manager | Agreed |
| R-03 | Log a call from the mobile app in under 30 seconds | Rep survey, 7 Mar | Should | Sales operations lead | Agreed |
| R-04 | Discounts over 15% need approval in the system | Sales director interview, 3 Mar | Must | Sales director | In conflict |
| R-05 | Score every contact from 0 to 100 | Marketing lead email, 8 Mar | Could | Marketing lead | Rejected |
| R-06 | Show the signed order form and handoff notes on the account | Customer success interview, 6 Mar | Must | Head of customer success | Agreed |
R-04 is in conflict. Finance says the limit should be 10% (workshop, 5 Mar). Sales director and finance manager to settle before build. The matrix does not pick a side. It records both, and who will decide.
R-05 is rejected. No agreed scoring model and no one to maintain it. Rejected by the sponsor, 12 Mar; revisit after go-live.
What this shows: four rows have an agreed status, and one decision is blocking a must-have. Check dependencies and delivery readiness before authorising build. What it does not show: whether the list is complete, or which side of the discount conflict is right. Those need the people, not the spreadsheet. Keep tests that depend on the disputed rule on hold until its owner records a decision.
Resolve a requirement with missing evidence
A 48-second silent walkthrough using synthetic examples. Captions are included in the picture; the full explanation follows below.
Download the video (MP4) ยท Download captions (VTT)
Walkthrough transcript
Silent walkthrough. All examples are synthetic.
A numbered requirement can still be unresolved. Follow it back to the stated need and forward to observable acceptance evidence.
A score on a screen is not enough. The row needs an agreed scoring model and evidence that the result serves the intended decision.
In this synthetic case, the sponsor rejected the requirement because no model was agreed and nobody would maintain it.
Keep the rejected row and its reason. Deleting it would hide why the request was not included and invite the same disagreement later.
If the need returns, define the model, maintenance responsibility and acceptance evidence first. Record a new decision instead of assuming approval.
Use the blank and completed matrix together. Find the missing link, record what remains unknown, and decide what evidence to gather next.
Which requirements still need agreement?
Before build starts, every requirement should trace to someone who needs it, an owner who will accept it and the evidence that will prove it. The rows that cannot are the ones to settle.
Your starting question: Which decisions and requirements need agreement, and what supports them?
Start by checking
- Whether every requirement traces back to a named person and a dated source.
- Which requirements conflict, and who has the authority to settle each one.
- Which must-have requirements have no agreed acceptance evidence yet.
Evidence to gather
- Interview and workshop notes, with dates.
- The documents requirements were taken from.
- Each owner's answer on what they will accept as done.
Not established yet
- Which side of each conflict is right.
- Whether the list is complete.
- What each requirement costs to build.
Mistakes that make a matrix useless
- Requirements with no source. When they are challenged, nobody can say who asked for them or why.
- Averaging a conflict. A 12.5% discount limit satisfies neither sales nor finance, and hides that a decision was needed.
- Deleting rejected requests. The request comes back, and the reason it was refused is lost.
- Acceptance evidence left for later. A must-have with no agreed test becomes the argument at user acceptance.
Check the links in both directions
Forward traceability starts at the source need and follows it to the requirement and acceptance evidence. For R-02, follow the finance workshop request to the won-deal billing requirement and the evidence the finance manager will accept. Backward traceability starts at the test or delivered behaviour and asks which agreed need it serves. Bidirectional traceability means both checks work; a filled row alone does not prove that they do.
When testing begins, keep an optional UAT reference, test result and evidence location beside the agreed acceptance criterion, or in a linked test register keyed by requirement ID. Record the agreed baseline and later change decision without overwriting why the earlier version was accepted. These are additions for a testing workflow, not compulsory columns for the first interview.
When a spreadsheet is enough
A spreadsheet can support a bounded set of requirements when named owners can review changes and links reliably. Move to a controlled workflow when concurrent changes, permissions, version history or links across releases cannot be maintained safely. Choose that workflow from the actual review and evidence needs; a different tool does not settle R-04's disagreement or make R-05 justified.
When agreed requirements become delivery promises, carry the owner and acceptance evidence into the sales-to-customer-success handoff. Keep disputed and rejected requests visible so the receiving team can distinguish commitments from unresolved proposals.