Business Analysis Frameworks · Topic 2 of 4
Gathering Requirements
CAPM requirements gathering: elicitation techniques for each situation, user stories versus use cases, requirement types and the traceability matrix.
- 4 min
- Elicitation techniques: interviews, workshops, focus groups, surveys, observation, document analysis, prototyping.
- Workshops resolve differences between stakeholders quickly.
- Functional: what it does. Nonfunctional: how well. Transition: moving to the new state.
What it is
A requirement is a condition or capability that must be present in a product, service or result to satisfy a need. Gathering requirements (also called elicitation) means drawing that information out of stakeholders and documents, then recording it in a form the team can build and test against.
How it works
Elicitation techniques and when to use them
| Technique | Best for |
|---|---|
| Interviews | Detailed or sensitive information from individuals; experts and decision makers |
| Workshops (facilitated sessions) | Bringing several stakeholders together to define and agree requirements quickly, resolving differences |
| Focus groups | Learning the attitudes and expectations of a selected group of users |
| Surveys and questionnaires | Reaching many people, often spread out, with standard questions |
| Observation (job shadowing) | Learning how work is actually done, when people struggle to describe it |
| Document analysis | Learning from existing documents, systems, policies and regulations |
| Prototyping | Getting early feedback on a model before building the real thing |
| Brainstorming | Generating many ideas quickly |
| Lessons learned | Reusing knowledge from earlier projects |
| Benchmarking | Comparing with practices of other organizations |
A worked example: a hospital wants a new booking system. The BA reads current procedures (document analysis), shadows reception staff (observation), runs a workshop with clinic managers to agree priorities, and sends a short survey to patients.
Types of requirements
| Type | Describes |
|---|---|
| Business requirements | High-level needs of the organization, such as goals and objectives |
| Stakeholder requirements | Needs of a stakeholder or group |
| Solution requirements: functional | What the product must do, its behaviors |
| Solution requirements: nonfunctional | Qualities such as performance, security, usability and reliability |
| Transition requirements | Temporary capabilities needed to move to the new state, such as data migration and training |
| Project requirements | Actions, processes or conditions the project must meet |
Documenting requirements: matching tools to scenarios
| Tool | What it is | Use when |
|---|---|---|
| User story | A short statement of value: "As a (user), I want (goal) so that (benefit)" | Adaptive projects; conversation follows to add detail |
| Use case | Describes the interaction between an actor and the system, step by step, including alternative paths | Detailed system behavior must be understood |
| Requirements document or specification | A formal written set of requirements | Predictive projects, contracts and regulated work |
| Process model or flowchart | Shows steps of a business process | Understanding or improving a process |
| Prototype or wireframe | A visual model of a screen or product | Stakeholders need to see before they can say what they want |
| Acceptance criteria | Conditions that must be met for acceptance | Defining when a requirement is satisfied |
Requirements traceability matrix and product backlog
A requirements traceability matrix (RTM) is a table that links each requirement to its origin (business objective or stakeholder) and forward to the deliverables, design and tests that satisfy it. It helps make sure every requirement is delivered and tested and that nothing is built without a reason.
In adaptive projects, the product backlog plays this role: each backlog item traces to a need and is accepted against its criteria.
When stakeholders cannot describe what they do, use observation. When many people in many places must be reached, use a survey. When several groups disagree, use a facilitated workshop.
How the exam asks about this
- "Which technique best reveals how users actually do their work?" Observation.
- "Which document links each requirement to its source and its test?" The requirements traceability matrix.
- "Data migration from the old system is which type of requirement?" A transition requirement.
What to remember for the exam
- Elicitation techniques: interviews, workshops, focus groups, surveys, observation, document analysis, prototyping.
- Workshops resolve differences between stakeholders quickly.
- Functional: what it does. Nonfunctional: how well. Transition: moving to the new state.
- User stories suit adaptive work; use cases describe detailed interactions.
- The RTM traces requirements from source to delivery and test; the backlog does this in agile.
A survey cannot replace conversation for complex needs. It reaches many people but gives little depth.
Common mistakes
Calling security or performance functional requirements. They are nonfunctional.
Using an interview to reach hundreds of users. A survey is more efficient.
Treating the RTM as a schedule. It traces requirements, not dates.
Check yourself
When is a facilitated workshop the best elicitation technique?
When several stakeholders must define and agree requirements together, especially if their views differ.
What is the difference between a user story and a use case?
A user story is a short statement of value from a user's view; a use case describes the step by step interaction between an actor and the system.
What does a requirements traceability matrix do?
It links each requirement to its origin and to the deliverables and tests that satisfy it.
Topic 2 of 4 in Business Analysis Frameworks
Test yourself on Business Analysis Frameworks
The full PMI CAPM question bank has 1,049 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by PMI. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.