If you don't figure out what stakeholders actually need before building anything, you will waste time, money, and trust on a solution nobody wants. Requirements elicitation and analysis is the organised process of discovering, clarifying, and documenting what a project must deliver, so that the team builds the right thing the first time. For the CAPM exam, you need to know the tools and techniques used to dig these requirements out of people who may not even know what they really need.
Jump to a section
A simple way to picture Requirements Elicitation and Analysis
A personal shopping assistant is hired by a client who wants a new wardrobe but has no idea what they actually need. The client says, 'I need something professional for work.' The assistant doesn't just run to the nearest shop and buy a suit. They sit down with the client and ask questions: What kind of work do you do? Do you stand or sit most of the day? Do you prefer natural fabrics? Do you have any colours you hate? Do you need to look approachable or authoritative? The client might also mention, 'I like the style my colleague Sarah wears,' but Sarah's style might clash with the client's body shape or office dress code. The assistant observes the client's current closet, takes notes on what fits and what doesn't, and then researches brands and budgets. Only after gathering all this raw data does the assistant create a detailed shopping list: three blazers, five blouses, two pairs of trousers, and one dress. They then present a clear document to the client saying, 'Here is what you asked for, here is what I recommend based on our chat, and here is why each item works for your life.' The client reviews it, makes changes (maybe swap the dress for another pair of trousers), and finally approves the plan before any money is spent.
This shopping assistant's work is exactly like requirements elicitation and analysis in a project. The assistant didn't guess what the client wanted. They asked, clarified, documented, and got approval. In an IT project, if you skip this step, you will buy the wrong suit — a system that nobody actually needs or wants.
Requirements elicitation and analysis is the process of finding out what a project's stakeholders (the people who have an interest in the project's outcome) truly need, then turning those raw ideas into a clear, written set of requirements that the project team can build to. Think of it as detective work, negotiation, and translation all rolled into one.
First, you need to understand the difference between a requirement and a wish. A requirement is a specific, measurable, and testable condition that the final product must meet. A wish is a vague desire like 'the system should be fast.' You need to turn wishes into requirements: 'The system shall load the main dashboard in under 2 seconds on a standard broadband connection.'
Now, let us define the key terms you will see in the CAPM exam.
Stakeholder — anyone who is affected by the project or can affect it. This includes the project sponsor (the person funding the project), the end users (the people who will actually use the product), the customer (the person paying for it), and even people who oppose the project.
Requirements elicitation — the act of gathering raw information from stakeholders. This is NOT asking 'what do you want?' and writing down the answer. Stakeholders often do not know what they want, or they ask for something impossible. Elicitation uses structured techniques to uncover hidden needs.
Requirements analysis — the act of taking the raw information and making it clear, consistent, complete, and feasible. You break down big vague statements into small specific ones, you find conflicts between stakeholders (e.g., Sales wants lots of data fields, but Marketing wants a simple form), and you decide which requirements are truly essential.
Requirements documentation — writing everything down in a formal document called the Business Requirements Document (BRD) or the Requirements Traceability Matrix (RTM). The RTM is a table that links each requirement back to a business need, a test case, and a deliverable. It proves every requirement has a reason to exist.
Why does this exist and what did it replace? In the old days, a manager would say 'build me a software to manage inventory,' and developers would guess the details. The result was usually a system that worked technically but failed in practice because it didn't match how people actually worked. Requirements engineering formalised the upfront thinking to reduce costly rework later.
The main techniques for requirements elicitation that the CAPM exam tests are:
Interviews — one-on-one conversations where you ask prepared questions and follow up on answers. Best for getting deep detail from key stakeholders.
Focus groups — a facilitated discussion with a small group of stakeholders (5-10 people) to explore a topic. Great for getting a range of opinions and seeing how people react to each other's ideas.
Surveys and questionnaires — written sets of questions sent to many people. Useful when you have a large number of stakeholders spread across locations.
Observation — watching people do their current jobs without asking them questions. This reveals what people actually do, not what they say they do.
Prototyping — building a rough, working model of the product (like a clickable mock-up) so stakeholders can see and touch it. They often say 'oh, I didn't mean that — I meant this' once they see the prototype.
Workshops — structured meetings where stakeholders work together to define requirements. Often called Joint Application Development (JAD) sessions.
Document analysis — reading existing documents like old reports, process manuals, or system specifications to find requirements implicit in the current way of working.
The analysis side then involves classifying requirements into categories. The most common split is:
Functional requirements — what the system must DO. Example: 'The system shall send an email confirmation when a user registers.'
Non-functional requirements — HOW the system must perform. Example: 'The system shall be available 99.9% of the time.'
Finally, everything gets prioritised. Not every requirement can be built in the first version. Techniques like MoSCoW (Must have, Should have, Could have, Won't have) help decide what goes into the first release.
In short, requirements elicitation and analysis is the blueprint stage of any project. Without it, you are building a house without a plan.
Identify Stakeholders and Plan Elicitation
Before you ask any questions, you must know who to ask. Identify all stakeholders who have an interest in the project outcome. Then plan which elicitation technique to use for each group (e.g., interviews for key individuals, surveys for large groups).
Elicit Raw Requirements
Use one or more techniques (interviews, focus groups, observation, prototyping, document analysis) to collect raw information. Record everything — even vague wishes and conflicting statements — because you will analyse them later. Use open-ended questions to avoid limiting responses.
Analyse and Model Requirements
Review the raw data. Remove duplicates, resolve contradictions, break broad statements into specific ones, and classify each item as functional or non-functional. Use techniques like affinity diagramming to group related requirements and process mapping to visualise workflows.
Document Requirements
Write the requirements in a clear, structured format. Create a Business Requirements Document (BRD) that includes the project scope, functional and non-functional specifications, and a Requirements Traceability Matrix (RTM) that links each requirement to its source and its test case.
Validate and Gain Approval
Present the documented requirements to stakeholders for review. Ask them to confirm that the requirements accurately reflect their needs. Incorporate feedback, get formal sign-off (approval), and baseline the document. This baseline becomes the official scope that guides design, development, and testing.
Manage Changes Throughout the Project
Even after approval, new requirements or changes may arise. Use a formal change control process to evaluate, approve, or reject changes. Update the RTM and the requirements document whenever a change is approved to maintain traceability.
Meet Priya, a project manager at a mid-size insurance company called ShieldInsure. The company wants to build a new mobile app that lets customers file claims by taking photos of damage on their phones. Priya's boss says, 'Just build it — customers want it.' But Priya knows better. She starts requirements elicitation.
First, Priya holds one-on-one interviews with three key stakeholders: the Head of Claims, a customer service representative, and a customer who frequently files claims. The Head of Claims says, 'I need the system to flag suspicious claims automatically.' The customer service rep says, 'I need the app to tell me when a customer has already sent documents by email so I don't ask again.' The customer says, 'I just want it to be simple — like taking a photo on WhatsApp.' These are all raw inputs, not yet requirements.
Priya then runs a facilitated workshop with six people from different departments (Claims, IT, Legal, Marketing, Customer Service, and Compliance). In the workshop, she uses a technique called 'brainstorming' to list every idea. Then she uses 'affinity diagramming' to group similar ideas. The Legal person says, 'We can't accept photos without metadata proving when they were taken.' Legal wants to reject all photos without metadata, but the customer wants simplicity. Priya notes this conflict — it will need analysis later.
After the workshop, Priya builds a simple prototype — a series of clickable screens on a whiteboard drawn with markers. She shows it to the customer representative, who says, 'Oh, I thought the photo would be taken inside the app, not from the gallery. That changes everything.' Without the prototype, that misunderstanding would have survived until coding was complete.
Priya then observes a day in the life of the claims handling team. She watches how they currently process paper claims. She notices that they manually re-type the customer's policy number from the form into the system. That is a data entry error waiting to happen. So a new requirement emerges: the app should pre-fill the policy number from the customer's login.
Back in her office, Priya analyses everything. She writes a requirements document with 47 functional requirements and 12 non-functional ones. She creates a Requirements Traceability Matrix (RTM) in a spreadsheet: each requirement has an ID, a source (who said it), a priority (Must/Should/Could), a status (Approved/Deferred/Rejected), and links to test cases. She sends the document to all stakeholders for review. The Head of Claims rejects requirement #23 (automatic fraud flagging) because the existing fraud system already does that — it was a duplicate. Priya removes it.
Finally, after two rounds of review and sign-off, Priya gets the approved requirements document. The development team now has a clear, unambiguous list of what to build. Priya knows that if she had skipped this process, the developers might have built an app that takes photos from the gallery instead of in-app, or one that violates compliance rules. The requirements process saved the company months of rework.
The CAPM exam tests your knowledge of requirements elicitation and analysis under Domain IV (Business Analysis). You will see about 5-8 questions on this subtopic. The exam does NOT ask you to perform elicitation — it asks you to recognise the correct technique for a given scenario and understand the outputs.
What they love to test:
The specific techniques and when to use them. For example: 'You need to gather requirements from a large, geographically dispersed group. Which technique should you use?' The answer is 'survey/questionnaire,' not 'focus group' because you cannot gather 500 people in one room.
The difference between elicitation and analysis. They will give a scenario: 'The project manager interviewed stakeholders and then reviewed the transcripts to remove contradictory statements.' The question: 'Which process is the project manager performing?' The answer is 'analysis,' not 'elicitation.'
The difference between functional and non-functional requirements. They will list several statements and ask you to identify which one is non-functional. Traps: 'The system shall store customer data' looks functional (it's what it does), but if they add 'in encrypted format,' it becomes a non-functional requirement about security.
The Requirements Traceability Matrix (RTM). They ask what it is used for: 'linking requirements to business objectives, test cases, and deliverables so that every requirement is accounted for.'
MoSCoW prioritisation. They give a list of requirements and ask which one would be a 'Must have' versus a 'Could have.' A 'Must have' is a requirement without which the product is useless. A 'Could have' is nice but not essential.
Common traps the exam sets:
They use the term 'gathering requirements' which is informal. The correct term is 'requirements elicitation.' If an answer choice says 'requirements gathering,' it is usually wrong because it implies passivity rather than active discovery.
They mix up 'stakeholder identification' (which happens in the Stakeholder Management knowledge area) with 'stakeholder involvement in requirements.' The question will say, 'During which process do you identify stakeholders?' That's not part of requirements — it's a separate process.
They present a scenario where a stakeholder says 'I want a fast system.' They ask what the next step is. The trap answer is 'write it down as a requirement.' The correct answer is 'analyse the statement to define measurable criteria (e.g., response time under 2 seconds).'
They ask about 'brainstorming' as a technique but then ask a question about 'affinity diagramming' as a separate technique to organise ideas from brainstorming. You need to know the sequence: brainstorm first, then affinity diagram, then prioritise.
Key definitions to memorise for the exam:
Business requirement — high-level need of the organisation (e.g., increase customer satisfaction).
Stakeholder requirement — specific need of a stakeholder group (e.g., customers want mobile access).
Solution requirement — technical or functional description of what the product must do.
Transition requirement — temporary requirements for moving from old system to new (e.g., data migration).
Project requirement — constraints like budget, schedule, and reporting.
Memorise these five categories. The exam will ask you to label a requirement statement with the correct type.
Requirements elicitation is an active, investigative process, not just asking 'what do you want?' and writing down the answer.
Stakeholders often cannot articulate their real needs, so techniques like observation and prototyping are essential to uncover hidden requirements.
Non-functional requirements (performance, security, usability) are just as critical as functional requirements, and both must be documented clearly.
The Requirements Traceability Matrix (RTM) links every requirement back to a business objective and forward to a test case, ensuring nothing is missed.
Conflicts between stakeholder requirements are normal and must be resolved through negotiation, analysis, and prioritisation, not ignored.
MoSCoW (Must have, Should have, Could have, Won't have) is a practical framework to prioritise requirements for each project release.
These come up on the exam all the time. Here's how to tell them apart.
Functional Requirement
Describes what the system must do (e.g., 'generate invoice')
Directly observable and testable by user actions
Example: 'System shall email receipt after payment'
Non-Functional Requirement
Describes how the system must perform (e.g., 'invoice generated within 2 seconds')
Relates to quality attributes like speed, security, reliability
Example: 'System shall be available 99.9% of the time'
Elicitation
Gathering raw information from stakeholders
Uses techniques like interviews, observation, prototyping
Output is unprocessed notes, recordings, and transcripts
Analysis
Structuring and clarifying the raw information
Uses techniques like affinity diagramming, prioritisation, conflict resolution
Output is a documented, analysed set of requirements
Stakeholder Requirement
Expressed in business language by stakeholders
Describes a need from a specific user group's perspective
Example: 'Customers want to upload photos from their phone'
Solution Requirement
Expressed in technical language by analysts and developers
Describes how the product will meet stakeholder needs
Example: 'The mobile app shall use the device camera API to capture JPEG images under 5MB'
Prototyping
Builds a working model of the product for feedback
Requires stakeholders to interact with a mock-up
Best for discovering missing or misunderstood requirements
Observation
Watches stakeholders perform their current tasks
Requires no active stakeholder participation beyond being watched
Best for uncovering actual workflow vs. stated workflow
Mistake
Requirements elicitation is just asking stakeholders what they want and writing it down.
Correct
Elicitation is an active, investigative process using techniques like observation and prototyping to uncover hidden, unspoken, or contradictory needs that stakeholders cannot articulate directly.
Beginners think stakeholders know exactly what they need, but in reality most stakeholders do not understand technical possibilities or limitations. The phrase 'just ask' feels natural, so it is a default assumption that must be unlearned.
Mistake
All requirements should be defined completely before any design or development begins.
Correct
Some requirements are best discovered iteratively through prototyping and feedback. The traditional 'waterfall' approach of fully defining everything upfront often fails because stakeholders change their minds when they see the product.
Beginners hear 'requirements define the scope' and assume complete upfront definition is ideal. They confuse the ideal of being thorough with the outdated practice of being rigid.
Mistake
Functional requirements are more important than non-functional requirements.
Correct
Non-functional requirements (like security, performance, and usability) are equally critical. A system that works functionally but crashes under load or leaks data is a failure.
People naturally focus on 'what the system does' because it is concrete. Non-functional concerns feel abstract until something goes wrong, so beginners underestimate them.
Mistake
A single stakeholder can speak for all users, so you only need to interview the project sponsor.
Correct
Different stakeholders have different, often conflicting, perspectives. The project sponsor may want cost savings, while end users want ease of use. You must elicit from multiple groups and resolve conflicts.
Beginners assume authority correlates with knowledge of all needs. They do not realise that the sponsor rarely does the actual day-to-day work, so they miss operational requirements.
Mistake
The requirements document is the final word — once approved, it can never change.
Correct
Requirements are baselined after approval, but changes can be requested through a formal change control process. The baseline is a snapshot, not a prison.
Beginners hear 'sign-off' and think it means 'frozen forever.' They do not understand that projects operate with change management to accommodate learning and evolving business needs.
Mistake
Prototyping is only for software projects and is too expensive for small projects.
Correct
Prototyping can be as simple as paper sketches or whiteboard diagrams, which are cheap and effective for any project type, even non-IT ones like process redesign.
The word 'prototype' sounds technical and expensive, so beginners assume it requires software tools. In reality, low-fidelity prototypes are fast and low-cost.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A business requirement is a high-level need of the whole organisation (e.g., 'increase customer retention by 10%'), while a stakeholder requirement is a specific need from a group like customers or employees (e.g., 'customers want a mobile app to check claim status').
No. End users are the ones who will actually use the product, so their needs often differ from management's assumptions. Skipping them leads to building something that works technically but fails in practice.
The RTM is a table that links each requirement back to its original business need and forward to the test case that verifies it. It ensures every requirement has a purpose and can be tested.
Yes. MoSCoW stands for Must have, Should have, Could have, Won't have. It is a prioritisation technique used to decide which requirements go into the next release and which are deferred.
Requirements can change through a formal change control process. The project manager evaluates the impact on cost, time, and scope, and if approved, the baseline is updated and the change is implemented.
No. You select techniques based on the project's size, complexity, stakeholder availability, and budget. Small projects might only need interviews and document analysis, while large ones may use workshops and prototyping.
You've finished Requirements Elicitation and Analysis. Continue through the CAPM study guide to build a complete picture of the exam.
Done with this chapter?