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.