PBA IQA key terms

The knowledge area covering how a business analyst decides which activities are needed, who performs them, how stakeholders are engaged, and how progress and results are tracked and reported.

The documented decision about how business analysis work will be performed on an initiative, including timing, formality, level of detail, prioritization method, and expected deliverables.

A description of which stakeholders matter, what each needs from the work, how and how often they will be involved, and what collaboration techniques will be used with them.

The process of identifying people and groups affected by a change and assessing their influence, interest, attitudes, and needs so engagement can be planned appropriately.

A responsibility chart that labels each activity as responsible, accountable, consulted, or informed, clarifying who does the work, who approves it, and who must be kept aware.

The decision rights, escalation paths, approval thresholds, and reporting structures that determine how business analysis work is authorized, reviewed, and changed.

The activity of drawing out information from stakeholders and other sources using techniques such as interviews, workshops, observation, and document analysis, rather than simply receiving stated requests.

Working jointly with stakeholders so that information, decisions, and ownership of outcomes are shared, supporting accurate elicitation and durable agreement on requirements.

Guiding a group session so participants reach a shared result, managing agenda, ground rules, participation balance, conflict, and documentation of decisions.

A structured group event that brings stakeholders together to elicit information, resolve differences, or define requirements within a defined time and scope.

A planned conversation with one or a few stakeholders, used to explore needs, context, and opinions in depth and to follow up on unclear or conflicting information.

Watching stakeholders perform real work in its actual setting to discover tacit steps, workarounds, and environmental constraints that people may not describe when asked.

The knowledge area concerned with tracing, maintaining, prioritizing, assessing changes to, and approving requirements from creation through retirement.

The recorded relationships among requirements, their sources, related designs, and test or delivery artifacts, enabling impact analysis and evidence that each requirement is addressed.

Ranking requirements by value, risk, urgency, or cost so that limited effort and funding go to what matters most and delivery order is defensible.

A prioritization scheme that sorts items into must have, should have, could have, and will not have this time, making the consequences of limited capacity explicit.

A defined process for submitting, assessing, deciding on, and recording changes to approved requirements or baselines so that alterations are deliberate and visible.

An agreed, recorded set of requirements that serves as the reference for further work, so that later modifications must pass through change control.

Assessing what a proposed change would affect, including related requirements, designs, interfaces, data, tests, stakeholders, cost, and schedule, before a decision is made.

The knowledge area covering analysis of the current state, definition of a desired future state, assessment of risks and change options, and selection of an approach to reach the target.

Examining how the organization works today, including processes, systems, capabilities, and problems, to establish a factual starting point for change.

A description of the desired conditions after change, covering goals, capabilities, processes, and measures, expressed clearly enough to guide design and evaluation.

Comparing the current state with the desired future state to identify what is missing or must change, forming the basis for solution scope and options.

The boundary stating what a proposed solution will and will not address, including affected business units, processes, systems, and interfaces.

The knowledge area covering structuring, modeling, verifying, and refining requirements, then defining and comparing design options that satisfy them.

Checking that a stated requirement is complete, clear, consistent, feasible, and testable, so that it can be used confidently by those who build and test the solution.

Confirming with stakeholders that requirements describe the right need and will deliver the intended value, ensuring shared understanding and agreement before work proceeds.

A candidate way of satisfying requirements, described well enough to compare alternatives on value, cost, risk, and fit before one is recommended.

Any information gathered or produced during business analysis work, such as needs, requirements, models, and decisions, which must be organized and maintained for use.

The knowledge area covering measurement of a delivered solution's performance and value, analysis of why gaps exist, and recommendation of action to improve or remove it.

A defined indicator with a target that shows how well a solution or process achieves intended outcomes, used to judge value and detect shortfalls.

A constraint or shortfall that prevents a delivered solution from fully realizing expected value, whether caused by design, environment, data, or user behavior.

Adjusting the methods, formality, and deliverables of business analysis work to suit the initiative's size, risk, regulatory setting, and delivery approach.

The ability to convey and receive information clearly in writing, speech, and visuals, adjusting tone and detail for the audience so understanding is confirmed.

Breaking a complex situation into parts, identifying patterns, causes, and relationships, and reasoning from evidence to reach defensible conclusions.

Defining a problem precisely, generating and evaluating alternatives, choosing a course of action, and checking whether the chosen action actually resolved the issue.

Reaching agreement among parties with differing interests by clarifying underlying needs, exploring trade-offs, and settling on terms all can accept.

Addressing disagreement among stakeholders by surfacing the real interests, using a deliberate approach, and documenting the outcome so work can continue.