A use case scenario is a structured description of how a particular user (an actor) interacts with a system to accomplish a specific goal. Instead of listing features in the abstract, a use case walks through the sequence of steps the user takes, what the system does in response, what must be true before the interaction starts, and what counts as success. In human-computer interaction work, this makes use cases a bridge between the people you are designing for and the interface you will eventually build.
In this course, use cases matter because they are where user research turns into something designers and developers can act on. Before you sketch a screen or run a usability test, you need a clear statement of who the user is, what they are trying to do, and under what conditions. Use cases also feed directly into requirements gathering: each step and alternate flow in a scenario tends to reveal a functional requirement, and the conditions around it often reveal non-functional ones such as speed, accessibility, or error tolerance.
As you watch the videos below, pay attention to four things: the vocabulary (actor, goal, precondition, postcondition, main flow, alternate and exception flows), how a written use case description differs from a use case diagram, how use cases connect to requirements documentation, and how use cases compare with user stories in agile practice. Try to notice that these are complementary tools rather than competitors — a short user story captures intent, while a full use case captures detail.
This Geekific video, framed around object-oriented design, explains what use cases and user stories each are and then compares them side by side. Based on its title and description, it should cover the purpose and structure of a use case, the typical format of a user story, and when each is the more appropriate tool. Expect concise definitions with examples rather than a long walkthrough of a single project.
It maps directly onto the "Use Cases vs. User Stories" subtopic, which students often find confusing, and Geekific is a well-regarded channel for compact software design explanations that keep the terminology precise.
This tutorial from The Business Analysis Doctor walks through an actual use case description (also called a use case specification), showing how the document is structured and filled in. The description indicates it treats the use case as a way to verify that functional requirements cover the needed behavior, so expect discussion of actors, preconditions, main and alternate flows, and best practices for writing them clearly.
At eighteen minutes it is the most detailed look at the "Key Components of a Use Case" and "Role of Use Cases in Requirements Gathering" subtopics, and the producer is a practicing business analyst channel aligned with IIBA professional standards, so the conventions shown reflect real industry documentation.
Lucid Software's tutorial introduces UML use case diagrams from the ground up, covering the notation for actors, use cases, system boundaries, and relationships such as include and extend. It is pitched at both beginners and intermediate learners, so it should move from basic symbols to how diagrams are assembled for a full system.
It supplies the visual, system-level counterpart to the written scenario, helping students see how individual use cases fit together in scope; Lucid is the maker of a widely used diagramming tool and the video's very large view count reflects its clarity as a standard reference.
Together these videos build the foundation MO1 requires: the Geekific and Business Analysis Doctor videos supply the vocabulary and structure students need to compose use case scenarios that state a real user goal and its interaction context, while the Lucid tutorial gives them a way to show how those scenarios relate across a system. The use case description tutorial also supports MO3, since walking through main flows, alternate flows, preconditions, and postconditions is exactly where functional behaviors and surrounding quality constraints become visible and can be sorted into functional versus non-functional specifications. MO2 is addressed indirectly here — these videos show what the output of requirements gathering looks like, which gives purpose to the interview, survey, and observation techniques covered elsewhere in the module.
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.
Every interface is built for someone, and almost every interface is also paid for, approved, maintained, or regulated by someone else. Before you can write a believable use case scenario, you have to know who those people are. This topic introduces stakeholder analysis: the practice of systematically listing everyone who has an interest in a system, classifying them, and deciding whose input shapes which design decisions.
A key distinction in this module is between users and stakeholders. Users are the people who directly operate the interface to accomplish a task; stakeholders are the broader set of parties affected by or invested in the system, including managers, clients, support staff, compliance officers, and sometimes people who never touch the software at all. Users are a subset of stakeholders, but their goals are not identical to stakeholder needs — a manager may need audit trails and cost control while the frontline user needs speed and fewer clicks. You will also look at how user roles and permissions subdivide the user population, since an administrator and a guest may use the same system in very different ways.
As you watch the videos below, keep a running list of two things: the techniques each speaker uses to surface stakeholders who might otherwise be forgotten, and the kinds of questions used to pull needs and goals out of those people. Notice that the videos come from different traditions — UX research, project management, and software engineering — and that each tradition frames stakeholders slightly differently. That contrast is useful: it shows you that stakeholder identification is a transferable skill with vocabulary that shifts depending on who is doing it.
Revisit this video a second time with a different lens: listen specifically for how stakeholder statements are turned into usable inputs for design rather than treated as instructions to follow.
A second pass helps you separate stakeholder needs from user goals, which is the distinction most often confused when students begin writing scenarios.
A project-management-oriented walkthrough of how to identify the stakeholders on a project. The video is aimed at practitioners who need a practical, repeatable method for listing and sorting the people with an interest in a project's outcome.
It gives you a concrete, step-by-step identification technique from the project management perspective, which complements the UX view and supports the "Techniques for Stakeholder Identification" subtopic.
A lecture-style software engineering video that defines stakeholders, presents the common types or categories of stakeholders, and discusses why they matter to a software project. It also addresses how to go about identifying them during the requirements phase.
The explicit focus on stakeholder types maps closely to the subtopics on defining stakeholders and distinguishing users from other interested parties, and it frames the material in the software engineering vocabulary used in this course.
Together these videos prepare you for the module outcomes by establishing who the scenarios are about before you write them. Identifying and classifying stakeholders and user roles gives you the cast of actors and the goals needed to compose accurate use case scenarios (MO1). The NN/g interview video and the identification techniques in the project management and software engineering videos introduce the interview-based side of requirements gathering that you will extend with surveys and observation (MO2). Finally, recognizing that different stakeholders care about different things — speed and ease of use for end users, security, compliance, and cost for others — sets up the later work of sorting collected requirements into functional and non-functional interface specifications (MO3).
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.
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.
Task analysis is the systematic study of what users actually do to accomplish a goal. Instead of guessing at features, you observe or interview people, then break their work into a structured set of steps, decisions, and sub-goals. The result is a task model: a description of the user's goal, the sequence of actions needed to reach it, the information required at each step, and the conditions under which the sequence changes.
In this module, task analysis is the bridge between raw requirements-gathering data and the use case scenarios you will write. Hierarchical Task Analysis (HTA) decomposes a goal into numbered sub-tasks and plans, giving you a tree you can read almost directly into main flows and alternate flows. Cognitive task analysis goes after the invisible part — what the user must know, remember, notice, or decide — which is where most interface difficulty actually lives. Once you have a model, you validate it by walking users back through it and correcting the steps you got wrong.
The three videos below approach the topic from different directions: one on task analysis as a decomposition and teaching technique, one on cognitive walkthrough as a way to evaluate a task step-by-step from the user's mental perspective, and one on hierarchical breakdown structures from project management. While watching, focus on the mechanics: how a goal is split, how deep the decomposition goes, how steps are numbered and ordered, and how you would know whether the resulting model is correct. Note also where each technique stops — none of these videos is a complete HCI task-analysis method on its own, so read them as complementary pieces.
This video, from the Center for Community Engagement, introduces task analysis as a method for breaking a task into its component steps so that a person can be supported in performing it independently. It is framed around executive functioning and student independence rather than software design, so expect examples drawn from everyday and instructional tasks. Likely coverage includes how to identify the goal, how to list and sequence the steps, and how to judge the right level of detail.
It gives a clear, slow-paced explanation of the core decomposition skill at the heart of this topic — identifying a goal and listing its steps — which transfers directly to interface tasks even though the examples are not from computing.
The Nielsen Norman Group explains the cognitive walkthrough, a task-based inspection technique in which evaluators step through a task as a first-time user would and ask, at each step, whether the user would know what to do and whether they would recognize that their action moved them toward the goal. The video covers what the method evaluates (learnability), how the task steps are defined in advance, and how findings are recorded.
NNgroup is a widely cited authority in usability, and this video connects directly to the cognitive side of task analysis and to validating a task model by walking it step by step from the user's point of view.
This short video contrasts the Work Breakdown Structure with product, resource, and organizational breakdown structures, explaining what each one decomposes and how the hierarchies are built and numbered. It comes from project management practice rather than HCI, but the underlying logic of parent nodes, child nodes, and levels of decomposition is the same structure used in Hierarchical Task Analysis.
It is a compact, concrete model of hierarchical decomposition and numbering conventions, which helps you see how an HTA diagram is constructed and why keeping different kinds of breakdowns (tasks versus deliverables versus roles) separate matters when you write use cases.
Together these videos support the module outcomes by supplying the analysis step that sits between data collection and specification. The task analysis video and the breakdown structure video give you techniques for decomposing user goals into ordered, numbered steps, which is the raw material for composing accurate use case scenarios with main and alternate flows (MO1). The cognitive walkthrough video shows how to use structured observation and step-by-step questioning to surface what users need to know and do, reinforcing observation as a requirements-gathering technique and offering a way to validate task models with real users (MO2). Finally, the habit of separating what a step does from what it requires and how well it must perform helps you sort the findings into functional and non-functional interface requirements (MO3).
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.
A use case scenario is a written description of how a user (the actor) interacts with a system to accomplish a goal. Rather than describing screens or code, it records the sequence of steps that move a user from an intention to a result, along with the conditions that must hold before the interaction starts and the state the system is left in afterward. In this module you will learn the structure of a use case document: identifying the actor and goal, specifying preconditions and postconditions, writing the main success scenario, and then documenting alternative flows (other valid ways to reach the goal) and exception flows (what happens when something goes wrong).
This matters in an HCI course because use cases are the bridge between the users you study and the interface you design. They force you to commit to a concrete interaction context, expose decisions and error states that are easy to overlook, and give you a vocabulary that designers, developers, and stakeholders can all check against. A well-written use case is also a source of testable requirements, which is why it connects directly to the requirements work in the rest of this module.
As you watch the videos below, pay attention to three things: the template or section headings used, how each step is phrased (short, numbered, one actor action or one system response per step, no ambiguous words like "etc." or "appropriately"), and where the author branches out of the main flow into an alternative or exception. Try pausing and predicting the next step before it is shown, then compare your phrasing to the example on screen.
This tutorial walks through a complete use case description (also called a use case specification), showing the fields of a typical template and filling them in with a worked example. Based on its description, it covers how the specification verifies that functional requirements are fully covered, and it is likely to demonstrate the main flow along with supporting sections such as actors, preconditions, and alternate or exception handling. It also frames best practices for writing the steps themselves.
It is the closest match to this topic: a full, example-driven walkthrough of a use case document, produced by a business analysis channel oriented toward IIBA certification standards, which makes the terminology consistent with professional practice.
This video explains the use case diagram, showing how actors and key system actions are drawn and related to one another, and walks through constructing an example diagram step by step. It focuses on the visual model that sits alongside the written specification, including how to identify actors and name use cases at the right level of detail.
Diagrams are how most teams scope and name the use cases before writing them up, so this gives you the framing step that precedes a use case document and helps you pick goal-level names for your own scenarios.
This overview surveys five common types of requirements documentation used by business analysts, with use case documentation among them, alongside business process documentation, data documentation, and others. It is likely to compare what each document type is good for and when an analyst would choose one over another.
It situates use case writing within the larger documentation toolkit, which helps you understand what a use case should and should not try to capture and how it relates to the other requirements artifacts in this module.
Together these videos move from scoping to drafting to context. The use case diagram tutorial helps you identify actors and goals so that your scenarios represent real user intentions and interaction contexts, and the detailed use case description walkthrough models the document structure, main success scenario, preconditions, and branching flows you will produce yourself, supporting MO1. The documentation overview connects use cases to the broader set of artifacts produced from interviews, observation, and other elicitation work (MO2) and shows how written requirements get organized and separated by type, which prepares you to sort your own findings into functional and non-functional interface specifications (MO3).
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.
When we design an interface, it is tempting to describe only the "happy path" — the sequence of steps a cooperative user takes when everything works. Real systems are messier. Users lose network connection halfway through a form, enter names with apostrophes or characters your field rejects, switch languages, use a screen reader, hold the phone in one hand on a moving bus, or abandon a task and return three days later. Enumerating usage paths means systematically walking through a feature and listing every branch it can take, including the rare, boundary, and failure branches that we call edge cases.
This topic builds directly on the use case scenarios you have been writing. A use case set is only as good as its coverage: if an important path is never written down, it will never be designed for, never be tested, and will surface as a defect or a frustrated user. You will practice techniques for generating paths (varying inputs, states, sequences, interruptions, and contexts), for considering user diversity (ability, expertise, language, device, environment), for recording how often each path occurs and how much it matters, and for reviewing a set to judge whether it is reasonably complete.
The videos below approach this from three angles. As you watch, look for: how designers discover paths they did not anticipate (by talking to and observing real users), how a use case diagram makes alternate and exceptional flows visible as explicit structure, and how the needs you uncover get sorted into functional versus non-functional requirements — because many edge cases (performance under poor connectivity, accessibility, error recovery) land on the non-functional side of that line.
A short lesson from Google's UX Design Certificate on why edge cases deserve attention, built around the idea that what you expect users to do with an app is often not what they actually do. It frames edge cases as situations outside the anticipated flow and points to meeting with and observing real users as the way to surface them. Expect concrete framing and examples rather than a formal process.
It is the most direct match for the "What Are Edge Cases?" subtopic, and it comes from a widely used professional UX curriculum, so the vocabulary matches what you will encounter in industry.
A compact lecture distinguishing functional requirements (what the system must do) from non-functional requirements (qualities such as performance, reliability, usability, and security), with examples of each. It is presented in a classroom style aimed at exam and interview preparation, so definitions are stated crisply and contrasted side by side.
Edge cases frequently turn into non-functional requirements, so this video gives you the classification vocabulary needed to document what you find rather than letting it disappear into informal notes.
A thorough tutorial on UML use case diagrams covering actors, use cases, system boundaries, and the relationships between them, including how to represent extensions and included behavior. Lucid Software's walkthrough is aimed at both beginners and intermediate modelers and demonstrates building a diagram step by step.
Use case diagrams give you a visual structure for enumerating paths and attaching alternate and exceptional flows to a base case, which supports both the enumeration techniques and the completeness-review subtopics.
Together these videos extend your ability to compose complete, context-aware use case scenarios (MO1) by pushing past the happy path into alternate and exceptional flows, and by giving you a diagramming notation for organizing those flows. The Google UX video reinforces the observation and user-interview techniques from MO2 as the practical means of discovering paths you would not have imagined at your desk. The functional versus non-functional lecture supplies the classification scheme from MO3, so that the edge cases and context variations you uncover can be written down as properly categorized interface requirements rather than loose observations.
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.
A use case that lives only in the author's head, or in a file nobody can find, has no value to a project. Once you have written scenarios and gathered requirements, the work shifts to documentation and communication: where use cases are stored, how they are named and versioned, how each one connects back to the requirements it satisfies, and how you keep all of it current as the product changes. This topic treats use cases and requirements as shared project artifacts rather than one-time deliverables.
Three practices hold this together. Organization means a repository with consistent structure, identifiers, and status so team members can locate and reuse what exists. Traceability means every requirement can be followed forward to the use cases, design elements, and test cases that realize it, and backward to the stakeholder need that justified it. Communication means presenting use cases in a form that clients, developers, and testers can each act on, and keeping stakeholders involved when things change.
As you watch, look for three things: how a formal specification document is structured and what sections it contains; how traceability links are created, visualized, and checked for gaps; and what concrete behaviors make stakeholder collaboration work rather than fail. Note also how design and test activities draw directly on these documents, since that downstream use is the main reason to invest in clean documentation.
A lecture-style walkthrough of the Software Requirements Specification document, the standard artifact used to record and communicate requirements on a software project. Based on its title and channel, expect coverage of what an SRS is for, the sections it typically contains, and the qualities a good specification should have, such as being complete, consistent, and unambiguous. It is presented in the exam-preparation style typical of Gate Smashers lectures.
It gives you a concrete template for how requirements are formally documented and organized, which is the foundation for a use case repository and for traceability links back to numbered requirements.
A short practitioner video from Nielsen Norman Group presenting an eight-step process for UX designers and researchers to collaborate more effectively with stakeholders. The description indicates it focuses on specific behaviors that increase collaboration and buy-in rather than on documentation formats. Expect practical guidance on involving stakeholders throughout a project rather than only at review points.
It directly addresses the communicating use cases to stakeholders subtopic from a trusted UX research organization, and its advice applies equally to keeping stakeholders engaged when requirements change.
A technical demonstration from MathWorks showing three approaches to analyzing requirements traceability in MATLAB, described as tracking the connections between requirements and other project artifacts. Expect to see how links between requirements, design, and tests are represented and how gaps or missing coverage can be identified. The examples are tool-specific but the underlying concepts are general.
It makes the abstract idea of traceability visible and concrete, and it illustrates how requirements feed forward into design and testing, covering two of this topic's subtopics at once.
These videos extend the module's core skills into the documentation stage. The SRS lecture shows how requirements are formally written down and separated into categories and qualities, supporting MO3 by giving you a structure in which functional and non-functional interface specifications are recorded. The stakeholder collaboration video reinforces MO2 by showing that requirements gathering is an ongoing relationship with users and sponsors, not a single interview session. The traceability demonstration connects back to MO1 by showing why use case scenarios must be identifiable and linked artifacts, so that each user goal you compose can be traced through to the design and tests that satisfy it.
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.