Study PMI-PBA constraints, interfaces, and dependencies: key concepts, common traps, and exam decision cues.
Constraints, interfaces, and dependencies often define the real difficulty of a solution more than the headline requirement statements do. PMI-PBA expects analysts to look beyond requested capability and discover what limits, external touchpoints, timing conditions, and cross-team dependencies will shape feasibility. When this work is weak, the baseline may look reasonable while still hiding the factors that later cause delay, rework, or misleading change requests.
This is why discovery is not complete when the analyst understands what stakeholders want. It is only complete enough to support later decisions when the analyst also understands what the solution depends on, what cannot be changed easily, and where external systems, policies, contracts, or schedules constrain the path forward.
PMI-PBA often tests whether the analyst can tell when a requirement is still too shallow to evaluate or baseline. If major constraints, interface assumptions, or dependencies are still hidden, the requirement may sound ready while still lacking the structure needed for prioritization or approval. Strong elicitation therefore treats these factors as part of requirement readiness, not as side notes for later teams.
A constraint is not just any challenge. It is a limit or obligation that narrows the feasible solution space. It may come from regulation, policy, funding, architecture, contract terms, service windows, staffing, geography, or timing. PMI-PBA usually rewards the analyst who identifies these limits early rather than discovering them only after prioritization or design has already moved ahead.
Examples include:
The analyst does not need to solve every constraint immediately. The analyst does need to make it visible and relevant.
This topic also reinforces that interviews are not always the strongest source. Contracts, regulations, interface specs, policy manuals, audit findings, data maps, vendor documents, or operational reports may reveal constraints and dependencies more reliably than stakeholder memory. PMI-PBA usually rewards the analyst who uses the best available source rather than defaulting to conversation.
Many initiatives look simple until interfaces are examined. A process change may depend on multiple systems, shared data definitions, approval handoffs, vendor feeds, or manual communication loops. Stakeholders often describe the desired outcome without seeing how many boundaries the requirement crosses.
That is why interface discovery matters. The analyst should ask:
Interface complexity often explains why an apparently small requirement creates a large implementation burden.
Dependencies are not just planning details for later project management. They affect requirement quality and prioritization from the start. If one capability depends on upstream policy interpretation, another team, a vendor delivery, or an external data source, the analyst should capture that relationship before the requirement is treated as ready and independent.
PMI-PBA often favors surfacing dependency logic because it helps the team avoid two weak behaviors:
flowchart TD
A["Desired capability"] --> B["Constraints"]
A --> C["Interfaces"]
A --> D["Dependencies"]
B --> E["Feasibility and priority impact"]
C --> E
D --> E
E --> F["Baseline quality and later control"]
This is why hidden structure matters. It changes what the requirement really means in practice.
When elicitation reveals a major dependency or constraint, the strongest next step is usually targeted follow-up, not passive documentation. The analyst may need additional source review, a focused stakeholder session, or clarification of sequencing and ownership before the requirement can be treated as stable. PMI-PBA generally favors that disciplined follow-up over treating discovery as complete too early.
Discovery is only valuable if the output supports later analysis. A vague note such as “depends on vendor” is weak. Stronger capture identifies what the dependency is, what it affects, and how it should influence the path forward.
Useful dependency capture often includes:
This makes later prioritization and modeling much more credible.
When dependencies are not discovered early, they often reappear later as if they were new scope. A team may say an integration now needs extra work, or that a policy review has introduced new requirements. Sometimes that is true. But often the issue was always present; it simply was not surfaced during discovery.
PMI-PBA generally rewards the analyst who recognizes that weak discovery causes some later “changes” to look new when they are actually previously hidden constraints or dependencies. Better elicitation reduces that kind of avoidable surprise.
Analysts should not treat constraints and dependencies as a separate appendix to the “real” requirements. They should influence how requirements are written, decomposed, and discussed. If a requirement crosses multiple interfaces or relies on unstable upstream behavior, that should affect how specific the statement is, what assumptions are attached, and whether staged delivery or partial scope needs consideration.
This is one of the practical reasons discovery quality matters so much: it shapes the form of later analysis, not just the completeness of the notes.
A workforce-management system needs a new overtime-approval flow. Stakeholders initially describe the requirement as a simple approval rule update. Discovery shows that the change actually depends on a payroll vendor interface, union-rule interpretation for certain employee groups, and a nightly batch window that would delay same-day updates. The requirement is still valid, but it is no longer a simple rule change. By surfacing the hidden structure early, the analyst prevents unrealistic prioritization and a fragile baseline.
Scenario: A national retailer wants to automate store-credit reversals. Early requirements focus on approval rules and customer notifications. During discovery, the business analyst learns that reversals also depend on an external payment partner, a nightly reconciliation batch, and a policy restriction that some reversal reasons require manual fraud review before funds are released.
Question: What is the strongest action for the business analyst?
Best answer: C
Explanation: C is best because PMI-PBA expects the analyst to surface the hidden structure that determines feasibility and later control quality. External interfaces, timing conditions, and policy constraints are not side notes; they shape what the requirement really means.
Why the other options are weaker: