Requirements elicitation

Technique · Chapter 3

The idea in brief

• Requirements deal with knowns and unknowns — known knowns, known unknowns, and unknown unknowns. Elicitation aims to eliminate the unknown unknowns before design.
• Stakeholders often don’t know exactly what they want, and requirements “rarely lie on the surface” (Hunt & Thomas, The Pragmatic Programmer) — they’re buried under assumptions, misconceptions, and politics.
• Elicitation (aka requirements gathering) is a proactive, not reactive, process. Combining multiple techniques often yields the best results.

Elicitation techniques

Technique	What it is	Strengths	Watch out for
Interviews	Formal or informal sessions with one person or a small group; ask open-ended questions to spur discussion, closed-ended to confirm facts	Different stakeholder types give different perspectives; good for gathering info	Depends on interviewee’s knowledge/willingness; poor for reaching consensus (not everyone present); assign a note-taker
Requirements workshops	Group of relevant stakeholders meets to collect and prioritize requirements	One of the most common and effective methods; builds clarity	Needs a facilitator + separate note-taker, a clear agenda, and the right number of people; hard to gather everyone (run multiple sessions if needed)
Brainstorming	Spontaneous idea generation from a group, documented as you go	Fun, productive; varied stakeholders surface unconsidered ideas	Keep to 5-10 people; clear goals/scope; no criticism allowed; facilitator steers off-topic talk; use a visible whiteboard/shared screen; set a time limit
Observation	Studying a stakeholder doing real work in their environment (passive = non-disruptive, active = ongoing dialog)	Reveals requirements stakeholders forget or don’t realize are requirements; great for understanding current processes	Time-consuming and potentially disruptive; may miss infrequent scenarios; use as a supplement, not the only technique
Focus groups	More formal than brainstorming; invited group (often external users/experts) gives feedback via a neutral moderator	Good for public/external-facing apps; observe nonverbal cues and group interaction; faster than individual interviews	Risk of following the crowd; some hesitate to share; moderator may be a paid hire
Surveys	Written questionnaires with a clear purpose	Scales to many stakeholders; closed-ended questions are easy to analyze	People avoid long surveys — prefer several focused ones; open-ended answers cost more to analyze
Document analysis	Mining existing docs (manuals, contracts, SOWs, emails, training materials, COTS manuals) for requirements	Existing systems/docs seed the new requirements; useful when stakeholders are unavailable	Assumes usable artifacts exist
Prototyping	Building a prototype/wireframes (or even a working version) stakeholders can see or use	Triggers ideas for visually-oriented people; validates requirements; agile iterations reveal what works and what doesn’t	Takes time to build; best combined with other techniques
Reverse engineering	Analyzing existing source code to determine requirements	Powerful when an existing system embodies exactly what must happen; useful when stakeholders/docs are unavailable	Time-consuming; needs source-code access and technical skill; often a last resort

Get access to the proper stakeholders

• Even with good techniques, the right stakeholders may be unavailable, unhelpful, or unwilling to participate.
• Because requirements analysis is so important, make the effort to get access — this may mean escalating to your own management or the stakeholder’s organization’s management.
• Many stakeholders are external to your organization, which makes access harder; the project’s success may depend on it.

Related concepts

• Requirements engineering
• Developing business acumen
• Domain-driven design

Citations

• Software Architect’s Handbook (Packt, 2018), Ch.3 “Requirements elicitation”, pp. 163-175.