Requirements Gathering Techniques

Interviews

18 min Lesson 2 of 10

Interviews

An interview is a structured conversation between an analyst and one or more stakeholders, held to discover requirements, understand workflows, surface constraints, and build trust. Done well, an interview uncovers information that no document or survey ever could — the nuance behind a process, the workaround a user built years ago, the fear a manager has about a new system. Done poorly, it wastes everyone's time and produces vague notes that cannot drive a design.

This lesson walks through every stage: planning who to talk to and what to ask, choosing the right question style, running the session with discipline, and turning rough notes into a structured record that feeds your requirements document.

Why Interviews Are the Analyst's Core Tool

Consider a clinic that wants to replace its paper-based appointment booking with a software system. The project manager says the goal is "faster booking." The receptionist says the real pain is that doctors change their availability at the last minute and there is no way to notify patients. The head nurse says the biggest risk is double-booking a consultation room. The IT lead says any system must integrate with the existing patient records database. None of these perspectives appear in any existing document. Only face-to-face conversation — guided by a prepared analyst — will surface them in time to influence the design.

Key idea: Interviews are the primary technique for understanding motivation and context, not just facts. They answer not only "what does the system do?" but "why does it need to do that?" and "what happens when it goes wrong?"

Stage 1 — Planning the Interview

Planning is where most failed interviews are lost. Arrive without a plan and you get a pleasant chat; arrive with one and you get requirements.

Identify who to interview. Map every stakeholder role that touches the system — end users, supervisors, data owners, IT staff, customers, regulators. For the clinic example: receptionists, doctors, nurses, the clinic director, the IT administrator, and a representative patient (if feasible). Prioritise by influence and knowledge.
Set clear objectives per session. Write one sentence per interview: "Understand the current patient check-in workflow and the pain points receptionists experience." A focused objective prevents drift.
Prepare an interview guide. This is a list of topics and questions — not a rigid script, but a scaffold. Group questions by theme (current state, pain points, desired future state, constraints, priorities).
Schedule appropriately. Aim for 45–60 minutes per session. Shorter and you rush; longer and energy drops. Book a quiet room. Send a brief agenda one day in advance so the interviewee can prepare.
Decide on recording / note-taking. Ask permission before recording. Many analysts use a second person as a dedicated note-taker so the interviewer can maintain eye contact and listen actively.

Stage 2 — Question Types: Open vs. Closed

The single most important technique in interviewing is question design. Questions fall on a spectrum from fully open to fully closed, and expert analysts mix both deliberately.

From exploratory open questions to closed confirming questions — a skilled analyst uses all four zones in a single interview.

Open questions invite narrative. They begin with "Tell me about…", "Describe how…", "Walk me through…", or "What happens when…". They surface unexpected information and reveal the stakeholder's mental model. Use them at the start of a session and whenever you enter a new topic area.

Closed questions confirm specific facts. "Does the system send a confirmation email?" or "How many appointments does the clinic handle per day on average?" are closed. Use them to pin down details you have already heard in broad strokes and to check your understanding at the end of each section.

Probing questions are follow-ups that dig deeper into an answer: "You mentioned that cancellations are a problem — can you give me a recent example?" Probing is the most powerful technique in the interview and requires you to listen actively rather than mechanically running through your list.

Tip — the 5 Whys in interviews: When a stakeholder describes a pain point, ask "why?" up to five times. "Bookings are slow" → "Why?" → "We have to check three different calendars" → "Why?" → "Each doctor maintains their own spreadsheet" → "Why?" → "The old system never had a shared calendar." You have now found the root requirement: a shared, real-time calendar.

Stage 3 — Conducting the Interview

A well-run interview has a clear structure: opening, main body, and close.

Opening (5 minutes). Introduce yourself, explain the project purpose and how the information will be used, confirm the time available, and ask permission to take notes. Put the interviewee at ease — they are the expert; you are the learner.
Main body (35–45 minutes). Follow your guide but treat it as a map, not a railway track. Listen for threads worth following. Paraphrase to confirm: "So if I understand correctly, the receptionist has to phone each patient individually when a slot opens — is that right?" Silence is a tool: a pause of two or three seconds after an answer often prompts the interviewee to add the most important detail.
Close (5–10 minutes). Summarise what you have heard, ask "Is there anything we have not covered that you think is important?", confirm any follow-up actions, and thank the participant. This final open question frequently uncovers a critical requirement that never appeared earlier in the session.

Pitfall — leading questions: "You would want the system to send automated reminders, right?" leads the witness. Prefer "How do you currently notify patients of changes, and what do you wish were different?" A leading question creates false requirements that stakeholders later deny requesting.

Stage 4 — Documenting the Interview

Notes taken during the interview are raw material, not a deliverable. Within 24 hours of the session, convert them into a structured Interview Record. A standard record contains:

Header: project name, date, location/medium, interviewer(s), interviewee name and role
Objectives: the one-sentence goal set during planning
Key findings: bulleted, thematic summary of what was learned
Candidate requirements: each requirement stated as a clear action ("The system shall…" or "Users must be able to…")
Open questions / follow-up actions: unresolved points that need a second session or a different stakeholder
Interviewee review: send the record to the interviewee for corrections within two business days

The five-step interview process, from planning through stakeholder validation of the written record.

Practical Guidance for Common Scenarios

The reluctant interviewee. Some stakeholders are busy, anxious about job security, or simply introverted. Start with an easy question about their role and daily routine. People relax when talking about what they know best. Reassure them that there are no wrong answers — you are documenting process, not evaluating performance.

The over-talkative interviewee. Use a polite redirect: "That is really useful context — I want to make sure I understand [specific topic] before we run out of time. Could you tell me more about…" Closed confirmatory questions also help bring a wandering session back on track.

Conflicting accounts. Different stakeholders will describe the same process differently. Do not try to resolve the conflict in the interview itself — document both accounts faithfully. The conflict itself is a finding: it reveals unclear ownership, inconsistent practice, or a gap in current documentation.

Tip — interview in pairs: In a professional engagement, two analysts often attend each interview: one leads and asks questions, the other takes detailed notes and watches for non-verbal cues. Afterwards they compare observations to catch things a sole interviewer would miss while talking.

Strengths and Limitations

Interviews are powerful but not universal. They are time-consuming to arrange and conduct: interviewing six stakeholders at an online store (product manager, warehouse supervisor, customer service lead, logistics coordinator, CTO, a regular customer) with 45-minute sessions plus 30 minutes of prep and 60 minutes of documentation each consumes roughly 14–15 analyst-hours before a single requirement is formally written. They also carry interviewer bias risk — the analyst's assumptions can subtly shape what questions get asked and how answers are interpreted.

For these reasons, interviews are almost always combined with other techniques: questionnaires for large user populations, document analysis to understand the current system, and workshops to resolve conflicting requirements identified across separate interviews.