ExamFinch.com My Study

Study guide

9.1 Requirements Gathering Approaches

Practice this exam

CAPM Certified Associate in Project Management Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & CAPM Exam Overview

1.1 About the CAPM Exam 1.2 PMBOK 7th Edition Overview 1.3 Exam Content Outline (ECO) 1.4 CAPM vs. PMP: Understanding the Differences

2 Chapter 2: Project Life Cycles and Processes (Domain 1, Tasks 1-2)

2.1 Projects, Programs, and Portfolios 2.2 Project Life Cycle Phases 2.3 The Five Process Groups 2.4 The Ten Knowledge Areas

3 Chapter 3: Project Management Planning (Domain 1, Task 2)

3.1 The Project Management Plan 3.2 Scope Management and the WBS 3.3 Schedule Management 3.4 Cost Management and Earned Value 3.5 Quality Management

4 Chapter 4: Project Roles, Responsibilities, and Ethics (Domain 1, Tasks 3-4)

4.1 Project Roles and Responsibilities 4.2 Leadership and Emotional Intelligence 4.3 Risk Management Fundamentals 4.4 PMI Code of Ethics and Professional Conduct 4.5 Problem-Solving Tools and Techniques

5 Chapter 5: Resource, Communication, and Stakeholder Management (Domain 1, Tasks 2-3)

5.1 Resource Management 5.2 Communications Management 5.3 Stakeholder Management 5.4 Procurement Management 5.5 Issues, Risks, Assumptions, and Constraints

6 Chapter 6: Predictive, Plan-Based Methodologies (Domain 2)

6.1 When to Use a Predictive Approach 6.2 WBS, Work Packages, and Activity Definition 6.3 Predictive Project Controls and Artifacts 6.4 Critical Path and Schedule Calculations

7 Chapter 7: Agile Frameworks and Methodologies (Domain 3, Tasks 1-3)

7.1 When to Use an Adaptive (Agile) Approach 7.2 The Scrum Framework 7.3 Kanban, XP, and SAFe 7.4 Agile Planning, Estimation, and Metrics 7.5 Agile Project Controls and Artifacts

8 Chapter 8: Business Analysis Roles and Stakeholder Communication (Domain 4, Tasks 1-2)

8.1 Business Analysis Roles and Responsibilities 8.2 Stakeholder Communication in Business Analysis 8.3 Business Case and Needs Assessment

9 Chapter 9: Requirements Gathering and Product Roadmaps (Domain 4, Tasks 3-4)

9.1 Requirements Gathering Approaches 9.2 Requirements Traceability Matrix 9.3 Product Roadmaps

10 Chapter 10: BA Methodologies and Requirements Validation (Domain 4, Tasks 5-6)

10.1 Business Analysis in Predictive and Agile Approaches 10.2 Acceptance Criteria and Requirements Validation 10.3 Business Analysis Tools and Techniques Summary

9.1 Requirements Gathering Approaches

Key Takeaways Explain This Topic AI

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

Last updated: June 2026

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).