PMI-PBA key terms

The structured process of understanding a business problem or opportunity, its causes, and the capabilities required, before deciding whether and how to invest in a solution.

A concise description of the current problem or opportunity, including its scope, affected stakeholders, and the measurable impact it has on the organization.

A set of techniques for tracing a visible problem back to the underlying conditions that produce it, so solutions address causes rather than symptoms.

A comparison of the current state with a desired future state that identifies the specific differences, their size, and what must change to close them.

A documented picture of the desired operating environment after a solution is in place, expressed through capabilities, processes, and measurable outcomes.

Identifying everyone affected by or able to influence a change, and assessing their interest, influence, attitude, and information needs.

A decision document comparing expected benefits, costs, risks, and strategic alignment of options for an investment, usually ending with a recommendation.

An evaluation of whether a proposed solution is technically achievable, financially viable, legally permissible, and operationally supportable within known constraints.

The boundary stating which capabilities, processes, and users a proposed solution will address, and explicitly what it will not address.

The document describing how business analysis work will be done: activities, deliverables, schedule, stakeholders, techniques, and how requirements will be managed.

A plan specifying which stakeholders will be involved, when, through which techniques, and who is responsible for maintaining each relationship.

The agreed structure of decision rights, approval authority, and escalation paths that determines who can approve requirements, scope changes, and solution decisions.

Ranking requirements by value, risk, cost, urgency, or regulatory need so limited resources are applied where they produce the most benefit.

The planned method for linking requirements to their sources, to each other, and to design, test, and delivery artifacts so coverage and impact can be shown.

An uncertain event that could harm the quality or timeliness of business analysis work, such as unavailable stakeholders or unstable scope, tracked with a response plan.

The disciplined activity of drawing out requirements and other information from stakeholders and other sources, going beyond simply asking people what they want.

A structured group session run by a neutral facilitator where stakeholders jointly identify, clarify, and agree on requirements within a defined timeframe.

A technique in which the analyst watches users perform real work to uncover tacit requirements and workarounds that people may not think to mention.

Building a partial or simulated version of a solution early so stakeholders can react to something concrete, revealing requirements that discussion alone would not surface.

A description of a sequence of interactions between an actor and a system that produces a result of measurable value to that actor.

A short statement of a need written from the user's perspective, typically naming who wants it and why, paired with acceptance criteria that make it testable.

A diagram showing how work flows through activities, decisions, roles, and systems, used to expose handoffs, bottlenecks, and the changes a solution must support.

A statement that defines or constrains an aspect of business operations, such as a policy, calculation, or access condition, independent of how any system implements it.

A quality or constraint the solution must satisfy, such as performance, security, usability, availability, or compliance, rather than a specific behavior or feature.

The conditions a deliverable must satisfy to be accepted by the stakeholder, written clearly enough to be verified objectively through testing or review.

Confirming that requirements are complete, consistent, unambiguous, and correctly written, that they are stated right, before design and construction begin, often through peer review.

Confirming that requirements describe the right solution for the business need and will deliver the intended value, usually through review and agreement with stakeholders.

A table recording the relationships among requirements, their sources, related requirements, design components, and test cases, enabling coverage checks and impact analysis.

An approved and frozen set of requirements that becomes the reference point against which changes, planning, and acceptance are measured.

A formal proposal to modify baselined requirements, scope, or plans that is assessed for impact, decided upon by the authorized owner, and recorded.

An assessment of the consequences a proposed change would have on requirements, scope, schedule, cost, risk, and affected artifacts or stakeholders.

Descriptive metadata attached to a requirement, such as identifier, priority, owner, source, status, or version, used to manage, filter, and report on requirements throughout their lifecycle.

The current stage of a requirement in its defined workflow, such as proposed, approved, implemented, verified, or deferred, used to track progress and control change.

Measuring how well a delivered solution achieves the intended business outcomes and identifying actions needed to remove remaining obstacles to value.

Testing performed by users or customers against agreed acceptance criteria to determine whether a solution may be accepted into operational use.

A metric that quantifies how well a deployed solution performs against defined targets, covering effectiveness, efficiency, and stakeholder satisfaction.

Tracking whether the business benefits expected from an investment actually materialize after implementation, and taking corrective action when they do not.

Documented insights about what worked and what did not on an initiative, captured so later teams can repeat successes and avoid repeating mistakes.