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 stop the same request coming back in month three.
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: build can start on the agreed rows, and one decision is blocking a must-have. 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. You should not start user acceptance testing while a must-have row is still in conflict.
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.