SE Notes
Methods for eliciting requirements from stakeholders.
Requirement gathering (elicitation) is the process of discovering what stakeholders need from a software system. This is far more challenging than it sounds—stakeholders often cannot articulate their needs clearly, have conflicting priorities, make assumptions they do not realize are assumptions, and may not even know what is possible with current technology. Effective elicitation requires multiple techniques applied skillfully to different stakeholder groups, uncovering both explicit needs (what they say they want) and implicit needs (what they need but do not think to mention).
Interviews
The most common elicitation technique—direct, structured conversations with stakeholders.
Structured Interviews follow a predetermined script of questions, ensuring consistent coverage across multiple interviewees. Best for gathering specific information from many people.
Unstructured Interviews are free-flowing conversations that follow the interviewee's thought process. Best for exploration and discovering unexpected requirements.
Semi-Structured Interviews combine both—a prepared outline with flexibility to explore interesting tangents.
Interview best practices:
- Prepare questions in advance but remain flexible
- Ask open-ended questions ("Walk me through your typical day") before specific questions ("How do you handle returns?")
- Listen actively—paraphrase and confirm understanding
- Ask "why?" to understand motivations, not just actions
- Record interviews (with permission) to avoid losing details
- Follow up to clarify ambiguities discovered during analysis
Workshops and Focus Groups
Facilitated group sessions bring multiple stakeholders together to discuss requirements collaboratively.
JAD (Joint Application Development) Sessions bring users, developers, and management together in structured workshops lasting 1-5 days. A trained facilitator guides discussion through a defined agenda, resolving conflicts in real-time.
Brainstorming generates ideas without judgment. Participants suggest requirements freely; evaluation happens later. Effective for discovering innovative features and exploring possibilities.
Story Mapping arranges user activities and stories on a wall, creating a visual map of the system's functionality organized by user workflow and priority.
Observation
Watching users perform their current tasks reveals requirements that interviews miss—habits so ingrained that users forget to mention them.
Active Observation involves the analyst asking questions while watching: "Why did you just check that screen?" "What are you looking for in this printout?"
Passive Observation watches without interrupting, noting patterns, workarounds, and pain points. Users often develop creative workarounds for system limitations that reveal unspoken requirements.
Ethnographic Study embeds the analyst in the user's environment for extended periods, developing deep understanding of workflows, culture, and implicit rules.
Prototyping
Building a preliminary model of the system to help stakeholders visualize and react to proposed solutions.
Paper Prototypes are hand-drawn screens showing layout and navigation. Quick to create and modify—stakeholders feel comfortable criticizing sketches.
Wireframes are digital layouts showing structure without visual design. Tools like Balsamiq or Figma create clickable wireframes that simulate navigation.
Functional Prototypes implement core interactions with real (or simulated) data, allowing stakeholders to experience the system's behavior.
Prototyping is particularly effective when stakeholders cannot articulate requirements abstractly but can react to concrete proposals: "I don't know what I want, but I'll know it when I see it."
Document Analysis
Examining existing documentation to discover requirements:
- Current system manuals and help files
- Business process documentation
- Regulatory and compliance documents
- Forms currently in use (paper or electronic)
- Reports currently generated
- Previous project documentation
- Competitor product documentation
Surveys and Questionnaires
Efficient for gathering input from large, geographically distributed stakeholder groups. Best for quantifying preferences (ranking features by importance), validating requirements discovered through other techniques, and collecting demographic data about user populations.
Limitations: Cannot probe deeper on interesting responses, response rates may be low, and closed questions may miss unexpected needs.
Real-World Example: Hospital System Elicitation
Building a new patient scheduling system, the team uses multiple techniques:
Interviews (Week 1-2): Meet individually with 3 doctors, 5 nurses, 2 receptionists, 1 IT administrator, 1 billing manager. Discover each role's priorities and pain points.
Observation (Week 2-3): Spend 3 days observing the reception desk during peak hours. Notice: receptionists use sticky notes to track "soft" preferences not in the current system (e.g., "this patient prefers Dr. Smith but will see any available doctor on Tuesdays").
Workshop (Week 3): Bring all stakeholder representatives together. Use story mapping to visualize the complete scheduling workflow. Conflicts emerge: doctors want 30-minute appointment slots; administrators want 15-minute slots to increase throughput. Negotiate resolution: 15-minute default with configurable per-procedure-type durations.
Prototype (Week 4-5): Build clickable wireframes of the scheduling interface. Receptionists immediately identify: "Where do I see which rooms are available? I always check room availability before booking." This requirement was never mentioned in interviews—it was so automatic they forgot to mention it.
Choosing Techniques
No single technique uncovers all requirements. Effective elicitation combines multiple approaches: interviews for depth, observation for hidden requirements, workshops for conflict resolution, prototypes for validation, document analysis for existing constraints, and surveys for broad input. The specific mix depends on stakeholder availability, project timeline, and the nature of the system being built.
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Requirement Gathering Techniques.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this Software Engineering topic.
Search Terms
software-engineering, software engineering, software, engineering, requirements, requirement, gathering, techniques
Related Software Engineering Topics