Why is elicitation harder than just asking users what they want?

Stakeholders often cannot fully articulate their needs, hold conflicting goals, or omit knowledge they consider obvious; elicitation must surface this tacit and contested knowledge through a mix of techniques rather than a single interview.

What is the role of prototyping in elicitation?

Prototypes give stakeholders something concrete to react to, exposing misunderstandings and unstated expectations far more effectively than abstract descriptions, which makes prototyping a powerful elicitation as well as validation technique.

Requirements Elicitation

Requirements elicitation is the activity of discovering the needs, goals, and constraints of stakeholders that a software system must satisfy, drawing them out from people, documents, and the operating context.

Definition

Requirements elicitation is the process of seeking, capturing, and consolidating requirements from stakeholders and other sources, surfacing both stated needs and tacit or unstated expectations.

Scope

This topic covers elicitation techniques such as interviews, workshops, questionnaires, observation and ethnography, prototyping, scenario and use-case analysis, and document and domain study; the identification of stakeholders and their viewpoints; and the challenges of tacit knowledge, conflicting interests, and communication across disciplines.

Core questions

Who are the stakeholders and how are their viewpoints identified?
Which techniques best surface tacit and conflicting needs?
How can the operating context and domain knowledge be captured?
How are ambiguity and miscommunication minimized during discovery?

Key theories

Multi-technique elicitation: No single technique suffices; interviews, observation, prototyping, and scenario analysis are combined and chosen according to stakeholder availability, domain familiarity, and the tacitness of the knowledge sought.
Viewpoint and stakeholder analysis: Requirements are gathered from multiple stakeholder viewpoints, which are then reconciled; explicitly modeling viewpoints exposes conflicts and gaps that a single perspective would miss.

Clinical relevance

Effective elicitation determines whether the resulting system addresses real needs; incomplete or biased elicitation is a leading cause of project failure, so technique selection and stakeholder coverage are critical early decisions.

Evidence & guidelines

The SWEBOK Software Requirements knowledge area and ISO/IEC/IEEE 29148 describe elicitation sources and techniques as part of the requirements process.

History

Early requirements practice relied mainly on interviews and document study; from the 1990s, the field broadened to incorporate ethnographic observation, scenario and goal modeling, and participatory techniques, recognizing that much critical knowledge is tacit and socially situated.

Key figures

Joseph Goguen
Axel van Lamsweerde
Ian Sommerville

Seminal works

vanlamsweerde2009
goguen1993
sommerville2015

Frequently asked questions

Why is elicitation harder than just asking users what they want?: Stakeholders often cannot fully articulate their needs, hold conflicting goals, or omit knowledge they consider obvious; elicitation must surface this tacit and contested knowledge through a mix of techniques rather than a single interview.
What is the role of prototyping in elicitation?: Prototypes give stakeholders something concrete to react to, exposing misunderstandings and unstated expectations far more effectively than abstract descriptions, which makes prototyping a powerful elicitation as well as validation technique.