3.2 Elicitation In Real Projects
Requirements are discovered, negotiated, and tested. They rarely arrive fully formed. In real projects, stakeholders often know their pain better than they know the solution, and they often leave out the workarounds they perform every day.
Elicitation is the discipline of making hidden needs visible.
Techniques and what they reveal
| Technique | Good for | Weakness |
|---|---|---|
| Interview | Goals, frustration, decision logic | People may report ideal behavior, not actual behavior |
| Questionnaire | Broad patterns across many users | Shallow detail and weak follow-up |
| Observation | Real workflow, interruptions, workarounds | Time-consuming and context-specific |
| Workshop | Shared language and conflict discovery | Can be dominated by loud voices |
| Document review | Policies, contracts, regulations | Documents may be stale |
| Data analysis | Frequency and bottlenecks | Explains what happened, not always why |
The best teams mix techniques. A workshop may reveal conflict, observation may reveal hidden work, and data may show which exception path actually matters most.
Ask better questions
Weak question: "What feature do you want?"
Better questions:
- What are you trying to accomplish?
- What happens right before and right after this step?
- What do you do when the system cannot handle the case?
- Which exceptions are rare but dangerous?
- What would make this workflow unacceptable, even if the happy path works?
Real project warning
Stakeholders do not all want the same thing. Users may want speed, compliance may want evidence, support may want manual overrides, security may want fewer privileges, and business owners may want growth.
Your job is not to flatten these voices into one fake consensus. Your job is to surface the conflict early enough that the right people can make a decision.