← PMI-PBA: needs, requirements, and benefits
14 / 15 · 70 MIN

Traceability and impact boundaries

Use explicit relationships to identify what needs review without confusing links with proven impacts.

Give links meaning

In a fictional payments project, the business wants to change the cutoff time. A list of files containing the word cutoff is insufficient to identify impact. The API accepts requests, the worker executes the batch, one test covers both and the runbook guides APS. Record why each element relates to the requirement and in which direction the relationship is read. In the original model, API depends-on R means that API depends on requirement R. To investigate a change to R, relationships are traversed in reverse to find dependents. The same matrix can support different questions; document its semantics before automating the search.

Distinguish candidates, objectives and actual effects

The exercise identifies R, API, WORKER, T and RUN as review candidates. This does not mean that every candidate needs modification or that no other impacts exist outside the model. A supports relationship links R to objective G so that business rationale can be reviewed. LOGIN also contributes to G, but that shared link does not establish that login changes when cutoff changes. The algorithm does not automatically include LOGIN. Ask owners to confirm effects, interfaces, controls and omitted operations. If they discover a missing dependency, update the model and repeat the analysis. A small result can reflect genuinely narrow scope or an incomplete matrix.

Count work rather than paths to work

Test T is reached through both the API and worker. In the fixture, estimates are R=2, API=3, WORKER=5, T=4 and RUN=1 person-days. Counting each element once gives 15. Counting T again because another path reaches it would give 19 without identifying additional work. Deduplication is correct only because T represents the same work package here. If two configurations require distinct execution and evidence, create units with their own identities and estimates instead of removing a legitimate repetition. Person-days are not calendar days either: availability, sequence, skills and waiting determine duration. Present assumptions together with the total.

Preserve uncertainty and detect invalid information

When T has no estimate, the known subtotal is 11 and the total remains unknown. Reporting should expose that gap and its estimate owner; converting it to zero would create false completeness. The model rejects duplicate identifiers, missing link endpoints, unrecognized relationships and negative effort. A dependency cycle does not cause infinite execution because each element is visited once. This only demonstrates that traversal terminates: it does not establish that the cycle is valid for the business or that tasks can be scheduled. Investigate the cycle’s origin and distinguish information dependency, execution dependency and a simple documentary reference.

Turn traversal into a decision package

Before the committee, assemble change rationale, the baseline used, identified candidates, confirmed impacts, gaps, estimates and consequences of deferral or rejection. Include business teams, development, QA and APS when outcomes affect them. Public NASA requirements and configuration guidance helps explain relationships and baseline control; its specific boards and milestones are not rules for banks or every PMI project. In PMI-PBA, the objective is to keep requirements and artifacts consistent while assessing changes. Summarize results in verifiable language: five candidates found in the model, four estimates available if T is unknown, owner analysis still required. Do not present traversal as automatic authorization.

# Fictional relationship directions, not a bank workflow.
API --depends-on--> R
WORKER --depends-on--> R
T --verifies--> API
T --verifies--> WORKER
RUN --documents--> WORKER
R --supports--> G
LOGIN --supports--> G
# Change R: candidates R, API, WORKER, T, RUN.
# 2 + 3 + 5 + 4 + 1 = 15 person-days, not elapsed days.
IN PRACTICE

Changing R identifies five candidates and 15 person-days. Without T’s estimate, 11 person-days are known and the total is unknown.

Common pitfalls

Links as proof of impact; a shared objective as dependency; duplicate paths as additional work; unknown as zero.

Related topics: Requirements management · Estimates and dependencies · Change control and acceptance

Take this idea with you

Define the relationship, confirm impact with owners and communicate model coverage and gaps.

Create account

Reference: PMI-PBA Examination Content Outline · Five-domain ECO / verified 2026-10-01

PMI-PBA® and PMI® are registered trademarks of Project Management Institute, Inc. bigsavant.com is an independent preparation platform and is not affiliated with, associated with, sponsored, authorised or endorsed by PMI. Content and questions are original, are not official exam questions, and completing our tests does not award or guarantee any certification. Names are used only to identify the subject. All other trademarks belong to their respective owners.