PMI CD-BA key terms

The problem or opportunity that prompts an organization to change, expressed as the gap between current and desired performance. It justifies why a project or product is worth investing in.

A concise description of the current problem or opportunity, written before solutions are considered. It frames context, affected stakeholders, and the consequence of doing nothing.

Comparing current-state capability with the desired future state to quantify what is missing. The difference, not the solution, defines the scope of work that follows.

Documenting how work is performed today, including processes, systems, volumes, and pain points. It establishes a baseline against which future improvements can be measured.

Describing the desired end condition in measurable terms so that solutions can be evaluated against it. It states outcomes and success measures, not a chosen technology or product.

Specific, measurable goals the organization wants to achieve through a change initiative. They provide criteria for prioritizing requirements and judging whether the delivered outcome was worthwhile.

A structured justification for an investment, covering expected benefits, costs, risks, and alternatives considered. It supports a go/no-go decision and is revisited when assumptions change materially.

An assessment of whether a proposed option is viable technically, financially, operationally, and within schedule constraints. It informs option selection before significant commitment of resources.

One of several candidate ways to close the identified gap, such as process redesign, software build, or outsourcing. Options are compared on value, cost, risk, and fit before one is chosen.

Systematically finding everyone affected by or able to influence the change, including indirect and overlooked groups. The output feeds planning for engagement, communication, and requirement elicitation.

Assessing stakeholders by influence, interest, attitude, and impact so engagement effort can be targeted appropriately. It is refreshed as the initiative progresses and power relationships shift.

A documented approach describing who will be engaged, on what topics, through which channels, and how often. It also records how feedback and disagreements will be handled.

Deciding which analysis activities, techniques, deliverables, and level of rigor are appropriate for the initiative. The plan scales effort to risk, complexity, and regulatory context.

The documented schedule of analysis work: activities, techniques, deliverables, roles, and dependencies. It aligns with the overall project or product plan and is updated as scope evolves.

Defines how requirements will be elicited, documented, prioritized, approved, baselined, and changed. It sets the rules that keep requirements consistent and controlled throughout the lifecycle.

Choosing methods such as interviews, workshops, observation, or document analysis based on stakeholder availability, information type, and risk. Different techniques surface different kinds of information.

Drawing out requirements and information from stakeholders and other sources through planned interaction and research. It is more than collecting stated wants; it uncovers underlying needs.

Examining elicited information to identify gaps, conflicts, and dependencies, then shaping it into clear, testable requirements. It includes decomposing, modeling, and refining until the set is coherent.

Ranking requirements by value, risk, cost, and urgency so limited effort goes to what matters most. Techniques include ranking, scoring models, and time-boxed categorization.

Confirming that documented requirements are complete, consistent, unambiguous, and written to agreed standards. It checks the quality of the specification itself rather than the delivered solution.

Confirming with stakeholders that the requirements describe the right solution and will meet the business need. It answers whether the team is building the correct thing.

A statement of behavior the solution must perform, such as calculating, storing, or displaying something. It describes what the solution does in response to inputs or events.

A constraint or quality attribute describing how well the solution must perform, such as response time, availability, usability, or security. These often determine architectural choices and acceptance criteria.

A description of interactions between an actor and a system that produces a measurable outcome of value. It captures normal flow plus meaningful alternatives and exceptions.

A short statement of a need from the perspective of a role, valued for conversation rather than completeness. It is refined with acceptance criteria before development begins.

Conditions a deliverable must satisfy to be accepted by the stakeholder. They make requirements testable and reduce disagreement about when work is truly done.

A visual or structured representation of how activities, decisions, roles, and data flow to produce an outcome. It exposes handoffs, bottlenecks, and unclear responsibilities.

A representation of the entities, attributes, and relationships that a solution must store and manage. It clarifies data ownership, integrity rules, and reporting needs early.

A table linking each requirement to its source, related design, and test cases in both directions. It supports impact analysis and demonstrates coverage of the business need.

The ability to follow a requirement forward to design, build, and test artifacts and backward to its origin. It reveals gaps, orphans, and the ripple effect of proposed changes.

An approved, frozen set of requirements that serves as the reference for further work. Changes after baselining go through formal control rather than informal adjustment.

A defined process for proposing, assessing, approving, and implementing changes to baselined requirements. It records impact on scope, schedule, cost, and risk before a decision is made.

Assessing the consequences of a proposed change across requirements, designs, tests, stakeholders, and plans. Traceability information makes this assessment faster and more reliable.

Metadata attached to a requirement, such as priority, owner, status, source, or stability. Attributes enable filtering, reporting, and consistent management across a large set.

Assessing a delivered or partially delivered solution against business objectives and stakeholder needs. It identifies value actually realized and obstacles preventing full benefit.

Confirming that the intended business benefits have materialized after the solution is in use. It may require measuring over time rather than at a single delivery milestone.

A constraint or shortfall in a delivered solution that reduces its value or prevents some needs from being met. Identifying it feeds recommendations for improvement or follow-on work.

A proposed response to evaluation findings, such as adjusting the solution, revising the process, or retiring it. It should be evidence-based and tied to measured performance.

Insights captured about what worked and what did not during an initiative, so future work improves. They are most useful when recorded close to the event and made accessible.