SkarpChapter 16 of 20
Requirements Elicitation Techniques and Requirements Quality
Go beyond “gathering requirements” to use structured elicitation techniques and quality checks that ensure requirements are clear, feasible, and testable.
Step 1 – Why Elicitation and Requirements Quality Matter
Connecting to Earlier Modules
You have seen how projects mix predictive and agile approaches, and how business analysts and project managers rely on strong communication with stakeholders. This module zooms in on eliciting and shaping good requirements.
Key Exam Anchors
Remember: a project is "A temporary endeavor undertaken to create a unique product, service, or result." A stakeholder is "An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by" project outcomes.
Why Requirements Quality Matters
Requirements express what stakeholders need. Poor requirements cause rework and scope creep; good ones are clear, feasible, and testable so you can objectively check if they are met.
Acceptance Criteria on the Exam
Acceptance criteria have a canonical definition you must know: "A set of conditions that is required to be met before deliverables are accepted." You will draft and assess these in different life cycles.
Step 2 – Functional vs Nonfunctional Requirements
Functional Requirements
Functional requirements state what the system or process must do. Example: "The system shall allow customers to reset their password via email." This describes a behavior or feature.
Nonfunctional Requirements
Nonfunctional requirements state how well or under what conditions the solution must perform: performance, security, usability, reliability, compliance, etc.
Examples and Separation
Example bundle: "The app shall show the user dashboard (functional) within 1 second on 4G (nonfunctional)." Good practice is to split these into separate, clearer requirements.
Exam Tip
On questions, "shall do X" is usually functional. Requirements about speed, capacity, security, or look-and-feel are usually nonfunctional, even if they mention features.
Step 3 – Overview of Requirements Elicitation Techniques
Why Elicitation, Not Gathering
Requirements are elicited, not just gathered. You actively draw out needs using structured techniques rather than passively collecting wish lists.
Core Techniques
Know these for CAPM: interviews, workshops, observation, surveys/questionnaires, and prototyping. Each has strengths and weaknesses depending on your context.
Supporting Techniques
You may also use document analysis and focus groups to complement the core techniques, especially when regulations or many customers are involved.
Choosing a Technique
Consider stakeholder location, need for depth vs breadth, desire to uncover workarounds, and the level of conflict when deciding which elicitation technique to use.
Step 4 – Matching Elicitation Techniques to Scenarios
Scenario 1 – Distributed Customers
Bank app feedback from thousands of customers in many countries: use surveys/questionnaires for breadth, plus optional remote usability sessions for deeper insight.
Scenario 2 – Hidden Workarounds
Insurance claims staff with many Excel workarounds: use observation (job shadowing) to see real steps, then interviews to understand why they do them.
Scenario 3 – Conflicting Priorities
Sales, Marketing, and Finance disagree about CRM priorities: run a facilitated workshop with MoSCoW or similar to align and make visible trade-offs.
Scenario 4 – New User Interface
Small group of analysts needs better reports: use prototyping sessions with mockups plus short interviews so people can react to concrete screens.
Step 5 – Deep Dive: Interviews, Workshops, Observation, Surveys, Prototyping
Interviews
Use open questions to explore and closed questions to confirm. Good for busy or powerful stakeholders and for probing beyond proposed solutions to real needs.
Workshops
Facilitated group sessions to co-create requirements and priorities. Use structured turn-taking, subgroups, and a parking lot to manage conflict and dominance.
Observation
Passive or active shadowing reveals real workflows, workarounds, and informal approvals that documents miss. Great for process and gap analysis.
Surveys and Prototyping
Surveys gather input from many distributed stakeholders. Prototypes (sketches or mockups) let users react to something concrete and refine requirements iteratively.
Step 6 – What Makes a Requirement High Quality?
Core Quality Attributes
Key attributes: clear, complete, consistent, feasible, testable, and traceable. These turn raw stakeholder input into requirements that can guide design and testing.
From Vague to Precise
Vague: "The system must be very fast and easy to use." Improved: specify response times, load conditions, and training time so each requirement can be objectively tested.
Spotting Testability on Exams
Testable requirements include measurable criteria: numbers, time limits, percentages, or clearly defined pass/fail conditions, not just adjectives like "user-friendly".
Step 7 – Improve These Requirements (Thought Exercise)
Practice turning weak requirements into higher‑quality, testable ones. You can jot your answers in a notebook or mentally compare.
Task 1 – Make it testable
Original: "The website must load quickly."
- Identify what is vague.
- Rewrite it to be clear and testable. Include:
- A specific page or set of pages
- A response time
- A condition (for example, typical load)
Task 2 – Separate functional vs nonfunctional
Original: "The mobile banking app must allow users to transfer money easily and securely at any time."
- Underline the functional part (what it does).
- Underline the nonfunctional aspects (how well, under what conditions).
- Rewrite as at least two separate requirements.
Task 3 – Add completeness
Original: "Send a notification when an order is delayed."
Ask yourself:
- Delayed compared to what?
- Notified whom, and how?
- Any timing or content rules?
Now draft a more complete version that answers those questions.
After you try, compare with these sample improvements (do not peek until you attempt):
- Task 1: Response time and load conditions.
- Task 2: One functional requirement about transfers; separate nonfunctional ones for usability and security.
- Task 3: Define the delay threshold, recipient, channel, and message content.
This type of mental rewrite is exactly what the exam expects when it asks which option is "best" or "most appropriate" as a requirement.
Step 8 – Acceptance Criteria in Predictive and Agile Contexts
Canonical Definition
Acceptance criteria: "A set of conditions that is required to be met before deliverables are accepted." Know this wording for the exam.
Predictive Context
In predictive projects, acceptance criteria live in specs or contracts and support formal sign-off at phase gates or closure for each deliverable.
Agile Context
In agile, each user story has acceptance criteria that guide development and testing within an iteration and align with the team’s definition of done.
Common Confusions
Acceptance criteria are not the requirement itself and not full test cases. They are the conditions that test cases will verify to support acceptance.
Step 9 – Drafting Acceptance Criteria (Predictive and Agile)
Predictive Example
Requirement: monthly sales report by region. Criteria: specific fields, export formats, performance limit, and access control for regional managers.
Agile Example
User story: wishlist for shoppers. Criteria: add from product page, persists across logins, supports 100 items within 2 seconds, and is visible only to its owner.
What to Look For
Good acceptance criteria are concrete, measurable conditions directly tied to a requirement or story, not step-by-step test scripts or vague desires.
Step 10 – Quick Check: Elicitation and Requirement Types
Try this single‑question quiz to check your understanding of elicitation techniques and requirement types.
You are working on a new inventory system. Warehouse staff are spread across three locations and often use undocumented workarounds. You need to understand the real current process and then confirm it with a larger group. Which combination of techniques is MOST appropriate?
- Send a survey to all staff asking them to describe their process in detail.
- Conduct observation sessions with a few staff in each location, followed by a survey to all staff.
- Hold a single large requirements workshop with representatives from all locations.
- Build a high-fidelity prototype and ask staff to test it and provide feedback.
Show Answer
Answer: B) Conduct observation sessions with a few staff in each location, followed by a survey to all staff.
Option B is best. Observation (shadowing) with a few staff in each location helps uncover undocumented workarounds and the true current process. A follow-up survey to all staff then validates and refines what you observed. A survey alone (A) would miss hidden workarounds. A single workshop (C) may not reveal real daily practices. A prototype (D) is premature when you do not yet understand the current state.
Step 11 – Quick Check: Quality and Acceptance Criteria
Another quick quiz, this time on requirement quality and acceptance criteria.
Which of the following is the BEST example of acceptance criteria for the requirement "Provide an online payment feature"?
- The system must be user-friendly and secure.
- The system shall support credit card and digital wallet payments.
- A set of conditions that is required to be met before deliverables are accepted.
- Payment is processed within 5 seconds for 95% of transactions, supports Visa, Mastercard, and PayPal, and displays a confirmation message with transaction ID.
Show Answer
Answer: D) Payment is processed within 5 seconds for 95% of transactions, supports Visa, Mastercard, and PayPal, and displays a confirmation message with transaction ID.
Option D is the best example of concrete acceptance criteria for the payment requirement: it lists measurable conditions (performance, supported methods, confirmation message). Option A is vague and untestable. Option B is a functional requirement, not full criteria. Option C is the definition of acceptance criteria, not criteria for this specific requirement.
Step 12 – Flashcards: Key Terms and Concepts
Use these flashcards to reinforce critical definitions and distinctions you will see on the CAPM exam.
- Functional requirement
- Describes what the system, product, or process must do (its behaviors, features, or services), for example, "The system shall allow users to reset their password via email."
- Nonfunctional requirement
- Describes how well or under what conditions the solution must perform (performance, security, usability, reliability, etc.), for example, "The system shall display the dashboard within 2 seconds for 95% of requests."
- Acceptance criteria (canonical definition)
- Acceptance criteria: "A set of conditions that is required to be met before deliverables are accepted."
- Interview vs workshop
- Interviews: one-on-one or small-group, good for depth and sensitive topics. Workshops: facilitated group sessions to build shared understanding, resolve conflicts, and prioritize requirements.
- Observation (in elicitation)
- Watching stakeholders perform their work (passive or active) to uncover real workflows, workarounds, and bottlenecks that may not appear in documented procedures.
- Survey/questionnaire (in elicitation)
- Structured set of questions sent to many stakeholders, useful for gathering input from geographically distributed groups and validating patterns found in interviews or observation.
- Testable requirement
- A requirement that is stated in a way that allows an objective test or inspection to determine whether it is satisfied, typically including measurable criteria such as numbers, time limits, or specific conditions.
- Requirements traceability matrix
- A requirements traceability matrix is "A grid that links product requirements from their origin to the deliverables that satisfy them." It supports impact analysis and verification.
Key Terms
- project
- A temporary endeavor undertaken to create a unique product, service, or result.
- elicitation
- The set of activities used to draw out, discover, and clarify stakeholder needs and requirements through techniques such as interviews, workshops, observation, surveys, and prototyping.
- 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.
- 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.
- testable requirement
- A requirement that is stated with enough clarity and measurable detail that an objective test or inspection can determine whether it has been satisfied.
- 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.
- functional requirement
- A requirement that describes what the system, product, or process must do, focusing on behaviors, features, or services.
- nonfunctional requirement
- A requirement that describes how well or under what conditions the solution must perform, including performance, security, usability, reliability, and other quality attributes.
- requirements traceability matrix
- A grid that links product requirements from their origin to the deliverables that satisfy them.