Requirements Traceability Matrix Explained for the PMP Exam

The Requirements Traceability Matrix: Connecting Requirements to Deliverables

The requirements traceability matrix is one of those project documents that PMP candidates often underestimate. It appears straightforward — a table linking requirements to their origins and deliverables — but the PMP exam tests nuanced understanding of how the RTM supports scope management, quality assurance, and change control throughout the project life cycle.

What Is a Requirements Traceability Matrix?

An RTM is a grid that links product requirements from their origin to the deliverables that satisfy them. Each row represents a requirement, and columns track attributes such as the requirement ID, description, source, priority, WBS element, test case, and current status.

The matrix ensures that every requirement is addressed by at least one deliverable and that no deliverable exists without a corresponding requirement. This bidirectional traceability is what makes the RTM powerful.

Components of the RTM

A comprehensive RTM includes the following columns, and the PMP exam may test your knowledge of each:

Requirement ID: A unique identifier for tracking and reference.
Requirement description: A clear, concise statement of what is needed.
Business need/opportunity: The reason the requirement exists.
Source: Who requested the requirement (stakeholder, regulation, contract).
Priority: High, medium, or low — used for trade-off decisions.
WBS element: The work package that produces the deliverable satisfying this requirement.
Test case: The verification method that will confirm the requirement is met.
Status: Active, deferred, deleted, approved, assigned, completed.

How the RTM Supports Project Processes

Scope Validation

During the Validate Scope process, the RTM is used to verify that every requirement has been fulfilled by a deliverable. If a requirement has no corresponding completed deliverable, the scope is incomplete.

Change Control

When a change request affects a requirement, the RTM shows all connected elements — the WBS work package, test cases, and stakeholder source. This impact analysis is essential for informed change decisions.

Quality Control

Test cases linked to requirements through the RTM ensure that quality control activities verify exactly what was specified. No requirement goes untested, and no test exists without a traceable purpose.

Creating the RTM

The RTM is an output of the Collect Requirements process in the Scope Management knowledge area. It is created alongside the requirements documentation and uses these inputs:

Project charter (high-level requirements).
Stakeholder register (requirement sources).
Scope management plan and requirements management plan.
Assumption log.

The tools used during Collect Requirements — interviews, focus groups, questionnaires, benchmarking, brainstorming, and prototypes — feed directly into the RTM. Each requirement gathered through these techniques becomes a row in the matrix.

RTM vs. Requirements Documentation

The PMP exam distinguishes between the requirements documentation and the RTM:

Requirements documentation describes what the requirements are — detailed descriptions, acceptance criteria, and constraints.
The RTM traces where each requirement came from, what delivers it, and how it will be verified. It is a tracking tool, not a descriptive one.

PMP Exam Application

When a PMP question asks how to ensure all requirements are met, the answer often involves the RTM. When a question describes a deliverable that does not match any requirement, the RTM reveals the mismatch. When a stakeholder disputes whether their need was addressed, the RTM traces the requirement back to its source.

Build your own RTM for a practice project and use it to answer scenario-based questions in our PMP practice question bank.