Ask Better: Requirements Elicitation Techniques and When Each One Earns Its Hour
Share the page:
Requirements elicitation is the work of drawing out what a system has to do from the people, documents, data, and systems that currently hold the answer. There are nine techniques in common use, and most projects use one: the interview. Interviews tell you what people believe the process is. Observation tells you what it is. Document analysis finds the rules nobody remembers, and data analysis finds how often each case happens. Each technique costs your staff a different number of hours and prevents a different class of defect, so the choice is a budget decision as much as a methods one. For the sponsor approving those hours: which technique fits which stakeholder, what each costs, what goes wrong when interviews stand alone, and how to tell when elicitation is finished.
Introduction
The request for staff time arrives as a calendar block: "Requirements workshop, 3 hours, all leads to attend." Eight people, half a day, a projector. Four weeks later the requirements document arrives and the operations lead says the workshop never discussed the month-end exceptions, which are the only part of the process that ever breaks.
Every page that ranks for requirements elicitation techniques is written for the analyst running the workshop. This one is written for the person who approved the eight calendars, because the choice of technique decides what the analyst can find and what the business pays to have it found. Nine techniques, each with a stakeholder it suits, a cost in staff hours, and a defect it is good at preventing. The point is to spend the hours where the defects are.
What is requirements elicitation?
Requirements elicitation is the set of activities an analyst uses to draw out what a system must do, from the people who do the work, the documents that govern it, the data the current system holds, and the systems it connects to. The word is chosen over "gathering" for a reason. Requirements are not lying around waiting to be collected; most of them are in someone's head, or in a workaround nobody has written down, or in a field in a database that three departments populate differently. They have to be drawn out, and the technique decides which ones surface.
The International Institute of Business Analysis lists the techniques in the BABOK Guide, and the nine that carry most projects are interviews, requirements workshops, observation, document analysis, interface analysis, data analysis of the current system's records, prototyping, surveys, and focus groups. They are not interchangeable. An interview is good at motives and bad at frequencies. Observation is good at exceptions and bad at strategy. Document analysis is good at rules and bad at telling you which rules are still followed. A program that uses one technique gets one kind of truth.
What the sponsor is buying is coverage: every process in scope seen through at least two techniques, every stakeholder group heard through more than one channel, and every requirement traceable to a source that can be checked. The BABOK guide for hiring managers covers where elicitation sits among the other analysis disciplines; this guide stays on the techniques and what they cost.
Key Takeaway: Elicitation is drawing out, not collecting. Each technique surfaces a different kind of requirement, so coverage comes from combining them, and the combination is a budget decision.
Which elicitation technique fits which stakeholder and decision?
Match the technique to who holds the answer and what kind of answer it is: motives and priorities from senior people in interviews, hand-offs and disagreements in workshops, exceptions and workarounds through observation, rules from documents, volumes from data. The table gives the nine techniques with the stakeholder each suits, what it costs the business in staff hours on a typical mid-size program, and the defect it prevents.
The reading of that table that matters to a sponsor is the cost column against the defect column. Workshops are the most expensive hour in the plan and prevent one specific class of defect, the cross-department contradiction. Observation and document analysis cost the business almost nothing and prevent the two classes that cause most production incidents: the unhandled exception and the forgotten rule. Most elicitation plans invert that, with three workshops and no observation, because workshops are visible and observation looks like an analyst sitting quietly in the corner.
Key Takeaway: Spend workshop hours on conflicts that need everyone in the room. Spend observation and document time, which cost the business nothing, on exceptions and rules, which cause most of the incidents.
How much of your staff's time does each technique cost?
For a mid-size program, a sound elicitation plan costs the business between 120 and 200 staff hours over four to six weeks, and the mix decides whether those hours buy coverage or repetition. Here is the arithmetic for a program touching three departments and two systems, the shape we see most often.
Interviews: fifteen people at one hour each, plus twenty minutes to review notes, about 20 staff hours. Workshops: three sessions of three hours with eight people, 72 staff hours, the largest line by far. Observation: three days of an analyst sitting with operators across the three departments, perhaps five staff hours of questions answered while working. Document analysis: two days of analyst time and two staff hours to locate the documents and explain the folder structure. Interface analysis: two systems at three hours each with their owners, six hours. Data analysis: three hours from a data owner for access and context. Prototyping: eight users at 45 minutes for two rounds, twelve hours. Total: roughly 120 staff hours, of which 72 are workshops.
That proportion is the point. The workshops cost sixty percent of the budget and are the only technique whose output depends on who happened to speak. A plan that drops one workshop and spends the 24 saved hours on a second round of observation and a wider interview list usually finds more and contradicts itself less. The failure we see most often is the reverse: a sponsor approves four workshops because they are visible and declines three days of observation because "the analyst can just ask," and the requirements document arrives with the month-end exceptions missing because nobody in the workshop handles month-end.
ID Business Analysis Canada opens a Requirements Engagement with an elicitation plan that lists every technique, the people it needs by role, and the hours it will cost each department, so the sponsor approves the staff time as a budget line before the first interview is booked and can see where the observation days are.
Key Takeaway: Ask for the elicitation plan as a table of hours by technique and department before approving a single workshop. If workshops are more than half the hours, ask what observation was traded for them.
What goes wrong when interviews are the only technique?
The requirements document describes the process as the interviewees believe it to be, which is the version in the procedure manual, several years out of date, with none of the exceptions that make the work hard. Interviews are the easiest technique to schedule and the one whose weaknesses are best hidden, because every interview produces confident, articulate answers.
Four things go wrong. People describe the intended process, not the performed one; the clerk who re-keys the invoice total into a spreadsheet every afternoon does not mention it, because it is not part of the process, it is just what she does. People remember recent and dramatic cases and forget frequent, dull ones, so the requirements over-serve last quarter's incident and under-serve Tuesday. Senior people, who get the most interview time, are furthest from the exceptions. And two interviewees give two accounts of the same step, the analyst records both, and the contradiction surfaces in test, which is the problem the requirements verification methods exist to catch.
An interview tells you what people believe the process is. Observation tells you what it is. Data tells you how often. A program needs all three, and the pattern we see on the ones that only interviewed is a specification that is internally consistent, approved by everyone who was interviewed, and wrong about the twenty percent of cases that are not the happy path. The process mapping guide covers how observation turns into a current-state map; the point here is that it has to happen at all.
Key Takeaway: Interviews produce the manual's version of the process. Pair every interview program with observation and a data pull, or expect the exceptions to arrive in production.
How do you know elicitation is finished?
When six criteria hold, written down before elicitation starts so that "finished" is a test rather than a feeling. Elicitation without exit criteria ends when the calendar runs out, and the calendar does not know what was missed.
Every process in scope has been observed at least once, on a real case, by someone who was not performing it. Every stakeholder group has been heard through at least two techniques, so no requirement rests on one interview. Every requirement traces to a source: a named person, a document, a data finding, or an observed case. The open questions list has reached zero, or every remaining item is parked with an owner and a date. Every conflict between stakeholders is logged with a decision owner named, even if the decision is not yet made. And the last two sessions produced no new requirements, only confirmation of existing ones, which is the signal that the well is dry rather than that the analyst is tired.
The sixth criterion is the one teams skip. Elicitation has diminishing returns, and the honest way to know you have reached them is to keep going one session past the point where you think you are done and see whether anything new appears. If it does, you were not done. If the session confirms what you had, the set is ready for verification, and the hours stop.
Key Takeaway: Write the six exit criteria before the first interview. Elicitation ends when the criteria are met, not when the schedule is.
Frequently Asked Questions
What are the main requirements elicitation techniques?Nine techniques carry most projects: interviews, requirements workshops, observation, document analysis, interface analysis, data analysis of the current system's records, prototyping, surveys, and focus groups. The BABOK Guide lists these and several others. Each one suits a different source of requirements: interviews for motives and priorities, workshops for cross-department conflicts, observation for exceptions and workarounds, document analysis for rules, data analysis for volumes and frequencies, prototyping for usability, surveys for dispersed user groups, and focus groups for external users.
What is the difference between requirements elicitation and requirements gathering?Gathering implies the requirements already exist in a collectable form and the analyst's job is to pick them up. Elicitation recognizes that most requirements are not written anywhere: they are in how people do the work, in rules nobody remembers agreeing to, and in data patterns nobody has looked at. The distinction matters in practice because a gathering mindset stops at interviews and documents, while an elicitation mindset adds observation and data analysis, which is where the exceptions live.
How long does requirements elicitation take?Four to six weeks for a mid-size program touching two or three departments and a couple of systems, costing the business roughly 120 to 200 staff hours depending on the technique mix. A single-department change can be done in two weeks. The duration is set by the exit criteria rather than the calendar: every process observed, every stakeholder group heard twice, every requirement traced to a source, conflicts logged with owners, and two sessions with nothing new. Finishing early against those criteria is finishing; without them it is stopping.
Who should run requirements elicitation, and how do we start?A business analyst who did not design the current process and has no stake in the solution, working to a written plan the sponsor has approved. Start by asking for that plan: the techniques, the people each needs by role, and the hours it will cost each department. ID Business Analysis Canada runs elicitation inside a Requirements Engagement from that plan, with observation days alongside the interviews and workshops, a data pull in week one, and the six exit criteria agreed with the sponsor before the first session is booked.
Conclusion
The three-hour workshop with eight leads was not wrong; it was alone. The month-end exceptions were never going to appear in it, because the people who handle month-end were not in the room and the people who were had never seen one. Three days of an analyst sitting in the finance office, which would have cost the business almost nothing, would have found them.
If a requirements effort is about to ask for your staff's time, ID Business Analysis Canada's Analysis & Design practice starts with the elicitation plan described here: nine techniques matched to the stakeholders who hold the answers, hours by department approved up front, observation and data analysis alongside the interviews, and exit criteria that decide when the hours stop. Book a free consultation and bring the calendar invitation; the first thing we will do is ask who handles month-end.
Sources
- International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge (BABOK Guide), version 3; elicitation technique names referenced, descriptions and cost figures in this article are the author's own.
- Business Analysis Canada, The Standard Behind the Role: The BABOK Guide for People Who Hire Business Analysts, business-analysis.ca blog, September 2026.
- Business Analysis Canada, Prove It Early: Requirements Verification Methods That Catch Defects Before Build, business-analysis.ca blog, September 2026.
- Business Analysis Canada, Process Mapping for IT Projects: BPMN, Swimlane or Flowchart, business-analysis.ca blog, October 2026.
- Business Analysis Canada, Guarding the Gate: The Value of a Project Discovery Phase in IT Strategy, business-analysis.ca blog, August 2026.