Overview
Traceability and Monitoring covers five tasks that run from baseline to delivery: tracking requirements with a traceability artifact or tool, capturing status, sources and relationships; monitoring requirements across their lifecycles so supporting artifacts such as models, documentation and test cases are produced, reviewed and approved; updating each requirement's status as it moves through lifecycle states; communicating requirements status, issues, conflicts, risks and changes to the project manager and other stakeholders; and managing changes by assessing impacts, dependencies and risks against the baseline under the change control plan.
Candidates must understand what a requirements traceability matrix holds, how lifecycle states are used, and how impact analysis protects the integrity of the requirements and related artifacts. This domain executes the traceability strategy and change control methods chosen in Domain 2, protects the baseline approved in Domain 3, and provides the evidence chain that Domain 5 uses to show each requirement was delivered and tested.
How it's tested
Questions in this domain are mostly process and sequencing scenarios. A change request arrives, a requirement has no linked test, a status report is disputed, or a stakeholder asks a developer for an extra feature. You choose what the analyst should do FIRST or NEXT, and the right answer usually consults the traceability artifact and follows the change control plan before acting.
-
Change request sequence
A stakeholder requests a change to a baselined requirement. The expected order is log it, analyze impact with the traceability matrix, submit to the decision authority, then update the baseline, status and stakeholders.
-
Find the traceability gap
A requirement has no linked test case, or a feature traces to no requirement, and you identify the risk (untested requirement or gold plating) and the corrective action.
-
Status and communication
Stakeholders are surprised by a deferred or blocked requirement, and you choose the communication or status-tracking action that should have prevented it.
A sales director asks the analyst to add a discount field to an approved order screen before release. Options include adding it now, telling the director to wait for the next release, analyzing impact and submitting a change request, or asking developers whether it is easy. The requirement is baselined, so the analyst uses the traceability matrix to assess impact on related requirements, data, reports and tests, then routes the request through change control.
Tasks 5
Official tasks from the PMI outline, in outline order.
4.1 Track requirementsRecord status, sources and relationships in a traceability artifact.
- What it means
- Using a traceability artifact or tool, the analyst captures each requirement's status, source and relationships, including dependencies, to provide evidence that requirements are delivered as stated.
- What to understand
- A requirements traceability matrix links each requirement to its business objective and source, to related requirements, and forward to design elements and test cases. Every requirement needs a unique identifier so links survive rewording.
- How it shows up
- A stem asks how the analyst proves a requirement was delivered or which artifact shows a requirement's origin.
- Common confusion
- Thinking tracking means listing requirements in a document, without the links that make them traceable.
4.2 Monitor requirements throughout their lifecyclesEnsure each stage's supporting artifacts exist and are approved.
- What it means
- Using the traceability artifact or tool, the analyst monitors each requirement through its lifecycle so supporting artifacts such as models, documentation and test cases are produced, reviewed and approved at each point.
- What to understand
- Monitoring looks for gaps: a requirement in development with no approved model, or one marked ready for test with no test case. Catching missing artifacts early is cheaper than discovering them at user acceptance testing.
- How it shows up
- A requirement reaches testing without a linked test case, and you identify which task should have caught it.
- Common confusion
- Treating monitoring as the testers' or project manager's job rather than an analyst task tied to traceability.
4.3 Update a requirement's status as it moves through its lifecycle statesKeep status current and drive requirements to closure.
- What it means
- By communicating with stakeholders and recording changes in the traceability artifact or tool, the analyst updates each requirement's status as it moves through lifecycle states toward closure.
- What to understand
- Typical states include proposed, approved, in development, tested or verified, accepted, deployed, deferred and rejected; the exact set is defined in the requirements management plan. Status changes are recorded, not inferred, so reports reflect reality.
- How it shows up
- A requirement's status is out of date and causes a wrong release decision; the question asks what the analyst should have done.
- Common confusion
- Confusing requirement status with task progress in the project schedule.
4.4 Communicate requirements status to project manager and other stakeholdersKeep everyone informed of status, issues, risks and changes.
- What it means
- Using the communication methods in the plan, the analyst informs the project manager and other stakeholders of requirements issues, conflicts, changes, risks and overall status.
- What to understand
- Communication is tailored to audience: a sponsor needs summary status and risks, developers need detailed changes, and affected users need to know what was deferred. Conflicts and risks are raised early, not saved for scheduled reports.
- How it shows up
- A stakeholder learns late that a requirement was deferred, and you choose the communication failure or the corrective step.
- Common confusion
- Reporting only to the project manager and assuming the information reaches everyone else.
4.5 Manage changes to requirementsAssess impact against the baseline and follow change control.
- What it means
- In accordance with the change control plan, the analyst assesses each change's impacts, dependencies and risks, compares it with the requirements baseline, and maintains the integrity of requirements and associated artifacts.
- What to understand
- Impact analysis uses the traceability matrix to find every affected requirement, design element, test case, data structure and stakeholder, then estimates effects on scope, schedule, cost, quality and value. The designated authority decides; the analyst then updates the baseline, links and versions.
- How it shows up
- A change request arrives late in the project, and you choose the correct next step or sequence.
- Common confusion
- Implementing a change that looks small before impact analysis and approval, or rejecting it outright without analysis.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Requirements traceability matrix (RTM)
A grid or tool that links each requirement by unique ID to its source, business objective, related requirements, design elements and test cases.
- Remember
- The RTM is the first artifact to consult when assessing the impact of a change.
- Tested as
- Appears in most change, coverage and evidence questions in this domain.
- Trap
- Treating the RTM as a static deliverable created once and never updated.
-
Impact analysis
Assessing how a proposed change affects other requirements, design, code, tests, data, schedule, cost, risk and stakeholders.
- Remember
- It happens before the decision, so the decision-maker knows the full cost and value of the change.
- Tested as
- The usual correct next step after a change request is logged.
- Trap
- Doing impact analysis after the change has already been made.
-
Scope creep vs. gold plating
Scope creep is uncontrolled growth in scope from unapproved changes; gold plating is the team adding features nobody asked for.
- Remember
- Backward traceability reveals gold plating, because the feature traces to no requirement or objective.
- Tested as
- Stems describe extra functionality and ask what problem it represents or how to detect it.
- Trap
- Calling developer-added extras scope creep when no stakeholder requested them.
-
Requirement lifecycle states
Defined statuses a requirement moves through, such as proposed, approved, in development, verified, accepted, deployed, deferred or rejected.
- Remember
- The states and who may change them are defined in the requirements management plan.
- Tested as
- Questions ask what status applies or what must happen before a status changes.
- Trap
- Marking a requirement complete when development ends rather than when acceptance is confirmed.
-
Requirement dependencies
Relationships where one requirement relies on, conflicts with or constrains another.
- Remember
- Recording dependencies in the RTM is what lets impact analysis find ripple effects of a change.
- Tested as
- A change to one requirement unexpectedly breaks another, and the question asks what tracking was missing.
- Trap
- Tracing requirements only to tests and never to each other.
-
Coverage analysis
Using traceability to check that every requirement has linked design and test artifacts and every test traces to a requirement.
- Remember
- An untraced requirement may never be tested; an untraced test may test something nobody needs.
- Tested as
- Appears when a requirement is found untested near release.
- Trap
- Assuming that a test suite where every test passed means every requirement was tested.
-
Configuration management and versioning
Controlling versions of requirements and related artifacts so the baseline and every approved change are recorded and recoverable.
- Remember
- After an approved change, the analyst updates the requirement version, the RTM links and dependent artifacts together.
- Tested as
- Questions ask what must be updated after a change is approved.
- Trap
- Updating the requirement text but leaving linked test cases on the old version.
-
Status reporting
Regular and event-driven communication of requirement status, issues, conflicts, risks and changes, tailored to each audience.
- Remember
- The task names the project manager and other stakeholders, so reporting is not limited to the project manager.
- Tested as
- Stems involve surprised stakeholders or conflicting understanding of what is in scope.
- Trap
- Waiting for the next scheduled report to raise a significant conflict or risk.
-
Change request log
A record of each change request with requester, description, impact assessment, decision, decision-maker and date.
- Remember
- Rejected and deferred changes stay in the log so the reasoning is preserved.
- Tested as
- Appears when a previously rejected request resurfaces or an auditor asks why something changed.
- Trap
- Logging only approved changes.
-
Requirements integrity
The state in which requirements and their associated artifacts remain consistent, current and traceable to the approved baseline.
- Remember
- The purpose of managing change in this domain is to maintain integrity, not to block change.
- Tested as
- Questions ask why a formal process is used for a seemingly small change.
- Trap
- Thinking the goal of change control is to minimize the number of changes.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Scope creep vs. gold plating
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Scope creep | Scope grows through changes that bypass approval | Usually requested by stakeholders but uncontrolled | Labeling every scope increase as creep even when it was approved |
| Gold plating | The team adds features or quality beyond requirements | Not requested by anyone; detected by backward tracing | Treating it as harmless because the customer gets more |
Tracking vs. monitoring vs. managing change
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Tracking (4.1) | Recording status, source and relationships in the RTM | Builds the evidence chain | Keeping a list without links |
| Monitoring (4.2) | Checking each lifecycle stage has its approved supporting artifacts | Finds gaps such as missing models or test cases | Leaving gap detection to user acceptance testing |
| Managing change (4.5) | Assessing impact, dependencies and risk of a change against the baseline | Protects integrity when content changes | Implementing before the decision |
Requirement status vs. task progress
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Requirement status | Where a requirement sits in its lifecycle, such as approved, verified or deferred | Maintained by the analyst in the traceability artifact | Inferring it from schedule percentages |
| Task progress | How far work activities have advanced against the schedule | Maintained by the project manager in the schedule | Reporting a requirement as done because its build task is complete |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Small change, just do it
- What candidates pick
- Let the developer add a minor field because it takes an hour.
- Why it looks right
- It keeps the stakeholder happy and seems to cost almost nothing.
- Why it's wrong
- Even small changes can affect reports, interfaces, tests and data; bypassing impact analysis and change control breaks traceability and invites scope creep.
Clue to watch for The requirement is baselined and the request comes directly to a team member.
-
Reject to protect scope
- What candidates pick
- Decline the change request because the baseline is signed off.
- Why it looks right
- It appears to protect schedule and budget.
- Why it's wrong
- The analyst does not decide; the change is analyzed and sent to the designated authority, who may approve it if its value justifies the impact.
Clue to watch for The change could add significant business value, and the question asks what the analyst should do.
-
Ask the developers first
- What candidates pick
- Check with developers whether the change is easy before doing anything else.
- Why it looks right
- Technical effort is part of impact.
- Why it's wrong
- Effort is only one dimension; the analyst first logs the request and uses the RTM to find all affected requirements, tests and stakeholders.
Clue to watch for The options include a step that consults the traceability matrix or change control plan.
-
All tests passed means full coverage
- What candidates pick
- Approve release because 100% of executed tests passed.
- Why it looks right
- All tests passing sounds conclusive.
- Why it's wrong
- Passing tests says nothing about requirements with no linked test; coverage analysis through traceability shows whether every requirement was tested.
Clue to watch for The stem mentions requirements added late or a test suite that predates recent changes.
-
Update text only
- What candidates pick
- Edit the requirement wording after an approved change and move on.
- Why it looks right
- The approved change is now reflected in the requirement.
- Why it's wrong
- Integrity requires updating versions, RTM links, dependent requirements and test cases together; otherwise tests verify the old requirement.
Clue to watch for The question asks what to do after the change has been approved.
-
Project manager will tell them
- What candidates pick
- Report requirement deferrals only to the project manager.
- Why it looks right
- The project manager coordinates communication.
- Why it's wrong
- The task explicitly includes other stakeholders; affected users and sponsors need to know about deferrals, conflicts and risks that touch them.
Clue to watch for A stakeholder group is surprised to discover a requirement was deferred.
Answer framework
When a requirement changes or its status is in question after the baseline, follow this sequence.
- Check whether the requirement is baselined and which change control process and decision authority the plan names for it.
- Log the request with its source, then use the traceability matrix to find every dependent requirement, design element, test case and stakeholder.
- Assess impact on scope, schedule, cost, risk and the value proposition, and present the analysis to the designated decision-maker without deciding yourself.
- After the decision, update the requirement version, its status, the traceability links and every affected artifact so the baseline stays consistent.
- Communicate the outcome and any new risks or conflicts to the project manager and every affected stakeholder group, not only the requester.
Practice question
Want more like this? The PMI-PBA practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Study this domain after Analysis, because it operates on the baseline that Analysis produces. Start by building a small requirements traceability matrix for a sample project: ten requirements with IDs, sources, objectives, dependencies and test cases. Doing it once by hand makes most questions in this domain intuitive.
The highest-priority concept is the change request sequence. Write it as a numbered list from request to communication and rehearse it until you can spot any option that skips a step, especially impact analysis before the decision. Next, learn the lifecycle states and the difference between requirement status and task progress.
Candidates commonly underestimate the communication task. The ECO names the project manager and other stakeholders, so practice deciding who needs which information when a requirement is deferred, blocked or changed. Also review scope creep versus gold plating, which is easy to mix up under time pressure.
Afterward, take question sets that mix change, coverage and status scenarios. Review misses by checking whether you acted before analyzing or decided something the analyst should only recommend. Then move to Domain 5, which uses the traceability you built to prove the solution meets its acceptance criteria.
FAQ
How much of the PMI-PBA exam is Traceability and Monitoring?
PMI weights this domain at 15%. That is roughly 30 of 200 items as a planning estimate; PMI does not publish per-domain counts.
What does a requirements traceability matrix include?
At minimum, each requirement's unique ID, source, linked business objective, status, related requirements and linked test cases. Many also link design elements and releases.
What is the first thing to do when a change request arrives?
Record it and assess its impact using the traceability matrix, following the change control plan. The designated authority decides only after the impact is known.
Can the business analyst approve requirement changes?
Normally no. The analyst analyzes impact and facilitates the decision; the approval authority named in the plan, such as a change control board or product owner, decides.
How does traceability expose gold plating?
Backward tracing links every built feature to a requirement and objective. A feature with no link was added without a business reason, which is gold plating.
How is this domain different from Planning?
Planning decides the traceability strategy and change control methods. Traceability and Monitoring carries them out on the live baseline throughout delivery.
Does traceability apply on agile projects?
Yes, though it is usually lighter. Stories link to features, epics and acceptance tests in a backlog tool, and status moves through the team's workflow states.
Other Business Analysis certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 4 knowledge
You have covered the traceability matrix, lifecycle states, status communication and change impact analysis. Test whether you can choose the right next step when a change request lands late in a project.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the PMI-PBA AI tutor Get any concept explained your way