September 7, 2026 · 6 min read
TL;DR: The requirements traceability matrix appears in 23 of the bank's answer options: 4 keyed, 19 wrong. The keyed ones all involve a requirement whose linkage has broken, meaning you can no longer tell what connects to what. The wrong ones appear whenever a stem says the word requirements, which is most of the time.
The traceability matrix has a narrow job and a wide reputation. It traces each requirement to its origin and to the deliverable that satisfies it. That is genuinely useful, and it is useful for exactly one class of problem.
A lost view of requirements across artefacts. Two items show it precisely.
Two merging companies combine an agile software project from one side and a predictive electronics project from the other into a single hybrid project. Two months later, requirements have changed on both sides and nobody can say what the full set is, what state each requirement is in, or how important it is.
Keyed: build a requirements traceability matrix spanning the product backlog and the requirements specification. The matrix reaches across both artefacts and restores a single view of every requirement's status and importance, which is precisely what was lost. The distractors are all attempts to make one side become the other. A new master WBS only serves the predictive side. Folding the specification into the backlog, or the backlog into the specification, forces one track to work the other's way in order to solve a reporting problem.
The second is a conflict. A project manager asks a client to clarify an ambiguous requirement, and the written answer describes behaviour that directly conflicts with a related requirement the operations director signed off earlier. Keyed: trace both requirements on the matrix and bring the conflict back to the client and the operations director together.
Both halves matter. The matrix shows exactly what each requirement commits to and where they diverge; bringing that to both stakeholders gets one reconciled answer instead of the project manager guessing which stakeholder outranks the other. Implementing the newest clarification assumes recency wins. Implementing the earlier signed-off version assumes approval order wins. Asking a business analyst to decide hands a stakeholder disagreement to someone with no standing to settle it.
Whenever requirements are mentioned but linkage is not the problem.
| Scenario | The real problem | Keyed instead |
|---|---|---|
| A dozen dispersed teams, thousands of stakeholders, anxious executives | Nothing reaches the executives regularly | The communications management plan |
| Product owner has written all the stories into the backlog | What happens next in the agile cycle | Order by business priority, pull into an iteration, complete, remove |
| Landscape architect unsure what they are meant to build | Which document describes the work in detail | The WBS dictionary |
| Requests arriving, unclear which need formal approval | Which artifacts are under baseline control | The configuration management plan |
The executive item is the most instructive. A programme with nearly a dozen dispersed teams and thousands of affected stakeholders has executives anxious about the changes and pushing back on planning. Building a traceability matrix to trace the executives' requirements is offered. It loses to writing the communications management plan, because the anxiety is being fed by how little reaches the executives and how irregularly. Their requirements are not untraced. Their information needs are unmet.
Common trap: treating the traceability matrix as the document that tells someone what to build. A landscape architect on a botanical garden redevelopment does not know exactly what they are meant to be working on, and the item asks which document gives a detailed description of the scope, who it is assigned to, the acceptance criteria, and the resource requirements. The matrix is offered and loses to the WBS dictionary, which is the detail behind each box on the WBS: full description, responsible party, acceptance criteria, resources, and usually milestones and cost estimates besides. The scope statement is the closest miss and sits a level up. A traceability matrix tells you where a requirement came from and what satisfies it, not what to do on Monday.
Usually not on its own, because the ordered product backlog already does the job.
When a product owner has listed all the work, written user stories, and populated the product backlog, the keyed next step is the cycle: order by business priority, pull the top items into an iteration, complete them, remove them from the backlog. Moving the items into a traceability matrix is rejected in that item as a predictive planning artifact, and the explanation is direct: the ordered backlog already does the job of both a schedule management plan and a traceability matrix.
The hybrid merger case is the exception that proves it. There, the matrix earns its place because there are two artefacts to span. On a single-track agile project there is one, and it is already ordered.
When is the requirements traceability matrix the keyed answer? When the link between requirements is what is broken. The bank keys it for restoring a single view across a merged agile backlog and predictive specification, and for tracing two conflicting requirements before taking the conflict back to both stakeholders.
Why is the traceability matrix so often a distractor? Because it is offered whenever a stem mentions requirements, regardless of the actual problem. It loses to the communications management plan on a communications problem and to the WBS dictionary on a what-am-I-building question.
Does an agile project need a traceability matrix? Not usually. In one bank item the ordered product backlog already does the job, and moving items into a traceability matrix is rejected as a predictive artifact imposed on an agile flow. The exception is a hybrid project spanning both.
What is the difference between the matrix and the scope statement? The scope statement describes the project's scope and deliverables at a level above individual requirements. The matrix tracks each requirement's origin, status, and the deliverable satisfying it, which is why it answers linkage questions rather than what-are-we-building questions.
PMP Practice's 2,141 questions are certified against PMBOK 8 and the July 2026 ECO, with every wrong answer explained rather than just marked wrong. Start the free 20-question sample — no card, no signup required to try it.
Related reading: Project Scope on the PMP Exam: Requirements, the Baseline, and Who Gets to Say Yes and Requirements Elicitation: Which Technique the Scenario Actually Wants. Scope is mapped on the Process domain study page.
When is the requirements traceability matrix the keyed answer?
When the link between requirements is what is broken. The bank keys it for restoring a single view across a merged agile backlog and predictive specification, and for tracing two conflicting requirements before taking the conflict back to both stakeholders.
Why is the traceability matrix so often a distractor?
Because it is offered whenever a stem mentions requirements, regardless of the actual problem. It loses to the communications management plan on a communications problem and to the WBS dictionary on a what-am-I-building question.
Does an agile project need a traceability matrix?
Not usually. In one bank item the ordered product backlog already does the job, and moving items into a traceability matrix is rejected as a predictive artifact imposed on an agile flow. The exception is a hybrid project spanning both.