9.1 Requirements Gathering Approaches
Key Takeaways
- Requirements are classified as business, stakeholder, solution (functional + non-functional), and transition requirements — and CAPM scenario questions hinge on naming the correct type
- Elicitation techniques (interviews, workshops, brainstorming, document analysis, prototyping, observation, surveys, focus groups, benchmarking) each match a specific situation the exam describes
- Good requirements are clear, complete, consistent, testable, traceable, feasible, unambiguous, and modifiable
- Domain 4 (Business Analysis Frameworks) is 27% of the 150-question CAPM exam — the second-largest domain — so requirements content is heavily tested
- The most common trap is confusing functional (what the system DOES) with non-functional (how the system PERFORMS) requirements
Where This Sits on the CAPM Exam
Requirements elicitation is the process of discovering, documenting, and managing what a project must deliver. It lives in Domain 4, Business Analysis Frameworks, which carries 27% weight on the 150-question, 3-hour CAPM exam (135 questions are scored; 15 are unscored pretest items). Domain 4 is the second-largest domain after Project Management Fundamentals (36%), ahead of Agile (20%) and Predictive (17%). Expect roughly 40 questions drawn from business analysis, and a large share will ask you to classify a requirement or pick an elicitation technique for a scenario.
The Four Requirement Types
PMI tests your ability to read a one-sentence stem and name the requirement type. Memorize the distinctions below — the wrong answers are usually the other three types.
| Type | Definition | Exam-style example |
|---|---|---|
| Business requirement | High-level need of the whole organization | "Reduce customer churn by 15% within one year" |
| Stakeholder requirement | Need of a specific group | "Call-center agents need to see full order history on one screen" |
| Solution — functional | What the system must DO | "The system shall email a receipt after each purchase" |
| Solution — non-functional | How the system must PERFORM | "The page shall load within 2 seconds for 95% of users" |
| Transition requirement | Temporary capability to move from current to future state | "Migrate 4 years of records before go-live; train 200 staff" |
Trap: Transition requirements are only needed during the change (data migration, training, parallel running) and disappear once the solution is live. CAPM loves to offer "transition" as a distractor against "functional."
Elicitation Techniques — Match the Technique to the Scenario
| Technique | Use it when the stem says… | Best for |
|---|---|---|
| Interviews | One stakeholder, sensitive or detailed topic | Deep exploration |
| Workshops (facilitated) | Many stakeholders must reach consensus fast | Cross-functional alignment |
| Brainstorming | The team needs many ideas quickly | Idea generation |
| Document analysis | Reviewing existing manuals, contracts, regulations | Understanding current state |
| Prototyping | Stakeholders "can't describe it until they see it" | UI and visual requirements |
| Observation (job shadowing) | Workers can't articulate what they actually do | Capturing real workflows |
| Surveys/questionnaires | A large, dispersed audience | Many respondents cheaply |
| Focus groups | Pre-qualified users discuss attitudes | Opinions and reactions |
| Benchmarking | Compare against competitors/industry | Setting performance targets |
Worked scenario: "Warehouse staff cannot explain why they deviate from the documented picking process, and the analyst suspects undocumented shortcuts." The best technique is observation — surveys and interviews rely on self-reporting, which is exactly what is failing here. This is the classic CAPM observation question.
Quality Criteria for a Well-Written Requirement
| Criterion | Bad | Good |
|---|---|---|
| Clear / unambiguous | "The system should be fast" | "The system shall respond within 2 seconds" |
| Testable | "The system is user-friendly" | "95% of users complete checkout in under 60 seconds" |
| Complete | "Users can log in" | "Users log in via email/password or single sign-on (SSO)" |
| Consistent | Two requirements demand different mandatory login methods | All login requirements align |
| Traceable | Orphan requirement, no source | Linked to business objective BR-01 |
| Feasible | "Predict the future" | "Forecast demand from 3 years of sales data" |
Trap: "The system shall be intuitive and modern" fails the testable criterion — there is no measurable acceptance condition, so it cannot be verified.
Documentation Formats and the Requirements Management Plan
The requirements management plan (a component of the project management plan) defines how requirements will be elicited, analyzed, documented, prioritized, traced, and changed. It is created before elicitation begins so the team knows the rules of the game.
The output format depends on the delivery approach:
- Predictive: Business Requirements Document (BRD), then a detailed Software/System Requirements Specification (SRS), often with use cases.
- Agile: A prioritized product backlog of user stories in the form "As a [role], I want [goal], so that [benefit]" with acceptance criteria.
- Hybrid: Formal high-level requirements plus an agile backlog for implementation detail.
Prioritization Techniques
Not every requirement can be built first, so analysts prioritize. CAPM may name any of these:
| Technique | How it works |
|---|---|
| MoSCoW | Sort into Must-have, Should-have, Could-have, Won't-have |
| Numerical/multivoting | Stakeholders score or vote on each item |
| Kano model | Classify as basic, performance, or delighter features |
| 100-point method | Each stakeholder distributes 100 points across items |
| Value vs. effort | Plot value against cost to find quick wins |
Trap: In MoSCoW, "Won't-have" does not mean "never" — it means not in this release/timebox. Exam options that define it as permanently excluded are wrong.
Requirements Analysis and Gap Analysis
After elicitation, the analyst models and refines requirements using process models, data models, use-case diagrams, state diagrams, and decision tables. Gap analysis is the headline technique:
- Document current state (as-is) — how work happens today.
- Define future state (to-be) — how it should work post-project.
- Identify the gaps — the difference between the two states.
- Prioritize the gaps — which matter most to the business need.
- Define requirements — what is needed to close each gap.
Gap analysis is what feeds the business case and the initial backlog. On the exam, if a stem describes comparing "where we are" to "where we want to be," the answer is gap analysis, not benchmarking (which compares against others, not your own future state).
A stakeholder says, "After we launch, we must migrate three years of customer records from the legacy system and train 150 agents before they can use the new tool." What type of requirement is this?
"The system shall return search results within 2 seconds for 95% of queries" is best classified as which kind of requirement?
Warehouse workers cannot clearly explain why they skip steps in the documented picking process, and the analyst suspects undocumented shortcuts. Which elicitation technique is most appropriate?
Which of the following are qualities of well-written requirements? (Select THREE)
Select all that apply