Requirements Elicitation: Uncovering the Real Need with Interviews, Observation, Workshops and Prototypes

Version note: This post is conceptual; the preparation, conduct and confirmation steps of elicitation follow the Elicitation and Collaboration knowledge area of the BABOK Guide v3 from IIBA, and terminology follows ISO/IEC/IEEE 29148:2018, the joint standard of ISO (International Organization for Standardization), IEC and IEEE (Institute of Electrical and Electronics Engineers).

Guess First

In the previous post the Bookstore team wrote down, for the first time, the problem behind Hakan's request for "an Excel upload screen": institutions' book lists arrive in different formats, customer service types them in by hand, orders pile up in September and wrong books get shipped. Selin, the Product Owner, has two weeks until the first sprint planning for the bulk ordering feature.

Three people are ready to talk. Hakan, the corporate sales manager, has worked with schools for twelve years and is sure he knows what is wanted. A private school's vice principal is the person who signs the orders. Ms. Nevin, the same school's purchasing officer, is the one who collects the lists from teachers and prepares them. If Selin has only one day, who should she talk to first?

Second question: which of these two questions should open the interview? "What would you like to have on the bulk order screen?" or "How did you prepare last September's order? Can you walk me through it from the beginning?"

Elicitation: Uncovering, Not Gathering

This work is often called "gathering requirements", and the phrase is misleading. Gathering implies requirements are lying around somewhere, ready for someone to collect them in a basket. In reality most requirements do not exist as sentences in anyone's head; they emerge while a stakeholder describes their work, in a note in the margin of a document, or while clicking through a prototype. ISO/IEC/IEEE 29148 also defines elicitation not as passive collection but as proactively identifying needs with systematic techniques such as prototyping and structured surveys.

BABOK splits the work into three steps, and the split is very practical even for a developer. Preparation: choosing the scope, who to talk to and which technique to use. Conduct: doing the interview, the observation, the workshop; what comes out of it is, in BABOK's terms, unconfirmed information. Confirmation: taking what was understood back to the stakeholder to ask "did we get this right?" and reconciling contradictions between sources. Most teams do the second step, skip the third, and move sentences from their notebook into the backlog as requirements.

BABOK also groups techniques into three kinds: direct interaction with stakeholders (interviews, workshops), research on existing data and documents (document analysis), and controlled experiments (prototypes). In this post we use at least one technique from each group on bulk orders.

Let's draw one boundary up front. Finding which problem is worth solving, product discovery, was the subject of the "Product Discovery" post in the Introduction to Product Management series; the customer interview principles from that post apply here too. Elicitation usually starts after the problem has been chosen and asks: which rules, which exceptions and which constraints exactly must the system that solves this problem respect?

Stakeholder Map

The first step of elicitation is working out who is affected by the feature and who knows something about it. Selin and the developers Emre and Ayşe put this list together in half an hour:

The most valuable rows in the table are the ones nobody thinks of first. Teachers will never use the system, but they are the reason lists arrive per class section and by title. The foundation's accounting office will not log in either, but it gives the only real answer to "who is the invoice issued to?". When building the map, look at two things separately for each row: the person's influence over decisions and what the person knows about the work. Hakan has a lot of influence; Gül has a lot of knowledge. Elicitation needs both, but don't expect the same thing from both.

Interviews: "Tell Me About the Last Time"

The second of the two questions in Guess First is the right opening. "What would you like to have?" pushes the other person into the role of product designer; the answer is usually a feature they saw on another website. "How did you do it last time?" makes them tell a story that actually happened, and stories are full of exceptions.

Selin and Emre go into a forty-five-minute interview with Ms. Nevin with a list of questions, but they don't stick to it rigidly. An excerpt:

"Think about last September's order. What was the first step?" Ms. Nevin explains: in June she sends an empty spreadsheet to fourteen department heads; the sheets come back by mid-August, some with book titles, some with ISBNs. "And then?" She merges the sheets into one file, combines the class sections that want the same book, and sends the total to the foundation's accounting office for approval. "How long does approval take?" A week; if the foundation's budget approval does not come by August 15, the order slips to the second week of September. "What happened after the order was sent?" In the first week of school three teachers changed their lists, and Ms. Nevin sent the corrections in separate emails. "Where did the books arrive?" The school has three campuses; each campus needs its own boxes, but last year everything arrived at the main campus and was distributed with the school bus.

None of what came out of those forty-five minutes was in Hakan's email: budget approval depends on a date, lists change even after the order is placed, there is more than one delivery point, and the invoice goes to the foundation, not the school. We asked Ms. Nevin about none of it directly; she mentioned it all on her own while telling the story.

A good interview has a few habits. Ask about a concrete event and follow its order. Expand each answer with another "and then?" instead of closing it with your interpretation. When you hear an exception, stop there: "How often did this happen? When was the last time?" Don't share your own solution idea in the interview; the other person will agree to please you. And always ask at the end: "Is there anything I didn't ask you but should have?"

The interview with the library director reveals a completely different flow: the municipality first asks for a written price quote, no order can be placed until the quote is approved internally, and payment is made by invoice after delivery. Behind the same word "bulk order" there are two different processes.

Observation and Document Analysis

When people describe their work, they skip the steps that have become habits. So Emre spends a morning in customer service next to Gül and watches her handle two small institutional orders that came in for a summer school. He watches before he asks, then asks about what he saw.

What he sees: Gül has a personal Excel file on her desktop called "ISBN fixes", with old ISBNs of out-of-print books next to the ISBNs of their new editions. When a row turns out to be a book that is not in the catalog, she calls the school and suggests an alternative. She tracks partially shipped orders in a notebook. None of these three habits is written in any document; when asked, Gül says "that's just the nature of the job". That is exactly why they are requirement candidates: if the new system doesn't do these things, Gül will keep using her notebook and her personal spreadsheet.

Document analysis looks at the same question with data from the past. Selin goes through the emails and attachments of the 46 institutional orders that came in last September. The result: nine different file layouts; 31 files have ISBNs, 15 only titles; in 6 files the same book appears on separate rows per class section; in 12 emails the invoice details are in the email body, not in the file; 4 orders were followed by a correction list. The largest list has 870 rows. These numbers show where the "up to 1,000 rows" requirement from the previous post came from, and they move the discussion from opinions to data.

Workshop: Everyone in Front of the Same Wall

Interviews and observation bring pieces of information from different people; you only see that the pieces contradict each other when you put them side by side. So Selin runs a ninety-minute workshop: Hakan, Gül, the warehouse lead, someone from Bookstore accounting, Ms. Nevin joining online, Emre and Ayşe.

There is one item on the agenda: lay out a real order from last September on the wall with sticky notes, from preparing the list to paying the invoice. Each participant writes their own steps in their own color; then everyone puts a red dot next to the step where they had trouble.

The wall immediately makes two contradictions visible. The warehouse lead says the "one order, one shipment" rule is essential for his planning; Ms. Nevin wants separate deliveries to three campuses. Bookstore accounting says it can transfer only one invoice per order to the ERP; whether the foundation wants a separate invoice per campus is unclear. The workshop resolves neither contradiction, and it doesn't have to; but both are now open questions with an owner and a date.

Selin's most important job in the workshop is facilitation: keeping the loudest voice from taking over the discussion. Asking Gül and Ms. Nevin "is it like that for you too?" after each of Hakan's statements changes the value of the whole workshop.

Testing Assumptions Early with a Prototype

The interviews produced an assumption: purchasing officers will want to upload the list as a file. Instead of spending a sprint to find out, Ayşe builds a clickable skeleton in Angular in one day: no backend, hard-coded data; a paste area, a "check" button and a table showing the validation result. A sketch on paper could have done the same job; what matters is that nobody tries to turn this prototype into production code.

The prototype is tried with three purchasing officers, twenty minutes each. Each gets a single task: "Prepare last year's list for ordering." What is observed: two of them copy the ISBN and quantity columns from Excel and paste them without looking for a file. The third has no ISBNs in her list; the paste area doesn't help her, and a need for searching by title emerges. All three ask the same question: "Can I save this as a draft and send it to the principal for approval?"

That last question is a requirement that came up in none of the interviews: an approval step inside the school. That is exactly the value of a prototype; while clicking on something, people voice needs they never mentioned while talking about it. A warning: "it looks great" is not a prototype test result. The result is whether the user completed the task and where they got stuck.

From Notes to a Glossary and an Open Questions List

At the end of two weeks Selin has interview notes, a photo of the wall, document analysis numbers and prototype observations. These are not requirements yet; they need to become two concrete elicitation outputs: a glossary and an open questions list.

A glossary makes sure the team and the stakeholders use the same word with the same meaning. In the "Ubiquitous Language" post of the Domain-Driven Design series we saw how that language is protected in code; here we look at where the language is born. The first glossary entries of the Bookstore team: "Institution" (Institution in code) is a school or library that has an agreement with Bookstore; the foundation or municipality the invoice is addressed to is a separate concept called "Billing party" (BillingParty). A "Delivery point" (DeliveryPoint) is each address where an institution's books are delivered; a school can have more than one. A "Purchase order number" (PurchaseOrderNumber) is the number the institution's own accounting assigns, and it must appear on the invoice. An "Approval limit" (ApprovalLimit) is the amount above which the institution requires internal approval for an order.

If you notice while writing the glossary that a word has two meanings, that is not a mistake but a finding. "Bulk order" meant an institution's order to Hakan and a high-quantity shipment to the warehouse; the team picks "institutional order" in the glossary and decides to use "bulk" only in the context of quantity.

Each row on the open questions list has three parts: the question, who will answer it and by when. The first items on Bookstore's list:

• Does the "minimum 20 copies" rule apply to the order total or to each book? Corporate sales (Hakan), July 15.
• If stock is insufficient, does the institution accept a partial shipment or prefer to wait? Two schools and the library, July 18.
• Does the foundation want a separate invoice per campus? Foundation accounting, July 18.
• Is the internal school approval step needed in the first release, or is the order approved by email and entered afterwards? Ms. Nevin, July 20.

We will clarify some of the rule questions on this list with examples in the Example Mapping session of post 05. What is not on the list, yet is the most valuable output of elicitation, is the unspoken rules (tacit knowledge): budget approval being tied to August 15, invoices going to the foundation, teachers changing lists after school starts. Write these under a separate heading together with their source; because they are so "natural" that they go unnoticed on first reading, they are the information most easily lost.

In Production

Don't skip confirmation. After each interview, write a short summary and send it to the person you talked to: "Here is what we understood; is anything wrong or missing?" The reply to the summary sent to Ms. Nevin corrected a detail: campus delivery is needed only for textbooks; library books can go to the main campus. Unconfirmed notes turn into established facts as they circulate inside the team.

Keep the source of every piece of information. Next to the sentence "the invoice is issued to the foundation" there should be who said it and when. Six months from now, when the rule changes, that note tells you who to ask.

If you want to record an interview, ask for explicit permission first. A voice recording is personal data; ask your company's legal team or data protection officer what you need to do under KVKK or the law that applies to you, and don't keep recordings longer than needed.

Don't make promises in interviews. "We'll add that too" turns into a commitment in the stakeholder's mind; prioritization is the Product Owner's call, made in the backlog, not in the interview.

Common Pitfalls

The first pitfall is listening only to the loudest stakeholder. Hakan's experience is valuable, but Hakan describes his own work; he doesn't know about Gül's notebook, Ms. Nevin's budget date or the foundation's invoice. Ask the quiet people in the workshop directly; deliberately put people with little influence but a lot of knowledge on your interview list.

The second pitfall is talking to the manager instead of the user. The vice principal signs the order but does not prepare it; an interview with him describes the process as it should be, not as it is. Reaching the person who actually does the work may require asking the manager for permission; it is worth doing.

The third is asking leading questions. The only polite answer to "An Excel upload would make your job easier, right?" is "yes". Ask open questions and tie them to a past event.

The fourth is treating elicitation as a phase done once at the start of the project. The internal school approval step that came up in the prototype test was in none of the interviews held two weeks earlier. Every new story and every demo is a new elicitation opportunity.

The fifth is keeping developers out of elicitation. Emre's morning next to Gül uncovered the ISBN fixes list; read from a meeting summary, that information would probably have looked like an unimportant detail.

A Small Experiment

★☆☆ Build a stakeholder map for a feature you are working on. Add two separate notes to each row, "influence" and "knowledge", and find a person with a lot of knowledge you have not talked to yet.

★★☆ Do a fifteen-minute interview with a user and start with a single question: "When was the last time you did this? Can you walk me through it from the beginning?" Write down every exception you hear; then count how many of them appear in the current requirement text.

★★★ Take ten terms your team uses and write a glossary entry for each: the business term, its name in code, a one-sentence definition. Find at least one place where you use the same word with two different meanings and decide as a team which meaning goes with which word.

We came out of elicitation with a glossary, an open questions list and a pile of confirmed information. Now we need to turn them into pieces the development team can work on. In the next post we first write bulk ordering as a use case and then split it into user stories: we'll look at the card, conversation and confirmation trio, the INVEST check, and the situations where a use case is still the better tool.