Requirements Traceability Matrix: Example and How to Maintain It

The requirement changes on Friday evening. The customer asks to also send order status updates via SMS — email is not enough. The team lead asks a sensible question: what will break? And it turns out there is no one to answer. The analyst remembers the email, the tester remembers their test cases, the developer remembers the service that calls the gateway. No one holds the whole picture in their head.

The requirements traceability matrix holds that picture for you. In it, each requirement is linked upward — to where it came from — and downward — to where it is implemented and how it is verified. You can read it in both directions: from a business goal to a test case and back.

At interviews, it is asked about often, but the answer is usually half: “a table where requirements are mapped to tests.” That is true. But it is the most boring half, and it immediately shows that the person saw the matrix on a slide rather than maintained one.

What it actually links

The definition from ISO/IEC/IEEE 29148:2018 — the international standard for requirements engineering — sounds dry but is precise: traceability is the identification and documentation of the derivation path upward and the allocation/flow-down path downward within a requirements set. The standard calls a requirement from which another is derived the parent, and the derived one the child.

The standard then lists where a requirement must trace: downward — to lower-level requirements, to architecture, to the system elements that implement it, and to verification entities that check it; upward — to parent requirements from which it is derived or to stakeholder needs.

The matrix itself is described in the standard by a separate term: a structured information artifact that links requirements to their higher-level requirements or needs and to lower-level implementation.

Here it is worth distinguishing two words that often get confused in conversation. Traceability is a property: links between requirements exist and are maintained. The matrix is a form in which it is convenient to show them. You can maintain traceability without a single table, or you can have a nice table without traceability — if it records what no longer exists.

Each direction answers its own question. Upward — “why are we doing this”: every requirement must stem from someone’s need, otherwise it was invented along the way. Downward — “did we do this”: the requirement has code that implements it and a check that confirms it.

The matrix is not box-ticking reporting. It is the only place where the question “what will break” gets answered in a minute, not in a day.

Example: five rows to start with

An online store. The quarter’s goal is to offload support: there are too many “where is my order” inquiries.

Five rows, five columns — that is already enough for the matrix to start working. There can be more columns: priority, owner, version, status. But extra columns are convenient to add to a live matrix and pointless to design in advance.

Let’s return to Friday’s request about SMS. You look at row FR-13: above it is SH-4, below — the email template and one test. That means a sibling FR-13 gets added, not an edit to FR-12; the screen stays untouched, NFR-3 about five minutes remains in force and extends to the new channel. Answering the team lead took a minute.

Notice row BG-1. Its implementation column is empty — and that is normal: a business goal is not implemented in code, it is verified by a metric. An empty cell here means a boundary, not a hole.

What BABOK says about traceability

In BABOK, traceability is not a technique but a separate task: 5.1 Trace Requirements in the Requirements Life Cycle Management knowledge area. That is also where relationship types are named. There are exactly four: derive, depends, satisfy, and validate.

• Derive — one requirement is derived from another; they are at different levels of abstraction. FR-12 is derived from SH-4.
• Depends — a requirement depends on another. Two subtypes: necessity, when implementing it alone is pointless, and effort, when you can, but doing them together is cheaper.
• Satisfy — a link between an implementation element and the requirement it fulfills. The status service satisfies FR-12.
• Validate — a link between a requirement and the test case that confirms the solution meets the requirement.

The difference between necessity and effort is a deeper-level question, and it usually shows whether the person has maintained traceability or is retelling a chapter.

The guide itself views traceability more broadly than “linking a requirement to a test.” Task 5.1 exists so you can manage scope and the risk of it creeping, find gaps, assess the impact of changes, understand the status of each requirement, and allocate requirements across releases and components. It’s a management tool, not a documentation one.

Inside the task there are three elements: level of formality, the links themselves, and the traceability repository. The first one is the main one, and it’s also the most mature answer the guide gives to the whole topic. BABOK nowhere requires you to trace everything. It requires you to consciously decide once what gets traced and to what level — because links cost time, and traceability here isn’t a virtue but an investment with a price and a payoff.

The guide doesn’t name any tools at all, and that’s deliberate. It says exactly one thing about the traceability repository: in complex cases, it gets automated. The third edition came out in 2015 and is still relevant today — expecting it to list modern systems is pointless, it sets the rules, not the products.

About the BABOK guide itself and why an analyst needs it — in the article What is BABOK and how we use it.

What it catches

Three things that make it worth keeping at all.

Orphans. A requirement with no downward link — nobody implemented it and nobody checked it. A test case with no upward link — we are testing something that was not requested. The standard suggests even measuring this: the share of parents without children and the average number of child requirements per parent, with the latter being an indicator of design complexity. In our table, an orphan is visible to the eye: if FR-13 had an empty verification column, the status-change email would go into release untested, and customers would notice.

Change impact. That same Friday with SMS. Without the matrix, the question “what will break” turns into polling three people and still ends with the word “probably”.

Coverage. When the customer asks six months later “did you do this?”, the matrix answers with a row, not with the team’s memories.

How much it costs and when not to do it

Now the honest part, which is rarely said aloud in courses. Links do not appear on their own and do not maintain themselves. Each new row is work that someone does manually and then updates with every change.

The more complex the web of links, the more expensive it is to keep it alive — which is exactly why the guide requires you to set the level of formality upfront, not as you go. The decision is made once, consciously: what we trace, to what level, and with what.

There is one practical piece of advice. Do not create a separate Excel file if the team lives in Jira: links between issues are already traceability, and the matrix is gathered with a filter. A file on disk survives exactly one sprint in which someone forgot to update it. And a dead matrix is worse than no matrix — people reference it, and it lies.

Where to start if there is no matrix

Do not start with history. Rebuilding links across three years of development is impossible, and the attempt will eat a month and end in nothing.

Take the nearest release. List its requirements with identifiers — just number them if there were no IDs. For each, set the source: whose need it is and from which decision it grew. Then — how it is verified. That’s it, the matrix exists.

Then the interesting part begins: some cells will remain empty. That is not a failure of the exercise; it is its result. An empty cell in the source column means a requirement whose purpose is unclear. An empty one in the verification column — something that will go to production unchecked. With these two lists, you can already go to the team meeting, and the conversation there will be substantive.

How it is done today: traceability with a model

The most boring part of traceability is not thinking but matching. Sixty requirements, two hundred test cases, and you need to figure out what relates to what. This is where a language model saves hours rather than pretending to be intelligent.

Three techniques that actually work.

Initial mapping. You give the model a list of requirements and a list of test cases, ask it to link them and return two tables: what matched and what did not. The value is in the second one. It is a ready list of orphan candidates that would take half a day to assemble manually.

Spec review. You ask to find requirements without a source, semantic duplicates, and formulations that cannot be turned into a check. The model reads the whole document and does not get tired by page forty — unlike a human.

Draft impact analysis. “We change FR-13, here is the matrix — what is affected?” The output is a candidate list that you check with your own eyes. Minutes instead of back-and-forth with three colleagues.

Then comes a red line, stiffer than it seems. The model can invent a link that does not exist. A false link is more dangerous than a missing one: an empty cell is visible and raises a question, while a wrong one looks like done work and raises nothing. So the rule is simple: the model proposes — the human confirms. Only what you have verified yourself — by opening the requirement and the test — goes into the matrix.

Requirements management tool vendors embedded this even earlier: their platforms suggest links, assess confidence in them, and mark downstream elements as suspect when an upstream requirement changes. Names and prices differ, the principle is the same.

And here’s the thing I see most often. A tool gets plugged in — and people assume traceability has appeared. It hasn’t: what’s appeared is a repository where nothing has been decided. What we trace and to what level — that’s a decision the model won’t make for you.

Why I trace more than just requirements

The following is a personal opinion, and it is broader than the topic. The value of traceability is not in the table but in the habit of asking two questions: where did this come from and how will I know it worked. The habit transfers anywhere.

The course we are building is assembled exactly this way. Not from a nice table of contents downward, but bottom-up — from a bank of real interview questions. Each module traces to how many questions it accounts for. A module with almost no questions does not make it into the program, no matter how mandatory it looks in other courses. It is the same matrix: upward — a need, downward — material.

The same goes for articles. We have a rule: a topic with no real search demand behind it does not go on the site. The query is written in the article file itself — next to the text, not in someone’s head. This article was also written for a specific query, and in three months one can open the measurement and check whether it worked. An empty “why” cell here means the same as in a project: work done by inertia.

That is why at interviews I trust a candidate who traces anything more than one who recites the four relationship types by heart. The first understands the purpose. The second read a chapter.

How it sounds at an interview

A weak answer is “a table where requirements are mapped to tests.” Formally correct, but the conversation goes no further.

A strong one is shorter than it seems: a link up and down, one example from your own project, the four relationship types if asked deeper. And an honest “on the last project we did not maintain it because the team was four people and everything lived in Jira” is especially valued. That is the answer of a practitioner, not a retelling of a chapter.