Requirements Excellence: The Craft at the Heart of Business Analysis

DAY 2 | Elicitation Mastery: Getting to the Real Requirement

There is a concept in cognitive psychology called tacit knowledge. It refers to knowledge that a person holds and uses effectively but cannot easily articulate when asked. The experienced nurse who knows a patient is deteriorating before the numbers show it. The master craftsperson who adjusts their technique in response to feedback they cannot describe. The subject matter expert who has been processing insurance claims for twenty years and knows instantly when something does not look right, but struggles to explain the rule they are applying. Tacit knowledge is everywhere in organisations, and it is one of the primary reasons elicitation is harder than it looks.

When you sit down with a subject matter expert and ask them what the system needs to do, you are asking them to externalise knowledge that they may have never needed to put into words before. They know their process the way you know how to walk. They do not think about it step by step. They just do it. And when you ask them to describe it, they give you the version they are aware of, which is almost always incomplete. Requirements elicitation is the craft of helping people articulate what they know but cannot easily say. And it requires considerably more than asking questions in a workshop and writing down the answers.

What Elicitation Actually Is

Most BA training programmes describe elicitation as the process of gathering requirements from stakeholders. That description is accurate in the way that describing surgery as cutting people is accurate. Technically true. Completely insufficient. Elicitation is the structured, deliberate process of uncovering the real needs that underlie stakeholder requests, surfacing the assumptions that stakeholders have not examined, and translating the operational reality of a business process into precise requirements that a solution can be designed to meet.

The word the BABOK Guide uses is eliciting; drawing out rather than gathering, which implies collection of something that already exists in ready-made form. Requirements do not exist in ready-made form. They are constructed through dialogue, observation, analysis and challenge. The elicitation process is where they are built.

The Six Elicitation Techniques Every BA Must Command

Technique 1: Structured Interviews

The one-to-one structured interview is the most powerful elicitation technique available to a Business Analyst and the one most consistently underused. Most BAs reach for the workshop when a well-prepared individual interview would produce better information in less time. The structured interview works because it removes the social dynamics of a group setting. In a workshop, stakeholders are aware of each other. They moderate what they say based on who is in the room. The junior team member will not contradict the senior manager. The person whose job is most at risk from the change will not articulate their real concerns openly. The subject matter expert who has strong views will soften them in front of their peers.

In a one-to-one, those dynamics are largely absent. People tell you things in private that they would never say in a group. And the questions you can ask in a one-to-one - questions that probe an individual's specific experience, surface specific concerns, or challenge specific assumptions- are not possible in a group format without creating awkwardness.

Preparation is what separates a structured interview from a conversation. Before every one-to-one, you should know exactly what you need to learn from this specific person, what their relationship to the change is, what concerns they are likely to have, and what questions will draw out the information you need. Go in with a question guide, not a script. The guide keeps you on track. The conversation takes you where it needs to go.

Technique 2: Facilitated Workshops

Workshops work for requirements that need to be built through group consensus, when different stakeholder groups have potentially conflicting requirements that need to be surfaced and resolved, when you need to achieve sign-off from multiple parties simultaneously, or when the requirement is genuinely uncertain and benefits from group exploration. The BA's role in a workshop is not to take notes. It is to facilitate: to create the conditions in which the real requirements can emerge. This means managing dominant voices without marginalising them, drawing out quieter participants, keeping the conversation at the right level of detail, parking discussions that are important but not relevant to the current objective, and synthesising what is said into draft requirements in real time so the group can validate them immediately.

A workshop that produces a list of stakeholder statements is not a successful elicitation workshop. A workshop that produces draft requirements that the group has collectively validated is.

Technique 3: Observation

Observation is watching how people actually do their work rather than asking them to describe it. This is the most underused elicitation technique in BA practice and often the most revealing. The gap between how people describe their process and how they actually perform it is consistently significant. Ask someone to walk you through their end-of-month reconciliation process, and they will give you the official version: the steps they are supposed to follow, in the order they are supposed to follow them. Watch them actually do the reconciliation and you will see the workarounds, the undocumented checks, the exception handling that has evolved over years of practice and exists nowhere in any process documentation. Those workarounds are requirements. The undocumented checks are requirements. The exception handling that the new system must replicate because operations depend on it; that is a requirement. And you would never have found it by asking.

Technique 4: Document Analysis

Existing documents - current system documentation, process manuals, reports, spreadsheets, previous project requirements, and regulatory guidance are a rich source of requirements that do not require stakeholder time to extract. Document analysis is particularly valuable for identifying non-functional requirements that stakeholders rarely volunteer spontaneously, understanding the current state in enough detail to design a credible future state, and surfacing legacy requirements that an organisation has accumulated over time and may not consciously remember having.

It is also the fastest way to identify contradictions between what stakeholders say their process is and what it actually is. When a stakeholder describes a process that is inconsistent with the policy document governing it, that inconsistency is a requirement for resolution. You need to know which version reflects the real business need before you can write the requirement for the new system.

Technique 5: Prototyping

Prototyping is showing stakeholders a working or visual model of a proposed solution rather than asking them to respond to written specifications, and it's one of the most effective techniques for surfacing requirements that stakeholders cannot articulate in the abstract.

The reason is simple. People find it much easier to respond to something concrete than to imagine something abstract. Ask a stakeholder to describe what they need a dashboard to show, and you will get a vague answer. Show them a prototype dashboard, and they will immediately tell you what is wrong, what is missing, what is in the wrong place, and what they would actually use. The prototype has externalised what was previously tacit.

Prototypes do not need to be high-fidelity to be useful. A hand-drawn wireframe, a PowerPoint mock-up, or a basic clickable prototype built in a free tool is enough to generate specific, actionable requirements feedback. The goal is not to design the solution. It is to use a visual prompt to unlock requirements that the elicitation process has not yet reached.

Technique 6: Requirements Workshops With Structured Analysis

Beyond the standard facilitated workshop, structured analysis techniques, use case development, user story mapping, process decomposition, and event-response analysis give the elicitation process a framework that helps both the BA and the stakeholders think more completely about what the system needs to do.

Walking through a use case together - who is the actor, what triggers the interaction, what does the system do, what does the user do, what are the alternative paths, what happens when something goes wrong - generates requirements that a simple question-and-answer format rarely reaches. The structure of the technique itself is what does the work: it forces completeness by asking the same questions about every scenario.

The Questions That Find What Stakeholders Cannot Articulate

Beyond the choice of technique, there is a category of question that experienced BAs use in elicitation that consistently surfaces what other questions miss. These are not standard requirements questions. They are probing questions designed to disrupt the assumptions that produce incomplete requirements.

• "What happens when it goes wrong?" Most requirements describe the happy path, the normal flow where everything works as expected. The exception handling - the error states, the recovery procedures, the edge cases where the data is unusual, or the timing is unexpected - these are where the most important requirements hide, because they are the cases that users deal with daily and that systems fail at consistently. Ask specifically about failure modes, error cases, and exception handling for every process you elicit.

• "What do you do today that the new system needs to do?" This question surfaces legacy requirements; workarounds, manual adjustments, and compensating processes that have developed over time and are now essential to operations. If the answer is "we have a spreadsheet that does that" or "Sarah handles those cases manually," you have just found a requirement that nobody was planning to include.

• "What would make this wrong?" After a stakeholder describes what they need, ask them what the system would have to do for them to consider it a failure. This question surfaces implicit success criteria, the standards a stakeholder is applying that they have never made explicit. The answer often contains the most important acceptance criteria for the requirement.

• "Who else is affected by this?" Requirements elicitation can become siloed around the most vocal or most accessible stakeholders. Asking systematically who else is affected by each requirement draws out the perspectives of the people whose needs are most often missed: the downstream teams who receive the output, the support teams who handle the exceptions, the users whose edge cases are not representative of the main user group.

The Four Elicitation Mistakes That Produce Shallow Requirements

• Accepting the first answer: The first answer a stakeholder gives you is rarely the complete answer. It is their immediate, unconsidered response. The real requirement often lives two or three questions deeper. Get into the habit of treating every stakeholder statement as the beginning of an investigation rather than the conclusion of one.

• Eliciting from the most accessible stakeholders rather than the right ones: The people who are easiest to book time with are not always the people whose requirements matter most. Identify the stakeholders whose input is critical to each requirement and pursue their availability, even when it is inconvenient. A requirement elicited without the input of the right stakeholder is a guess with a professional wrapper.

• Treating elicitation as a phase rather than a practice: Requirements elicitation is not something you do in weeks two and three of a project and then consider complete. New requirements emerge throughout delivery as stakeholders see working software and understand the change more concretely. The BA who treats elicitation as a closed phase will consistently miss the requirements that only become visible later.

• Failing to validate in real time: During an elicitation session, paraphrasing and confirming what you have heard is not a social nicety. It is the quality control step. "So what I am hearing is that the system needs to do X in condition Y. Is that right?" This immediate validation surfaces misunderstandings while the stakeholder is still in the room and can correct them, rather than six weeks later in a review cycle.

• 
  

Go out and be successful.

Oluwatosin Ogunkoya | Flotog BA Insights | www.flotogbainsights.com

Tomorrow: Writing Requirements That Hold Up. Functional and non-functional requirements in depth, the quality criteria every requirement must meet, and the documentation failures that send projects in the wrong direction.