PMI-PBA Cheat Sheet

Use this as your last-mile PMI-PBA® review. Pair it with the Syllabus for coverage and Practice for speed.

For official exam format and policy details, see Overview.

---

Business analysis in one picture (from need → value)

    flowchart TD
	  A["Define the business need"] --> B["Plan BA approach + stakeholders"]
	  B --> C["Elicit + analyze requirements"]
	  C --> D["Model + validate + prioritize"]
	  D --> E["Trace + manage change"]
	  E --> F["Evaluate outcomes + benefits"]
	  F --> B

When multiple answers look plausible, choose the one that:

• clarifies outcomes and constraints first
• selects a fit-for-purpose technique
• produces testable, traceable requirements
• supports governance decisions with evidence

---

Requirement types (keep these straight)

---

Elicitation technique selection (fast)

Best-answer pattern: pick the technique that reduces the biggest uncertainty given time/constraints.

---

Modeling toolbox (what to pick)

Model quality checks

• consistent names across artifacts
• exceptions covered (alternate flows)
• business rules explicit (not implied)
• NFRs not forgotten (security/performance/usability)

---

Requirements quality checklist (exam-useful)

Good requirements are:

• Unambiguous: one interpretation; terms defined
• Complete: includes actors, conditions, exceptions
• Feasible: achievable within constraints
• Verifiable: you can test it; has thresholds/examples
• Consistent: no contradictions across artifacts
• Traceable: links to objectives and tests

Common “bad requirement” words: fast, easy, user-friendly, seamless, adequate, robust (unless you define measurable thresholds).

---

Prioritization methods (know what each optimizes)

Best-answer pattern: define criteria first (value, risk, compliance, effort), then prioritize.

---

Traceability + change control (the “impact analysis” muscle)

Traceability should connect:

• objectives → requirements → design/build → tests → results → benefits/KPIs

When a change is proposed, you should be able to answer:

• what objectives it affects
• which requirements/models/test cases must change
• which stakeholders must approve
• what it does to cost, schedule, risk, and value assumptions

---

Business case formulas (core)

ROI (return on investment)

\[ \text{ROI} = \frac{\text{Net Benefit}}{\text{Cost}} \]

• Net Benefit is often “total benefits − total costs” over a time window.
• Use ROI to compare options, but sanity-check assumptions and risk.

NPV (net present value)

\[ \text{NPV} = \sum_{t=0}^{n} \frac{CF_t}{(1+r)^t} \]

• (CF_t\) = net cash flow at time (t\).
• (r\) = discount rate.
• (\text{NPV} > 0\) means value creation (in present dollars), given assumptions.

Payback period (concept)

• Time until cumulative net benefits recover the initial investment.
• Faster payback can beat higher ROI when risk/uncertainty is high.

Benefit–cost ratio (BCR)

\[ \text{BCR} = \frac{\text{Present Value of Benefits}}{\text{Present Value of Costs}} \]

• (\text{BCR} > 1\) is generally favorable.

---

Evaluation (prove value, not activity)

Good evaluation answers:

• Did we solve the problem? (outcomes)
• Did we deliver the requirements? (acceptance evidence)
• Did we realize benefits? (KPIs and variances vs assumptions)
• What should we change next? (recommendations)

---

Glossary (quick)

• Acceptance criteria: measurable conditions for acceptance of a requirement/story.
• Assumption: something treated as true for planning; must be validated.
• Constraint: a limit that must be respected (budget, policy, tech).
• Dependency: something required before a requirement can be delivered (data, upstream team, vendor).
• Elicitation: drawing out information from stakeholders and sources.
• Nonfunctional requirement (NFR): quality attribute/constraint (security, performance, usability).
• Traceability: ability to link requirements to objectives, design, tests, and benefits across lifecycle.