SkarpChapter 15 of 20
Requirements Elicitation: From Stakeholder Needs to Clear Requirements
Follow the path from vague stakeholder wishes to structured, testable requirements using common elicitation techniques. This module shows how business analysis practices fit into both predictive and adaptive projects and how the exam expects you to reason about them.
From Vague Wishes to Clear Requirements
Why Elicitation Matters
Stakeholders start with fuzzy wishes like "make it faster". Requirements elicitation turns those vague ideas into clear, testable requirements the team can build and verify.
Projects Are Unique
A project is "A temporary endeavor undertaken to create a unique product, service, or result." Because each project is unique, you must actively discover this project’s specific needs.
What You Will Learn
You will connect stakeholder analysis to elicitation, compare techniques, learn requirement categories, and see how requirements feed scope, WBS, and product backlogs.
Exam Angle
CAPM questions often ask for the best next action: which elicitation technique to use, how to resolve conflicts, or where to document a requirement. Keep that decision focus in mind.
Stakeholder Analysis as the Foundation
Why Stakeholder Analysis First?
Before eliciting requirements, you must know who to ask and how to approach them. Missing or misjudging stakeholders is a major cause of rework and scope creep.
Stakeholder Definition
A stakeholder is "An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by" project decisions, activities, or outcomes.
Key Analysis Steps
Identify stakeholders, analyze their interests and influence, assess availability and communication preferences, and map potential conflicts or alliances.
Exam Tip
If an early option is "update stakeholder analysis" versus jumping into interviews, the exam often prefers refining stakeholder analysis before detailed elicitation.
Planning Elicitation Across Predictive and Agile
Elicitation Needs a Plan
Elicitation is not random. You plan who to talk to, when, and using which techniques so you get the right information at the right time.
Predictive Planning
In a predictive life cycle, scope, time, and cost are set early. Elicitation is front-loaded to support baselined scope, WBS, and a detailed schedule.
Adaptive Planning
In an adaptive life cycle, detailed scope is defined before each iteration. Elicitation is ongoing and lightweight, often via backlog refinement and sprint planning.
Product Backlog Link
In agile, requirements are mainly captured as items in a product backlog: an ordered list of everything known to be needed, managed by the product owner.
Exam Cue
Phrases like "baseline scope" signal predictive; phrases like "2-week iterations" or "product backlog" signal adaptive, guiding which elicitation plan fits.
The Four Requirement Categories
Why Categories Matter
Stakeholder statements often mix goals, needs, and solution details. Categorizing them helps you structure scope and answer exam questions accurately.
Business Requirements
High-level organizational goals or outcomes, like increasing retention or complying with a regulation. They live in the charter and business case.
Stakeholder Requirements
Needs of specific stakeholder groups, such as customer reps needing a single-screen view or compliance needing audit reports.
Solution Requirements
Characteristics of the product or service, including functional behaviors and non-functional qualities like performance or security.
Transition Requirements
Temporary capabilities for moving from current to future state: data migration, training, cutover steps. They end once adoption is complete.
Worked Example: Decomposing a Stakeholder Statement
The Raw Statement
Stakeholder: "We need a modern portal so customers stop calling for balances, it must meet new regulation, and we must move all customers without downtime."
Business Requirements
Reduce call volume and comply with open-banking regulation are business-level goals driving the project’s justification.
Stakeholder & Solution Needs
Stakeholder needs: customers see real-time balances; compliance gets secure data sharing. Solution needs: specific features and quality attributes.
Transition Requirements
Migration without downtime and customer notifications are temporary transition requirements needed only during changeover.
Exam Lens
Ask: Is this about organizational outcomes, a group’s need, the product’s behavior/quality, or a temporary change activity? That reveals its category.
Choosing Elicitation Techniques: Interviews, Workshops, Observation, Surveys
Mixing Techniques
You rarely rely on a single elicitation technique. You choose a mix based on who the stakeholders are and what you need to learn.
Interviews
Best for deep exploration and sensitive topics with individuals or small groups. High detail but time-consuming and potentially biased.
Workshops
Structured group sessions to identify and align on requirements. Great for resolving conflicts but hard to schedule and may be dominated by loud voices.
Observation
Watching real work as it happens. Reveals tacit knowledge and workarounds, but takes time and may change how people behave.
Surveys
Written questions to many stakeholders. Scales well and can be anonymous, but usually offers less depth and depends on good question design.
Exam Hint
Large, dispersed groups suggest surveys plus samples of interviews. Conflicting departments suggest a facilitated workshop to align them.
Thought Exercise: Match Technique to Scenario
Apply what you have learned by choosing techniques for these short scenarios. Think your answers through before revealing the suggested approach.
- Scenario A: A new HR system will be used by 15 HR specialists in one office. They already know each other, but their processes differ slightly.
- Question: Which primary elicitation technique would you choose and why?
- Pause and decide, then compare:
- Suggested approach: A requirements workshop with all HR specialists. This lets you map the current processes, highlight differences, and negotiate a common future process. Follow up with a few interviews for edge cases.
- Scenario B: You are improving a warehouse picking process. Workers say the process is "fine", but management believes there is waste.
- Question: Which technique best uncovers the truth about the process?
- Suggested approach: Observation (job shadowing). Watching workers in action reveals actual paths, delays, and workarounds that they might not mention in interviews.
- Scenario C: A public university is redesigning its student portal. There are 20,000 students across several campuses and online.
- Question: How do you efficiently gather broad input?
- Suggested approach: Start with surveys to gather quantitative data and themes, then run targeted focus-group style workshops or interviews with representative students and staff.
- Scenario D: Two powerful departments disagree about which features are "must have" in a finance system.
- Question: How do you move toward alignment?
- Suggested approach: After separate interviews to understand each side, use a facilitated workshop to co-create priorities and make trade-offs, possibly using techniques like MoSCoW (Must/Should/Could/Won’t).
From Elicited Requirements to Scope, WBS, and Backlogs
Why Output Matters
Elicited requirements must feed into planning and delivery. For CAPM, you must link them to scope, WBS, and product backlogs.
Scope Statement
Analyzed business and stakeholder requirements define what is in and out of scope, forming the basis of the project scope statement in predictive projects.
From Requirements to WBS
Solution and transition requirements drive deliverables and work packages in the WBS, where cost and duration are estimated and managed.
Backlogs in Agile
In adaptive life cycles, solution and stakeholder needs become items in a product backlog, ordered and managed by the product owner.
Exam Signal
After elicitation: in predictive, expect "update scope/WBS"; in agile, expect "refine and reprioritize the product backlog".
Making Requirements Testable: Acceptance Criteria and Traceability
Why Testability?
Requirements must be testable so you can prove they are met. Acceptance criteria and traceability are key tools to achieve this.
Acceptance Criteria
Acceptance criteria are "A set of conditions that is required to be met before deliverables are accepted." They turn requirements into clear pass/fail checks.
RTM Basics
A requirements traceability matrix is "A grid that links product requirements from their origin to the deliverables that satisfy them."
RTM Benefits
The RTM ensures each requirement is covered, supports impact analysis for changes, and helps with audits and regulatory compliance.
Exam Pitfalls
Do not confuse item-specific acceptance criteria with a general definition of done, and remember traceability concepts matter in both predictive and agile.
Role of the Business Analyst in Elicitation
Why the BA Role Matters
Even if your title is not Business Analyst, CAPM expects you to know how BA practices support elicitation and connect business and technical teams.
Preparation
The BA clarifies objectives, chooses techniques based on stakeholder analysis and life cycle, and prepares questions and visuals.
Facilitation
They run interviews and workshops, encourage participation, manage conflict, and use visuals to make ideas concrete.
Documentation & Validation
The BA structures notes, drafts requirement statements, and validates them with stakeholders; in agile, they help refine backlog items and acceptance criteria.
Exam Red Flag
If the BA jumps to picking a technology before understanding needs, the better answer is usually to return to or deepen elicitation.
Quick Check: Requirement Types and Techniques
Test your understanding of requirement categories and elicitation choices.
A stakeholder says: "We must train all 300 sales reps on the new CRM before we disable the old one." What type of requirement is this, and which elicitation technique would be most efficient to confirm details with sales managers in three regional offices?
- Business requirement; observation at each office
- Transition requirement; virtual workshop with the three sales managers
- Solution requirement; survey of all 300 sales reps
- Stakeholder requirement; one-on-one interviews with all 300 sales reps
Show Answer
Answer: B) Transition requirement; virtual workshop with the three sales managers
Training users before disabling the old system is a temporary change activity, so it is a transition requirement. To confirm details with three regional managers, a focused virtual workshop is efficient and allows alignment. Observation and interviewing all reps would be too time-consuming, and surveying reps is less targeted than speaking with managers who own the training plans.
Quick Check: Predictive vs Adaptive Elicitation
Apply your understanding of life cycles and how elicitation outputs are used.
In a project using an adaptive life cycle, the team has just completed a round of stakeholder interviews about a new reporting feature. What is the most appropriate next step?
- Develop a detailed WBS for all future releases based on the interview results
- Baseline the full project scope and prevent further changes to the reporting feature
- Create or update product backlog items for the reporting feature, including acceptance criteria, and work with the product owner to prioritize them
- Finalize the requirements traceability matrix and submit it for formal approval
Show Answer
Answer: C) Create or update product backlog items for the reporting feature, including acceptance criteria, and work with the product owner to prioritize them
In an adaptive life cycle, detailed scope is defined before each iteration and captured in the product backlog. After interviews, the best next step is to create or refine backlog items with clear acceptance criteria and collaborate with the product owner on prioritization. Baselines and full WBS development are more characteristic of predictive projects, and a fully formal RTM approval is less typical at this stage in agile.
Flashcards: Core Elicitation and Requirements Terms
Use these flashcards to reinforce key definitions you will see on the exam.
- project
- A temporary endeavor undertaken to create a unique product, service, or result.
- stakeholder
- An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio.
- predictive life cycle
- A development life cycle in which the project scope, time, and cost are determined in the early phases of the life cycle.
- adaptive life cycle
- A development life cycle that is agile, iterative, or incremental. The detailed scope is defined and approved before the start of an iteration.
- work breakdown structure (WBS)
- A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.
- work package
- The work defined at the lowest level of the work breakdown structure for which cost and duration are estimated and managed.
- product backlog
- An ordered list of everything that is known to be needed in the product, managed by the product owner.
- requirements traceability matrix
- A grid that links product requirements from their origin to the deliverables that satisfy them.
- acceptance criteria
- A set of conditions that is required to be met before deliverables are accepted.
- transition requirement
- A requirement describing the capabilities needed to move from the current state to the future state, such as data migration, training, or cutover activities.
Key Terms
- project
- A temporary endeavor undertaken to create a unique product, service, or result.
- stakeholder
- An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio.
- work package
- The work defined at the lowest level of the work breakdown structure for which cost and duration are estimated and managed.
- product backlog
- An ordered list of everything that is known to be needed in the product, managed by the product owner.
- acceptance criteria
- A set of conditions that is required to be met before deliverables are accepted.
- adaptive life cycle
- A development life cycle that is agile, iterative, or incremental. The detailed scope is defined and approved before the start of an iteration.
- business requirement
- A high-level statement of organizational goals or outcomes that the project must achieve, often captured in the business case or charter.
- solution requirement
- A requirement that describes the characteristics of the product, service, or result that will meet stakeholder needs, including functional and non-functional aspects.
- predictive life cycle
- A development life cycle in which the project scope, time, and cost are determined in the early phases of the life cycle.
- transition requirement
- A requirement describing the capabilities needed to move from the current state to the future state, such as data migration, training, or cutover activities.
- stakeholder requirement
- A requirement that describes the needs of a particular stakeholder or stakeholder group to support the business requirements.
- work breakdown structure
- A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.
- requirements traceability matrix
- A grid that links product requirements from their origin to the deliverables that satisfy them.