Requirement Elicitation and Analysis: Techniques, Process & Examples
Requirement Elicitation and Requirement Analysis are two of the most important activities in Requirement Engineering. Elicitation helps the software team discover what users and stakeholders actually need, while analysis converts those raw needs into clear, realistic, organized, prioritized, and conflict-free requirements. These activities may look simple in books, but in real projects they require communication, observation, business understanding, modelling, negotiation, prioritization, and continuous clarification. In this chapter, we will understand Requirement Elicitation and Analysis deeply in very simple language with techniques, complete process, stakeholder roles, requirement sources, interviews, questionnaires, observation, workshops, brainstorming, prototyping, use cases, prioritization, conflict resolution, examples, memory tricks, exam points, viva questions, and all related concepts.
Requirement Elicitation is the process of discovering and collecting requirements from users, customers, stakeholders, documents, existing systems, and the working environment. Requirement Analysis is the process of studying those collected requirements, removing ambiguity, identifying conflicts, checking feasibility, prioritizing needs, modelling the system, and converting raw requirements into a clear and agreed set of software requirements.
In simple language:
Elicitation asks: “User ko kya chahiye?”
Analysis asks: “Jo user ne bola hai, uska exact practical meaning kya hai?”
What is Requirement Elicitation?
Requirement Elicitation is the activity of finding, discovering, collecting, and understanding what stakeholders expect from a software system.
The word elicitation is important because requirements are not always available in one ready-made document. Many requirements are hidden inside user expectations, business rules, old systems, daily work practices, legal rules, reports, forms, or domain knowledge.
Simple Definition
Requirement elicitation is the process of gathering software needs from all relevant sources.
Main Goal
To discover what users really need, not only what they initially say.
What is Requirement Analysis?
Requirement Analysis begins after requirements have been collected. The analyst studies them carefully and checks whether they are:
- clear,
- complete,
- consistent,
- feasible,
- necessary,
- prioritized,
- testable,
- free from conflict.
Elicitation gives us raw requirements.
Analysis converts them into usable requirements.
Requirement Elicitation vs Requirement Analysis
| Basis | Requirement Elicitation | Requirement Analysis |
|---|---|---|
| Main Purpose | Discover and collect requirements | Study, refine, organize, and validate collected requirements |
| Main Question | What do stakeholders need? | What exactly do these needs mean for the system? |
| Input | Stakeholders, documents, systems, business processes | Raw requirements collected during elicitation |
| Activities | Interview, observation, survey, workshop, prototyping | Classification, prioritization, modelling, negotiation, feasibility checking |
| Output | Initial/raw requirement set | Refined, agreed, structured requirements |
| Main People | Analysts + stakeholders | Analysts + domain experts + developers + stakeholders |
Why are Requirement Elicitation and Analysis Important?
Many software projects fail not because developers cannot code, but because the team builds something different from what users actually need.
Reduces Wrong Assumptions
Instead of guessing what users need, the team gathers evidence directly from stakeholders and their environment.
Reduces Rework
Finding requirement problems early is cheaper than changing software after coding is completed.
Improves Final Quality
Better requirements lead to better design, coding, testing, and user satisfaction.
Controls Scope
Analysis helps separate essential needs from optional wishes and unnecessary features.
Improves Communication
Stakeholders, developers, testers, and managers get a shared understanding of the system.
Supports Testing
Clear requirements help testers decide what behaviour should be verified later.
Pictorial Process: From Stakeholder Need to Analysed Requirement
This process is usually not perfectly one-way. Analysts often go back to users again when new questions appear during analysis.
Sources of Requirements
Good elicitation starts by finding the correct sources of information. Requirements can come from many places.
Users
People who directly use the final system.
Customers
People or organizations that request or pay for the system.
Domain Experts
Experts who understand the business or technical domain deeply.
Existing Systems
Old applications can reveal useful features, limitations, and workflows.
Documents & Policies
Forms, reports, manuals, regulations, standards, and business rules.
External Systems
APIs, payment systems, devices, government portals, and third-party services.
Stakeholder Identification
A stakeholder is anyone who affects the system, is affected by the system, or has an interest in the project.
Primary Users
People who directly interact with the system every day.
Customers / Clients
People who define business goals and approve the project.
Managers
They care about cost, schedule, resources, and project success.
Developers
They help check whether requirements are technically feasible.
Testers
They help ensure requirements are testable and measurable.
Regulators / External Parties
They may introduce legal, safety, privacy, or compliance requirements.
Missing an important stakeholder can mean missing an important requirement.
Requirement Elicitation Techniques
Elicitation is not done through only one technique. Good analysts select techniques according to the project and combine several methods when needed.
Interviews
Direct conversation with stakeholders using prepared or open-ended questions.
Best for: Deep understandingQuestionnaires
Structured questions distributed to many users.
Best for: Large user groupsObservation
Watching users perform real tasks in their actual work environment.
Best for: Hidden workflowWorkshops
Multiple stakeholders discuss requirements together in a facilitated meeting.
Best for: Shared agreementBrainstorming
Participants generate ideas freely before evaluating them.
Best for: Early ideasPrototyping
A sample interface or system is created so users can react to something visible.
Best for: Unclear requirementsDocument Analysis
Existing reports, forms, policies, manuals, and system documents are studied.
Best for: Existing processesFocus Groups
A selected user group discusses needs, expectations, and problems together.
Best for: User opinionsUse Cases & Scenarios
Real user-system interaction is described step by step to discover system behavior.
Best for: Functional requirementsInterview Technique in Requirement Elicitation
Interviews are one of the most common requirement elicitation techniques. The analyst asks questions directly to stakeholders.
Types of Interviews
Structured Interview
Questions are prepared in advance and asked in a fixed order.
Useful when consistent answers are required from many people.
Unstructured Interview
The discussion is more open and flexible. The analyst asks follow-up questions based on stakeholder responses.
Good Interview Questions
- What problem are you facing today?
- What steps do you follow currently?
- What information do you need?
- What errors happen most often?
- What should the system never allow?
- Who else uses or depends on this process?
- What would make the new system successful for you?
Advantages of Interviews
- Deep information can be collected.
- Immediate clarification is possible.
- Body language and hesitation can reveal hidden concerns.
- Good for complex or sensitive requirements.
Limitations of Interviews
- Time-consuming for large groups.
- Stakeholders may forget important details.
- Quality depends heavily on the analyst’s questioning skill.
Questionnaire and Survey Technique
A questionnaire contains a list of written questions sent to stakeholders. It is useful when the project has many users or the users are geographically distributed.
Closed Questions
Users choose from fixed answers such as Yes/No, ratings, or options.
Easy to compare and analyse.
Open Questions
Users write their own answers.
Useful for discovering unexpected opinions and requirements.
Advantages
- Can reach many users quickly.
- Low cost compared with individual interviews.
- Easy to collect measurable feedback.
Disadvantages
- Response rate may be low.
- No immediate clarification.
- Users may misunderstand questions.
Observation and Ethnographic Study
Sometimes users cannot properly explain how they work because many actions have become automatic habits. In such cases, observation becomes very useful.
The analyst watches users perform real tasks and studies:
- actual work sequence,
- exceptions,
- manual shortcuts,
- communication between people,
- real delays and problems.
A hospital staff member may say that patient registration is simple. But observation may show that staff actually check several paper records, call another department, and manually verify insurance before completing registration. These hidden steps may become important software requirements.
Ethnographic-style observation goes deeper by studying users in their natural working environment over time.
Workshops, JAD and Brainstorming
Requirement Workshop
A workshop brings multiple stakeholders together in one structured session. A facilitator guides discussion and helps participants reach common understanding.
JAD – Joint Application Development
JAD is a structured collaborative technique in which users, managers, analysts, and developers work together to define or refine system requirements.
Brainstorming
Brainstorming encourages participants to generate many ideas without immediately rejecting them. Later, useful ideas are filtered and analysed.
Main Benefits
- Fast discussion among multiple stakeholders
- Conflicts can be identified early
- Improves shared understanding
- Good for discovering new ideas
Possible Problems
- Dominant participants may influence others
- Meetings may become unfocused
- Good facilitation is required
Prototyping, Use Cases and Scenarios
Prototyping
A prototype is an early sample or mock-up of the software. Users can interact with it and say what they like, dislike, or expected differently.
Prototyping is especially useful for:
- UI-heavy systems,
- unclear workflows,
- new or innovative products,
- users who cannot describe needs clearly in words.
Use Cases
A use case explains how an actor interacts with the system to achieve a goal.
Example: Student attempts online exam.
- Student logs in.
- Student selects available exam.
- System displays instructions.
- Student begins exam.
- Answers are saved.
- Student submits exam.
- System stores final response.
By writing this scenario, many hidden requirements become visible.
Requirement Analysis Process
After requirements are gathered, analysis converts them into a cleaner and more useful form.
Main Activities Performed During Requirement Analysis
Classification
Requirements are grouped into functional, non-functional, business, domain, interface, and other categories.
Feasibility Check
The team checks whether the requirement is technically and economically possible.
Dependency Analysis
Analysts identify which requirements depend on other requirements.
Conflict Detection
Contradictory stakeholder demands are identified.
Prioritization
Requirements are ranked according to importance and business value.
Modelling
Diagrams and models help represent system behaviour and structure clearly.
Requirement Prioritization
Not every requirement can always be implemented in the first release. Budget, time, and resources are limited. So requirements must be prioritized.
MoSCoW Prioritization Technique
Must Have
Essential requirement. Without it, the system or release is not acceptable.
Should Have
Important but can temporarily wait if necessary.
Could Have
Useful optional requirement if time and resources allow.
Won't Have Now
Not included in the current scope or current release.
Other Prioritization Factors
- business value,
- risk,
- cost,
- technical dependency,
- legal requirement,
- user impact,
- implementation effort.
Requirement Conflict Resolution and Negotiation
Different stakeholders may want different things. Requirement analysis must resolve these conflicts.
Example Conflict
A security team may want logout after 2 minutes of inactivity. Users may want the session to remain active for 30 minutes.
Both sides have valid reasons.
Negotiated Solution
The team may agree on a moderate timeout, or different timeout rules depending on activity type and risk.
Negotiation Process
- Identify conflicting requirements.
- Understand why each stakeholder wants them.
- Study impact on cost, risk, time, and usability.
- Discuss alternatives.
- Agree on a practical solution.
- Document the final decision.
Requirement Modelling
Requirement models help represent complicated requirements visually and logically. They make communication easier between users and technical teams.
Use Case Diagram
Shows actors and their interactions with the system.
Data Flow Diagram
Shows how information moves through the system.
Activity Diagram
Shows process steps and workflow.
State Model
Shows different states of an object and transitions between them.
ER Model
Helps represent data entities and their relationships.
Decision Table
Useful when many conditions and business rules affect the final action.
Characteristics of a Good Analysed Requirement
Common Problems During Elicitation and Analysis
Elicitation Problems
- Users do not know exactly what they want
- Different users give different answers
- Stakeholders may hide important details
- Technical language may confuse users
- Important stakeholders may be missed
Analysis Problems
- Conflicting requirements
- Unclear or ambiguous statements
- Unrealistic requirements
- Changing business needs
- Difficulty deciding priority
Real-Life Example: Requirement Elicitation & Analysis for a Food Delivery App
Notice the difference:
Raw statement: “Hume order miss nahi hona chahiye.”
Analysed requirement: “The restaurant dashboard shall generate a visible and audible notification for every new order until the restaurant acknowledges it.”
This is exactly what requirement analysis does: it converts vague needs into clear software requirements.
Comparison of Major Elicitation Techniques
| Technique | Best Use | Main Advantage | Main Limitation |
|---|---|---|---|
| Interview | Detailed individual understanding | Deep and flexible discussion | Time-consuming |
| Questionnaire | Large user population | Fast and low cost | Limited clarification |
| Observation | Real workflow analysis | Finds hidden requirements | Can take time |
| Workshop / JAD | Multiple stakeholder agreement | Fast conflict resolution | Needs skilled facilitation |
| Prototyping | Unclear UI or workflow | Users react to something visible | Users may mistake prototype for final system |
| Document Analysis | Existing organization/process | Uses real existing evidence | Documents may be outdated |
| Focus Group | User opinions and preferences | Multiple views at once | Group influence can affect answers |
Memory Tricks for Requirement Elicitation and Analysis
- I – Interview
- Q – Questionnaire
- O – Observation
- W – Workshop
- P – Prototype
- D – Document Analysis
- U – Use Cases
- C – Classification
- F – Feasibility
- D – Dependency & Duplicate Check
- P – Prioritization
- N – Negotiation
- M – Modelling
How to Write This Topic in Semester Exam
For 2 Marks
Write:
Requirement elicitation is the process of gathering requirements from stakeholders and other sources, while requirement analysis refines, prioritizes, and resolves those requirements before specification.
For 5 Marks
- Definition of elicitation
- Definition of analysis
- Major elicitation techniques
- Main analysis activities
- Short conclusion
For 10 Marks
- Introduction
- Elicitation meaning
- Requirement sources
- Stakeholders
- Elicitation techniques
- Analysis process
- Prioritization & negotiation
- Modelling
- Example
- Conclusion
10 Mark Ready Answer: Requirement Elicitation and Analysis
Requirement Elicitation and Requirement Analysis are important activities of Requirement Engineering. Requirement Elicitation is the process of discovering and collecting software requirements from users, customers, domain experts, documents, existing systems, and other stakeholders.
Elicitation can be performed using techniques such as interviews, questionnaires, observation, workshops, brainstorming, prototyping, document analysis, focus groups, use cases, and scenarios.
After requirements are collected, Requirement Analysis is performed. During analysis, requirements are classified, checked for feasibility, compared for conflicts, prioritized, negotiated, modelled, and refined.
Analysis also ensures that requirements are clear, complete, consistent, necessary, feasible, and testable.
Therefore, elicitation helps discover what stakeholders want, while analysis transforms those raw needs into a clear and practical set of software requirements.
Scoring Conclusion
Requirement Elicitation collects stakeholder needs, while Requirement Analysis converts those needs into clear, agreed, prioritized, and implementable software requirements.
Quick Revision Notes
Elicitation: Discovering and collecting requirements.
Analysis: Studying, refining, prioritizing, and resolving requirements.
Requirement Sources: Users, customers, documents, old systems, domain experts, regulations.
Main Elicitation Techniques: Interview, questionnaire, observation, workshop, brainstorming, prototype, document analysis, focus group, use cases.
Main Analysis Activities: Classification, feasibility, conflict detection, dependency analysis, prioritization, negotiation, modelling.
MoSCoW: Must, Should, Could, Won't Have Now.
Good Requirement: Correct, clear, complete, consistent, feasible, testable, necessary, prioritized.
Main Difference: Elicitation gives raw requirements; analysis gives refined requirements.
Important Viva Questions
It is the process of discovering and collecting requirements from stakeholders and other sources.
It is the process of refining, prioritizing, checking, modelling, and resolving collected requirements.
Interview, questionnaire, observation, and prototyping.
It helps discover real work practices and hidden requirements that users may forget to explain.
It classifies requirements as Must Have, Should Have, Could Have, and Won't Have Now.
Because stakeholders may have conflicting requirements, priorities, and constraints.
It is the use of diagrams and structured representations to understand requirements more clearly.
Frequently Asked Questions
No single technique is best for every project. Good requirement engineers normally combine multiple techniques.
Yes. In real projects, analysts often analyse early information and then return to stakeholders for further clarification.
Because users can react to something visible instead of trying to imagine the whole software from words alone.
Raw, conflicting, unrealistic, or ambiguous requirements may directly enter design and development, increasing project risk.
A refined, agreed, prioritized, feasible, and well-understood set of requirements ready for specification and validation.
Conclusion
Requirement Elicitation and Analysis form the core of Requirement Engineering. Elicitation helps software teams discover real user and business needs, while analysis converts those needs into a form that can be understood, prioritized, negotiated, designed, implemented, and tested.
Interviews, questionnaires, observation, workshops, prototypes, document analysis, scenarios, and use cases help uncover requirements from different angles.
Analysis then checks those requirements for feasibility, conflicts, dependencies, clarity, completeness, and priority.
The main lesson is simple: good software starts with good understanding, and good understanding starts with good elicitation and analysis.
Requirement Elicitation discovers stakeholder needs, while Requirement Analysis transforms those raw needs into clear, feasible, prioritized, and agreed software requirements.
Quick recall: Discover → Question → Observe → Analyse → Prioritize → Negotiate → Model
