Before you can design an interface, you need to know what people actually need it to do. Requirements gathering (also called requirements elicitation) is the systematic process of drawing out those needs from stakeholders and users: what goals they are trying to accomplish, under what conditions, with what constraints, and what would count as success. The techniques in this topic — interviews, contextual inquiry, workshops and focus groups, surveys and questionnaires, and analysis of documents and existing systems — are the standard toolkit, and each one answers a different kind of question.
In this course the payoff is immediate: the raw material you collect here becomes the actors, goals, preconditions, and step-by-step flows of the use case scenarios you write later in the module. Vague or assumed requirements produce vague use cases and, eventually, interfaces that solve the wrong problem. Gathering well also helps you sort what you learn into functional requirements (what the system must do) and non-functional ones (speed, accessibility, learnability, reliability).
As you watch, pay attention to three things. First, matching method to question — when is observing a user at work better than asking them, and when is a survey the right scale of tool? Second, the mechanics of good questioning — how practitioners avoid leading, biasing, or interrupting participants. Third, what the output looks like: try to imagine, for each technique, the kind of notes or data you would walk away with and how you would turn those notes into a use case step.
Laura Brandenburg of Bridging the Gap walks through five commonly used requirements elicitation techniques from a business analyst's perspective. Expect a comparative overview — what each technique is, the situations it suits, and how analysts use it to surface requirements rather than just opinions. This is the broad map of the territory covered by this topic's subtopics.
It serves as the orientation video, giving you a single framework for comparing interviews, workshops, surveys, observation, and document review before you study any one of them in depth.
A short explainer from Nielsen Norman Group defining contextual inquiry as a user research method. It covers what makes the method distinctive — researching users in their own environment while they do real work — and why that is useful for defining requirements, understanding existing processes, and learning what actually matters to users.
NNgroup is a long-established authority in user research, and this video directly addresses the Interviews and Contextual Inquiry subtopic, clarifying how observation in context differs from simply asking users questions.
A fast, practical video naming five common mistakes people make when conducting user interviews. It focuses on interviewing technique — the kinds of questions, prompts, and researcher behaviors that distort what participants tell you — rather than on logistics.
Interviews are the technique you are most likely to use for your own use case work, and this video gives concrete, correctable errors to watch for, which improves the quality of the requirements you collect.
Together these videos move from breadth to practice. The Bridging the Gap overview supports MO2 by surveying the range of elicitation techniques — interviews, surveys, observation, and more — so you can choose a method deliberately rather than by default. The two NNgroup videos deepen the two techniques most central to this module: contextual inquiry gives you the situated, in-context detail about user goals and interaction environments that MO1 requires for realistic use case scenarios, while the interview-mistakes video helps ensure the data you collect is accurate rather than an artifact of leading questions. Clean, well-sourced data is also a precondition for MO3, since you cannot reliably separate functional from non-functional requirements if what you captured was vague or biased.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.