SkarpChapter 17 of 20
Requirements Traceability Matrix and Managing Change Through the Life Cycle
Follow requirements from their origin all the way through design, build, and validation using the requirements traceability matrix. This module shows how traceability and controlled change protect value delivery in both predictive and adaptive contexts.
Why Traceability Matters Across the Life Cycle
From Requirements to Delivery
This module follows requirements from origin through design, build, testing, and acceptance using the requirements traceability matrix (RTM).
Key PMI Definition
A requirements traceability matrix is: "A grid that links product requirements from their origin to the deliverables that satisfy them." Memorize this wording.
Why It Matters
Without traceability, teams risk scope creep, missing critical requirements, and weak testing. Traceability connects needs, requirements, design, build, tests, and final deliverables.
Predictive vs Adaptive
RTMs are explicit in predictive life cycles, but the same logic appears in adaptive life cycles through links between backlog items, acceptance criteria, and increments.
Anatomy of a Requirements Traceability Matrix
RTM as a Table
The RTM is usually a table or spreadsheet. CAPM expects you to understand how to read it and spot gaps, not to memorize every possible column.
Common Columns
Common RTM columns: requirement ID, description, source, type, priority, WBS/work package, design reference, build component, test case IDs, deliverable, and status.
Customization
Organizations tailor RTMs. Regulated industries may add regulation references and risk level; software teams may add links to user stories or backlog items.
Forward and Backward Links
Forward traceability goes from requirement to design, build, test, and deliverable. Backward traceability goes from deliverable or test back to the original requirement.
Reading a Simple RTM: Spotting Coverage Gaps
Sample RTM Table
Consider a small online bookstore with an RTM listing requirement IDs, descriptions, source, priority, design specs, test cases, deliverables, and status.
Finding Gaps
R-04 has no test case yet, so there is a validation gap. R-05 has no design, test, or deliverable, so it remains only a proposed requirement.
Using Status
R-01 and R-02 are verified end to end. R-03 is in testing; if TC-03 fails, the team can immediately see which requirement is at risk.
Exam Angle
If asked how to find requirements not covered by tests or the impact of removing a deliverable, the RTM is the key artifact to review.
RTM and Change Control: Impact on Scope, Schedule, Cost, Quality
Change Is Inevitable
Requirements change over time. PMI expects you to know that changes go through formal change control, not informal agreement alone.
Scope Impact via RTM
Use the RTM to see which requirements, deliverables, work packages, and components are affected, especially regulatory or safety-related ones.
Schedule and Cost Impact
Trace from impacted requirements to schedule activities and rework needs. Extra design, build, and testing drive schedule delays and cost increases.
Quality and Exam Pattern
Changes can alter quality attributes and test needs. On CAPM, the best next step is usually: analyze impact using documents (including RTM), then submit a change request.
Impact Analysis Walkthrough Using the RTM
New Requirement: PayPal
Late in the project, the CEO requests a new requirement: users must be able to pay with PayPal. This becomes R-06 in the RTM.
Scope via RTM Links
The RTM shows R-02 and R-03 link to DS-Checkout and DS-Security. R-06 will also link there, implying updates to checkout and security deliverables.
Schedule and Cost Effects
Using RTM links to WBS and schedule, the team finds activities needing rework, new development, and new testing, all adding time and cost.
Quality and Exam Clue
New test cases and acceptance criteria are needed. If asked which document helps evaluate this change, the RTM is a key answer.
RTM and Validation: Are We Ready for Delivery and Acceptance?
Verification vs Validation
Verification checks if the product meets specified requirements. Validation checks if it meets stakeholder needs and business objectives.
RTM as Evidence
The RTM links each requirement to test cases, test results, and deliverables, helping prove that requirements are implemented and tested.
Readiness Checks
Near release, you review each RTM row: test coverage, test pass status, deliverable completion, and acceptance criteria satisfaction.
Exam Application
When asked how to confirm all approved requirements are met before release or closure, the RTM is often the best artifact to consult.
Traceability in Adaptive Life Cycles: Backlog, Acceptance Criteria, Increments
Adaptive Does Traceability Too
Agile teams may not use a big RTM spreadsheet, but they still trace from needs to backlog items, acceptance criteria, tests, and increments.
Product Backlog and Criteria
A product backlog is an ordered list of everything known to be needed, managed by the product owner. Items include acceptance criteria that define when they are done.
Lightweight RTM in Tools
Links in tools (backlog item → tasks → test cases → increment) form a lightweight RTM that supports impact analysis and transparency.
Exam Clues in Adaptive Contexts
In agile scenarios, look for product backlog, backlog refinement, acceptance criteria, and increments as the traceability and change-control mechanisms.
Thought Exercise: Predictive vs Adaptive Traceability
Use this short exercise to solidify how traceability looks different in predictive and adaptive contexts while serving the same purpose.
Scenario A (Predictive)
A construction project is using a detailed upfront design. A new safety regulation requires all staircases to have additional handrails. The project manager needs to understand the impact.
Reflect and jot down (mentally or on paper):
- Which artifact is most helpful to see which requirements and deliverables are affected?
- How will the team trace from the new regulation to work packages and schedule activities?
Scenario B (Adaptive)
A software team using Scrum receives feedback from users that password reset is confusing. The product owner wants to change the flow and add extra verification steps.
Reflect:
- Where is the current behavior captured (what artifact)?
- How will the team represent the change and ensure tests and increments align?
Check your reasoning
- For Scenario A, the key artifact is the requirements traceability matrix, linking regulatory requirements to design specs, work packages, and schedule activities.
- For Scenario B, the change appears as updated or new product backlog items with revised acceptance criteria, linked to tasks and tests in the agile tool.
Notice: in both cases, traceability supports controlled change and impact analysis, even though the tools and ceremonies differ.
If you want, quickly sketch how you would draw the trace links for one scenario as a simple chain like: regulation → requirement → design → work package → activity → test.
Quiz 1: Core Concepts of the RTM
Test your understanding of the basic purpose and usage of the requirements traceability matrix.
Which statement best describes the primary purpose of a requirements traceability matrix in a predictive life cycle?
- It is a document that lists all project risks and their responses.
- It is a grid that links product requirements from their origin to the deliverables that satisfy them.
- It is a hierarchical decomposition of the total scope of work to be carried out by the project team.
- It is a schedule that shows the planned start and finish dates for project activities.
Show Answer
Answer: B) It is a grid that links product requirements from their origin to the deliverables that satisfy them.
The RTM is defined by PMI as "A grid that links product requirements from their origin to the deliverables that satisfy them." The risk register, work breakdown structure, and schedule are different artifacts.
Quiz 2: Change and Impact Analysis
Apply what you learned about using the RTM for change control and impact analysis.
A key stakeholder requests a new reporting feature late in a predictive project. Before submitting a formal change request, what should the project manager do FIRST?
- Immediately add the feature to the scope to keep the stakeholder satisfied.
- Reject the request because changes are not allowed late in the project.
- Use the requirements traceability matrix and other project documents to analyze the impact on scope, schedule, cost, and quality.
- Ask the team to provide a rough guess of the extra effort without looking at any documents.
Show Answer
Answer: C) Use the requirements traceability matrix and other project documents to analyze the impact on scope, schedule, cost, and quality.
PMI emphasizes performing an impact analysis using project documents, especially the RTM, before submitting a change request. Automatically accepting, rejecting, or guessing effort without analysis is not best practice.
Key Term Flashcards: Traceability and Change
Flip through these cards (mentally or with notes) to reinforce core definitions you may see on the CAPM.
- requirements traceability matrix
- A grid that links product requirements from their origin to the deliverables that satisfy them.
- product backlog
- An ordered list of everything that is known to be needed in the product, managed by the product owner.
- acceptance criteria
- A set of conditions that is required to be met before deliverables are accepted.
- predictive life cycle
- A development life cycle in which the project scope, time, and cost are determined in the early phases of the life cycle.
- adaptive life cycle
- A development life cycle that is agile, iterative, or incremental. The detailed scope is defined and approved before the start of an iteration.
- work breakdown structure
- A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.
- work package
- The work defined at the lowest level of the work breakdown structure for which cost and duration are estimated and managed.
Mini RTM Exercise: Trace a Change Request
Apply everything from this module in a short scenario.
Scenario
You are managing a predictive project to develop a mobile banking app. The RTM shows this simplified entry:
- R-10: "App must support biometric login (fingerprint or face)."
- Source: Product owner
- Priority: High
- Design: DS-Login
- Build component: MOD-Auth
- Test cases: TC-10 (fingerprint), TC-11 (face)
- Deliverable: Biometric login feature
- Status: Implemented, tests in progress
A compliance officer now requests: "Biometric data must never be stored on the server; it must stay on the device only." Call this R-15.
Your task (think it through):
- Where would you record R-15 initially in the RTM (status, source, type)?
- Which existing requirement(s) might R-15 relate to or constrain?
- What artifacts should you check to assess impact (design, components, test cases)?
- What kinds of changes might be needed for tests and acceptance criteria?
Self-check (compare with this reasoning):
- R-15 is added to the RTM as a proposed requirement, source = Compliance, type = nonfunctional/security.
- It constrains R-10 and any server-side authentication requirements.
- You trace from R-15 to DS-Login and MOD-Auth to see if server storage is currently designed/implemented.
- New or updated test cases will verify that no biometric data is transmitted or stored on the server; acceptance criteria for R-10 and R-15 are updated accordingly.
This is exactly the kind of structured thinking the CAPM will expect when questions mention RTMs and change requests.
Key Terms
- work package
- The work defined at the lowest level of the work breakdown structure for which cost and duration are estimated and managed.
- product backlog
- An ordered list of everything that is known to be needed in the product, managed by the product owner.
- acceptance criteria
- A set of conditions that is required to be met before deliverables are accepted.
- adaptive life cycle
- A development life cycle that is agile, iterative, or incremental. The detailed scope is defined and approved before the start of an iteration.
- predictive life cycle
- A development life cycle in which the project scope, time, and cost are determined in the early phases of the life cycle.
- work breakdown structure
- A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.
- requirements traceability matrix
- A grid that links product requirements from their origin to the deliverables that satisfy them.