PMI CD-BA cheat sheet

Needs assessment outputs: business need, situation statement, and a recommendation on whether to proceed to solution development.

Situation statement content: problem or opportunity, affected stakeholders, impact of the problem, and the value of addressing it.

Root cause analysis tools: 5 Whys, fishbone (Ishikawa) diagram, and process mapping; symptom statements are not root causes.

Business goals and objectives must be measurable, time-bound, and traceable to the business need before elicitation begins.

Gap analysis formula: current state capability minus desired state capability equals the capability gap to be closed.

Stakeholder identification precedes needs assessment; unrepresented stakeholder groups create scope and adoption risk.

Go/no-go decision rule: if no viable solution path exists or value does not exceed cost, the recommendation is to not proceed.

Knowledge area inputs: enterprise environmental factors and organizational process assets inform the initial needs assessment.

BA planning outputs: stakeholder engagement plan, business analysis approach, governance plan, and information management plan.

Business analysis approach selection depends on risk tolerance, delivery method (predictive vs. adaptive), and regulatory constraints.

Stakeholder analysis dimensions: influence, interest, authority, attitude toward change, and level of impact from the solution.

RACI logic: one accountable per activity; responsibility can be shared; consulted is two-way; informed is one-way.

Elicitation plan specifies techniques, sources, sequence, and timing, matched to stakeholder availability and analysis need.

Traceability approach defines the level of granularity (requirement, design element, test case) and the repository/tool used.

Governance rules define who approves requirement changes, thresholds for escalation, and how baseline changes are authorized.

Communication planning matches channel and format to stakeholder preference, geographic distribution, and decision urgency.

Requirement types: business, stakeholder, solution (functional and non-functional), and transition requirements.

Requirement quality criteria: necessary, unambiguous, complete, consistent, feasible, verifiable, and traceable.

Modeling rule: choose the model by the question being answered - process flow, state, data, or decision logic.

Use case elements: actor, preconditions, main success scenario, alternate flows, exception flows, and postconditions.

Acceptance criteria define the condition of satisfaction; they are testable and are the basis for verification.

Prioritization techniques: MoSCoW, weighted scoring, and time-boxing/business-value ranking; rank by value, risk, and dependency.

Non-functional categories: performance, availability, security, usability, scalability, maintainability, and compliance.

Decomposition rule: break requirements down until each can be estimated, built, and verified independently.

Verification confirms the requirement is well-formed; validation confirms it represents the real stakeholder need.

Traceability types: forward (requirement to design/test), backward (requirement to source need), and bidirectional.

Baseline rule: once approved and baselined, a requirement changes only through the documented change control process.

Change impact analysis covers scope, schedule, cost, quality, risk, and affected downstream artifacts and test cases.

Requirement lifecycle states typically include proposed, approved, implemented, verified, deferred, and rejected.

Traceability matrix columns: requirement ID, source, rationale, design element, test case, status, and owner.

Monitoring compares actual requirement status against the plan and reports variances to the governance body.

Orphan detection: a requirement with no upstream source or no downstream test case signals a traceability gap.

Configuration management ensures the correct requirement version is the one being built and verified.

Solution evaluation compares measured solution performance against the business goals and objectives defined in needs assessment.

Evaluation measures: actual vs. target metric values, timing of benefit realization, and residual gaps.

Limitation categories to assess: solution limitations, enterprise/organizational limitations, and external influences.

Root cause of a performance shortfall is analyzed before recommending a change, replacement, or retirement of the solution.

Solution replacement or retirement decision requires evaluating impact on stakeholders, data migration, and cost.

Lessons learned capture feeds organizational process assets for future needs assessment and planning cycles.

Value measurement must account for the measurement period; early results may not reflect steady-state performance.

Recommendation options at evaluation: no action, adjust the solution, adjust the organization, or replace/retire the solution.