Requirements Traceability Matrix: Build One Row by Row (Full Example)
"Did we build everything we promised? Did we test it?" A requirements traceability matrix answers that in one table. In this video I build one row by row for a made-up online shop's gift cards: the four kinds of link the BABOK Guide names (derive, depends, satisfy, validate), backward and forward tracing, the six columns, six steps from goal to test, how it finds a missing test and an extra feature, how it shows the impact of a change, and the 5 mistakes to avoid.
Step by step
Not paperwork: a set of links
- A traceability matrix is a set of links, not paperwork. Each requirement links back to why it exists, and forward to what built it and what tested it. The BABOK Guide from the IIBA covers this in its Trace Requirements task. The example here is an online shop adding gift cards.
Explain like I'm 5: tracking a parcel
- Think of a parcel with a tracking number. Each scan is a link: back to the warehouse it left, and forward to the truck or your door. A matrix does the same for requirements: back to the goal and the person who asked, and forward to what was built and the test that checks it.
Four kinds of link (BABOK)
- The BABOK Guide names 4 kinds of link. Derive: a requirement comes from another one. Depends: one needs another, as using a gift card needs buying one first. Satisfy: a story or screen meets it. Validate: a test checks it. The first 2 link requirements; the last 2 link them to the work.
How much to trace? Decide first
- First decide how much to trace, because the effort grows with the number of requirements and how formal you make it. Here: the chain is goal, requirement, user story, test; it lives in one shared table; the BA owns it; every change is traced the same day. A bank or hospital may need far more.
The question nobody could answer
- The gift cards go live in 1 week. The sales manager asks: did we build everything we promised, and did we test it? Nobody can say. The requirements sit in a document, the stories in Jira and the tests in a spreadsheet, with no links between them.
Two directions: backward and forward
- Backward tracing asks why a requirement is here: who asked for it, and which goal it serves. Forward tracing asks where it went: which story built it, and which test checks it. Backward stops extra work sneaking in. Forward stops promised work falling out.
Columns 1-3: the backward side
- Columns 1 to 3 are the backward side. Column 1: the ID, a short unique code. Column 2: the requirement in one clear sentence, such as "A shopper can buy a digital gift card". Column 3: the source, meaning the goal and who asked: grow holiday sales, asked for by the sales manager.
Columns 4-6: the forward side
- Columns 4 to 6 are the forward side. Column 4: the build, the story or design that satisfies it, here story 101 in Jira. Column 5: the test that validates it, like test 1: buy a $50 gift card and check the order. Column 6: the status: not started, built, passed or failed.
Step 1: start from the goal
- Step 1: write down why the project exists. The goal is to grow holiday sales with gift cards. Under it goes the sales manager's business requirement: shoppers can buy and use gift cards online. If you can't write the goal in one sentence, stop and ask.
Step 2: one row per requirement
- Step 2: one row per requirement. 1: buy a digital gift card. 2: email the code to the receiver. 3: use it at checkout. 4: show the remaining balance (service agents). 5: cards expire after 3 years (finance). Requirement 3 depends on 1, and 2 depends on 5, as the email shows the expiry date.
Step 3: link the build
- Step 3: link each requirement to the story that satisfies it: 101 the gift card page, 102 the gift card email, 103 the gift card box at checkout, 104 the balance check, 105 the expiry rule. A requirement that needs 2 stories lists both. A story that covers 2 requirements appears in both rows.
Step 4: link the tests
- Step 4: link the tests. Test 1: buy a $50 card and check the order. Test 2: the email arrives with a working code. Test 3: pay part of an order with a card. Test 4: a card 3 years and 1 day old is refused. Add the last run's status: all 4 passed. But requirement 4 has no test.
Step 5: trace forward to find gaps
- Step 5: go down the matrix looking for empty cells. Requirement 4 has story 104 but no test. Test 5 spends $30 of a $50 card and checks the balance shows $20. It fails: the balance still shows $50. Without the matrix, that bug would have gone live.
Step 6: trace backward to find extras
- Step 6: take every story in Jira and ask which requirement it satisfies. Story 107, a spinning gift box animation, points to none. It costs 2 days and needs a test, so take it to the sales manager: give it a real requirement and source, or remove it. Here, it comes out.
Worked example: the finished matrix
- The finished matrix has the goal at the top and 5 rows: 1, story 101, test 1; 2, story 102, test 2; 3, story 103, test 3; 4, story 104, test 5 (passed after the fix); 5, story 105, test 4. Every row traces back to the goal and forward to a passed test.
A change comes in: impact in minutes
- 2 days before launch, finance changes the expiry from 3 years to 5. Follow requirement 5's row: change story 105 and rewrite test 4. Requirement 2 depends on 5 because the email shows the expiry date, so test 2 gets checked again too. That is impact analysis in minutes.
Where the matrix lives
- The matrix can live in an Excel sheet with one row per requirement, in Jira with stories and tests linked to requirements, or in a Confluence table. Update it the same day something changes, and check it before every release. A stale matrix is worse than none, because people still trust it.
5 common mistakes
- 5 mistakes to avoid: building it at the end to tick a box; tracing everything, even emails and meeting notes; tracing only one way; letting it go out of date; and links with no status, because a linked test that was never run proves nothing.
Recap
- Recap: 4 kinds of link (derive, depends, satisfy, validate), 2 directions, 6 columns (ID, requirement, source, story, test, status) and 6 steps: start from the goal, one row per requirement, link the build, link the tests, trace forward for gaps, trace backward for extras.
Common mistakes
- Building the matrix at the end. Filled in the week before launch, it only ticks a box and catches nothing in time. Add each row when the requirement is agreed, and link the story and test as they are created.
- Tracing only forward. Forward tracing finds requirements with no story or test, like requirement 4's missing balance test. Only backward tracing finds extras like story 107, the animation nobody asked for. Do both.
- Linked tests with no status. A test ID in the row doesn't prove the requirement works. Record the result of the last test run (passed or failed) so a failing test, like test 5, stands out.
- Letting it go stale. An out-of-date matrix says everything is fine when it isn't. Trace every change the same day, and check the matrix before every release.
When a business analyst uses this
When a change request lands late, such as finance moving gift card expiry from 3 to 5 years, the BA follows requirement 5's row to list the story to change and the tests to rerun. They also follow its depends links to related requirements, then take that impact list to the sponsor before sign-off.
Questions people ask
What is a requirements traceability matrix?
It is a table with one row per requirement that links the requirement back to its source (the goal and who asked) and forward to the story that built it and the test that checks it. A common set of columns is ID, requirement, source, story, test and status.
When is a requirements traceability matrix created?
Start it at the beginning of the project, from the goal, and add rows as requirements are agreed. Building it at the end just to tick a box means gaps and extras are found too late.
What is a requirement traceability matrix used for in testing?
It shows which requirements have a test and whether that test passed. An empty test cell points to something nobody checked, like a balance feature that turned out to be broken.
