Add Your Heading Text Here
Requirements elicitation
Requirements elicitation is the work of drawing out what stakeholders actually need, using techniques like interviews, workshops, observation, and prototyping. It is the discovery stage of requirements work, where a team uncovers goals, constraints, and unspoken assumptions rather than simply collecting a wish list of features.
What it means
The word 'elicitation' is chosen on purpose. You rarely get requirements by asking 'what do you want' and writing down the answer. People describe solutions when they mean problems, forget the obvious, and disagree with each other. Elicitation is the active work of surfacing the real need underneath, through good questions, watching how work actually happens, and showing early prototypes to react to.
Do it badly and the whole project inherits the mistake, because everything downstream is built on what was elicited. Different techniques suit different situations: interviews for depth, workshops for alignment, observation for the steps people never think to mention. The output feeds into analysis and then into written requirements that the team can trace and manage.
In practice
While building a warehouse app, an analyst spends a morning on the floor watching pickers work. She notices they scan items one-handed while holding a scanner, a detail nobody mentioned in the kickoff meeting. That single observation reshapes a core requirement about the interface, which a list of feature requests would never have caught.
FAQ
What are common requirements elicitation techniques?
What is the difference between elicitation and requirements gathering?
Manage requirements the modern way
Modern Requirements brings documentation, traceability, and reviews together inside Azure DevOps.
