CBAP cheat sheet

Plan Business Analysis Approach: choose predictive (waterfall-like), adaptive (iterative/incremental), or hybrid based on risk tolerance, change rate, regulatory constraints, and stakeholder availability; the plan names deliverables, timing, and approval gates.

Plan Stakeholder Engagement: classify each stakeholder by influence and attitude (supportive, neutral, resistant), then pick an engagement level (unaware, resistant, neutral, supportive, leading) and match communication style to it.

Plan Business Analysis Governance: define decision-making authority, requirement change control process, prioritization scheme, and who approves baselines; without a named approver, scope creep is unmanaged.

Plan Business Analysis Information Management: specify how requirements are stored, traceable, versioned, and reused; include access permissions and retention for audit.

Plan Business Analysis Performance Improvements: set measures (defect rate in requirements, rework hours, cycle time, stakeholder satisfaction), capture baseline, then act on variance.

RACI logic: only one Accountable per activity; Responsible does the work; Consulted is two-way before the fact; Informed is one-way after the fact.

Stakeholder matrix axes are power/influence (vertical) and interest/impact (horizontal); high-high stakeholders need proactive, tailored two-way engagement.

Business analysis plan is not the project management plan: the BA plan covers BA work (approach, stakeholders, governance, information, performance); the PM plan covers scope, schedule, cost, quality, risk.

Three elicitation tasks in order: Prepare for Elicitation, Conduct Elicitation, Confirm Elicitation Results; Confirm is distinct from Conduct - results are validated with the source before being treated as requirements.

Elicitation techniques map to purpose: interviews (depth, one-on-one), workshops (consensus, cross-functional), observation/job shadowing (tacit processes), document analysis (existing rules), surveys (large dispersed groups), prototyping (unclear UI).

Prototyping is both elicitation (surfaces hidden needs) and requirements validation; a throwaway prototype is not a requirements deliverable.

Manage Stakeholder Collaboration: ongoing two-way communication, negotiating conflicts, and surfacing disagreement early; unresolved conflict is a risk, not a defect.

If a stakeholder refuses to engage, record it as a risk with impact and escalate through governance; do not silently proceed on assumptions.

Workshop success factors: clear objective, right participants with decision authority, agenda circulated, ground rules, and a documented output reviewed afterward.

Observation vs. job shadowing: observation watches the process without interference; shadowing follows a specific worker to capture tacit steps and workarounds.

Elicitation output is not automatically a requirement - raw statements become requirements after analysis, validation, and confirmation with the source.

Trace requirements in two directions: backward to business objectives and stakeholders (why it exists) and forward to design, build, and test (what satisfies it).

Requirement states typically include proposed, in progress, approved, deferred, cancelled, rejected, and implemented; a state change is a governance event and should be recorded.

Baseline = a formally reviewed and approved set of requirements; changes after baseline follow change control (impact analysis, approval, version update).

Impact analysis for a change covers: affected requirements, designs, tests, and stakeholders; effort, cost, and schedule; risk; and alternative options.

Prioritization techniques: MoSCoW (Must/Should/Could/Won't), time-boxing, weighted scoring, and business value ranking; low-value requirements are deferred, not deleted without approval.

Maintain requirements attributes such as ID, source, owner, priority, status, complexity, and version; traceability without attributes is only half the record.

Approve requirements only when they are unambiguous, complete, consistent, and testable; approval is an authorization to proceed, not a quality judgment of the idea.

Reuse of existing requirements (from prior projects or a repository) still requires validation against the current context and stakeholders.

Strategy Analysis sequence: Analyze Current State, Define Future State, Assess Risks, Define Change Strategy.

Current state analysis uses internal context (capabilities, processes, technology, culture) and external context (market, competitors, regulation, PESTLE).

Define Future State sets business goals and objectives that are SMART (specific, measurable, achievable, relevant, time-bound); objectives must be verifiable to be useful.

Gap analysis = difference between current and future state; the gap plus its causes drives the change strategy, not the solution choice.

Assess Risks at enterprise level: identify risks to the change, evaluate likelihood and impact, and note risk tolerance; solution-level risks are handled later in design.

Change strategy options are compared by cost, benefit, risk, and feasibility; a solution-independent change strategy can precede selecting a solution.

Business need vs. solution: the need is the problem/opportunity; the solution is one option to address it; jumping to solution is the classic strategy error.

SWOT pairs internal strengths/weaknesses with external opportunities/threats; use it to generate strategy options, then test options against goals.

Six tasks: Specify and Model Requirements, Verify Requirements, Validate Requirements, Define Requirements Architecture, Define Design Options, Analyze Potential Value and Recommend Solution.

Verify = build the requirement right (quality: unambiguous, complete, consistent, testable); Validate = build the right requirement (addresses the business need and stakeholder value).

Model types: process models (flow), data models (entities, relationships, cardinality), state models (lifecycle), use cases (actor-goal interactions), and decision models (rules).

Requirements architecture organizes requirements into a coherent whole and shows relationships; it must be traceable to business objectives and consistent with standards.

Design options are compared on cost, benefit, risk, and feasibility; the recommended solution maximizes value against objectives, not technical elegance.

Business rules constrain requirements and are often discovered, not invented; a business rule is a statement that governs behavior, not a requirement itself.

Non-functional requirements (performance, security, usability, reliability) are as binding as functional ones and must be measurable to be verified.

Analysis produces requirements and designs; it is iterative, and models are refined as understanding grows, not frozen at first draft.

Solution Evaluation tasks: Measure Solution Performance, Analyze Performance Measures, Assess Solution Limitations, Assess Enterprise Limitations, Recommend Actions to Increase Solution Value.

Measure performance against the business objectives and expected benefits defined in Strategy Analysis; without a baseline, performance claims are unverifiable.

Solution limitation = a constraint inside the solution (design, capacity, defects); enterprise limitation = a constraint outside it (process, policy, culture, skills, incentives).

Value = benefit delivered minus cost, measured against objectives; a solution that meets requirements but not objectives has low value.

Recommend actions: do nothing, adjust the solution, adjust the enterprise, retire/replace the solution, or change the objectives (with stakeholder approval).

Performance measures should be defined before or during implementation so that evaluation is possible; retrofitting measures weakens credibility.

Assess limitations with root-cause analysis (e.g., 5 Whys, fishbone) to separate symptoms from causes before recommending action.

Evaluation findings feed back into Strategy Analysis and Requirements Analysis; they are inputs to the next change cycle, not a terminal report.