Requirements Elicitation & Gathering

Requirements elicitation is the most critical skill a Business Analyst possesses. It is the process of discovering, extracting, and defining what a solution must do — not what you think it should do, but what stakeholders actually need. Bad elicitation produces bad requirements, which produce failed projects.

This topic teaches you every major elicitation technique: structured and unstructured interviews, facilitated workshops, surveys and questionnaires, direct observation, document analysis, and brainstorming sessions. You will also learn how to classify requirements (functional vs non-functional vs business vs transition) and how to write requirements that follow the SMART framework — Specific, Measurable, Achievable, Relevant, and Time-bound. This is where you go from "knowing what BA is" to "actually doing BA work."

Complete Business Analysis Fundamentals before starting this topic.

The single biggest cause of project failure is not technical complexity — it is requirements that are wrong, vague, or incomplete. A 2020 PMI study found that 39% of project failures were caused by inaccurate requirements. Elicitation is the process that prevents this.

The term "elicitation" is deliberate — it means to draw out, not to ask for. Stakeholders often cannot articulate what they need because they have never been asked the right questions. Your job as a BA is to ask those questions, listen actively, and synthesize what you hear into clear, testable requirements.

Think of elicitation as detective work: you are gathering evidence from multiple sources, each giving a partial picture, and assembling the complete puzzle.

Interviews are the most common elicitation technique. They range from informal conversations to structured, documented sessions.

Structured interviews follow a prepared set of questions in a fixed order. Best for: comparing responses across stakeholders, ensuring consistency, and when you have limited time.

Semi-structured interviews have a loose guide of topics but allow the conversation to flow naturally. Best for: deep exploration, discovery, and when you are not sure what questions to ask yet.

Unstructured interviews are open conversations. Best for: initial discovery when you know very little about the problem.

Key question types:

• Open-ended: "Tell me about how you process invoices today" — encourages detailed responses
• Closed: "Do you use a system to track approvals? Yes/No" — confirms specific facts
• Probing: "Can you walk me through what happens after you submit the form?" — digs deeper into an answer
• Clarifying: "When you say ‘fast,’ what turnaround time are you expecting?" — removes ambiguity
• Hypothetical: "If you could change one thing about this process, what would it be?" — uncovers hidden needs

Workshops bring multiple stakeholders together to define, refine, and prioritize requirements in real time. They are faster than individual interviews and immediately surface conflicts.

JAD Sessions (Joint Application Development) are structured, facilitated workshops where business users, analysts, developers, and sponsors collaborate to define requirements. They are typically full-day or multi-day events.

Focus Groups are smaller, informal discussions with a specific user group to understand their perspective on a proposed solution.

Brainstorming Sessions generate a large volume of ideas quickly using techniques like mind mapping or sticky-note sessions (affinity diagramming).

Facilitation tips:

• Prepare an agenda and share it at least 24 hours in advance
• Define ground rules (one conversation at a time, no interrupting, every idea is valid initially)
• Use a timebox for each topic — keeps the group focused
• Document decisions and action items in real time (use a shared screen or whiteboard)
• Follow up with a summary email within 24 hours

Surveys are efficient for gathering input from a large number of stakeholders who cannot attend a workshop. They are especially useful when you need to validate a hypothesis across a large population.

When to use surveys:

• Stakeholders are geographically distributed
• You need quantitative data to validate qualitative findings
• You need input from a large group (100+ people) quickly
• The topic is sensitive and people may be more honest anonymously

Survey design best practices:

• Keep it short — 10-15 questions maximum
• Mix question types: Likert scale (1-5), multiple choice, ranking, and one or two open-ended
• Avoid leading questions ("Don’t you agree that...")
• Pilot the survey with 2-3 people before sending it to everyone
• Offer a brief explanation of why their input matters

Observation means watching stakeholders do their actual work. It is the most reliable way to discover unstated requirements — the things people do every day but never think to mention in an interview.

For example: a stakeholder says "I enter the data and submit the form." When you observe, you discover they also check three spreadsheets, copy data manually, and call the finance department for one field. None of this was mentioned in the interview.

Types of observation:

• Passive observation: you watch silently, taking notes without interrupting
• Active observation: you ask clarifying questions during the observation
• Workshop observation: you observe a team performing a collaborative process

Always ask permission and explain that you are observing the process, not evaluating the person.

Before interviewing anyone, review every existing document related to the problem. Document analysis extracts requirements from:

• Existing system documentation — user manuals, help guides, API docs
• Business process documents — SOPs, policy manuals, workflow diagrams
• Regulatory and compliance documents — legal requirements, industry standards
• Previous project artifacts — old requirements documents, change requests, lessons learned
• Data artifacts — spreadsheets, reports, database schemas
• Contracts and SLAs — service level commitments, vendor agreements

Document analysis saves time by establishing a baseline before you talk to people. You can then use interviews to validate and fill gaps rather than starting from scratch.

Requirements come in different flavors. Understanding the types helps you categorize and manage them properly:

The traceability between these types matters: a functional requirement must trace to a business requirement, and a business requirement must trace to a measurable outcome.

A requirement is only useful if it is clear, testable, and unambiguous. The SMART framework helps:

• S — Specific: No ambiguity. "The system shall" not "the system should maybe"
• M — Measurable: You can verify it. "Response time under 2 seconds" not "fast"
• A — Achievable: Technically feasible within constraints
• R — Relevant: Tied to a business need, not a nice-to-have
• T — Time-bound: Has a clear acceptance criteria or deadline

Bad requirement: "The system should be user-friendly."

SMART requirement: "A new user shall complete the invoice submission workflow within 3 clicks and without training, as verified by usability testing with 10 users achieving ≥90% first-time success rate."

Use requirement IDs (e.g. FR-001, NFR-001) for traceability and reference in reviews.

Complete these exercises to practice every elicitation technique:

1. Interview a colleague or family member about a process they follow daily (e.g., cooking a meal, paying bills). Record at least 10 questions across the five question types.
2. Design a 12-question survey to gather requirements for a hypothetical mobile banking app. Include at least 2 Likert-scale, 3 multiple-choice, 2 ranking, and 2 open-ended questions.
3. Write three versions of the same requirement: one vague, one better, one SMART.
4. Observe someone doing a simple task (e.g., filing documents or making coffee) and document three unstated requirements they never mentioned verbally.
5. Find a public process (e.g., returning an item on Amazon) and perform a document analysis by reading the help pages — extract at least 5 functional requirements.

In a real job, elicitation is where you spend the most time in the early phases. You join a project, the manager gives you a vague brief, and your first two weeks are spent interviewing 8-12 stakeholders, attending existing process walkthroughs, and reading every document you can find. You will discover that three stakeholders have three different definitions of "the problem." Your job is to reconcile these into a single, coherent requirements document that everyone signs off on. The techniques in this topic — especially probing questions, observation, and SMART requirements — are what separate a junior BA who just transcribes what people say from a senior BA who uncovers what people actually need.

Business problem: A restaurant chain wants to launch an online ordering system. They currently handle phone orders and walk-ins.

Objective: Practice elicitation end-to-end: plan your approach, conduct interviews, write SMART requirements, and classify them.