↑ 3 - Use Case Scenarios and Requirements Gathering

3 - Use Case Scenarios and Requirements Gathering

Introduction to Use Case Scenarios

1

Introduction to Use Case Scenarios

▶

Software projects fail for many reasons, but one of the most common is a gap between what stakeholders intend a system to do and what developers actually build. Use Case Scenarios exist precisely to close that gap. They are a structured, narrative technique for capturing how a person interacts with a system to achieve a specific goal, written in language clear enough for every stakeholder to read, challenge, and confirm. Before writing a single line of code or drawing a single wireframe, teams that invest time in solid use case scenarios tend to discover ambiguities, contradictions, and missing requirements early — when they are cheap to fix rather than expensive to rework.

Understanding use cases thoroughly means understanding not just their format but their purpose, their relationship to other requirements artifacts, and the discipline required to keep them user-centered. The sections below build that understanding from the ground up.

What Is a Use Case Scenario?

A use case scenario is a focused description of a single goal that a user (or another external system) wants to accomplish, told as a sequence of interactions between that user and the system. The word scenario is deliberate: it implies a story with a beginning (something triggers the interaction), a middle (a sequence of steps unfolds), and an end (the goal is either achieved or not). Every detail in a use case scenario is anchored to that goal — if a detail does not help explain how the goal is pursued or what can go wrong along the way, it does not belong.

Three qualities define a well-formed use case scenario:

  • Goal orientation. The scenario focuses on exactly one thing the user is trying to accomplish — for example, "withdraw cash from an ATM," "register for a university course," or "submit an insurance claim." If a scenario tries to cover multiple independent goals at once, it becomes too large to reason about and too vague to test.
  • User perspective, not system internals. A use case describes what the user sees and does and what the system presents or responds with — not how the database stores a record or how a microservice authenticates a token. The internal logic is hidden behind the system's responses. This keeps the scenario readable by non-technical stakeholders and prevents it from becoming prematurely tied to implementation decisions that may change.
  • Concrete and testable. Abstract requirements like "the system shall be user-friendly" cannot be tested. A use case scenario like "the user enters an invalid date format and the system displays an inline error message identifying which field is wrong" can be directly turned into a test case. This testability is one of the most powerful practical benefits of the technique.

Because scenarios are written in plain, structured prose rather than formal notation or code, both a chief technology officer and a customer-service manager can read the same document and either confirm it matches their understanding or point out where it does not. That shared readability is not a cosmetic nicety — it is the mechanism by which the technique catches misunderstandings before they become defects.

Consider a simple example. Suppose a team is building an online library catalogue. A vague requirement might read: "Users can search for books." A use case scenario for the same capability might look like this:

Goal: Find a book by title keyword
Actor: Library patron
Precondition: The patron has opened the catalogue home page.

Main success scenario:
  1. The patron types one or more keywords into the search box.
  2. The patron presses Enter or clicks the Search button.
  3. The system displays a list of matching titles, showing author,
     publication year, and availability status for each.
  4. The patron clicks a title of interest.
  5. The system displays the full record for that title.
  6. The patron notes the call number and closes the record.

Postcondition: The patron has identified a book they wish to locate
               on the shelves.

Even this short scenario raises questions a feature list never would: What if no results are found? How many results appear per page? What counts as a "match" — exact title only, or any keyword in the title? Each of those questions points to a real design or business decision that must be made before the feature can be built correctly.

Role of Use Cases in Requirements Gathering

Requirements gathering is the process of discovering, documenting, and validating what a system must do. It is notoriously difficult because stakeholders often cannot articulate their needs in abstract terms — they think in terms of tasks they perform, problems they encounter, and outcomes they care about. Use cases align naturally with that way of thinking, which is why they are such an effective elicitation tool.

When a business analyst sits down with a stakeholder and asks "Walk me through how you currently handle a customer return," the stakeholder narrates a sequence of actions and decisions — exactly the raw material of a use case. The analyst can then draft a scenario, review it with the stakeholder, and refine it until both parties agree it accurately represents the intended system behavior. That review cycle transforms vague intentions into verifiable, documented agreements.

  • Translating stakeholder goals into verifiable system behaviors. Every step in a use case describes something the system must do or something the user must be able to do. Each of those steps can later become one or more test cases. A requirement that cannot be expressed as a step in some use case scenario is either too vague to implement or perhaps not a real requirement at all.
  • Providing a shared reference point. Designers use use cases to understand what screens and interactions are needed. Developers use them to understand the expected system responses. Testers use them as the basis for test scripts. When all three groups are working from the same document, misalignments between design, implementation, and testing are far less likely. This shared reference also means that when a dispute arises about what the system "should" do, the team has an agreed-upon document to consult rather than relying on whoever can argue most forcefully.
  • Prioritizing and scoping work. Because each use case represents a complete user goal, it forms a natural unit of work that can be estimated, prioritized, and included or excluded from a release scope. A feature list entry like "reporting" is too large and vague to schedule. Use cases like "generate monthly sales summary report" and "export customer contact list to CSV" are discrete, estimable, and independently shippable.
  • Revealing gaps. Feature lists describe capabilities in isolation. Use cases describe capabilities in context — what the user does before, what state the system must be in, what happens afterward. That contextual structure exposes gaps that feature lists routinely hide. A team might list "user authentication" as a feature without ever considering: What happens when a session expires mid-transaction? What if the user has forgotten their password and there is no reset mechanism yet? Use cases surface these gaps because they force the team to walk through the complete interaction.

Key Components of a Use Case

A fully specified use case contains several standard components. Not every project requires the same level of formality, but understanding each component and its purpose allows a team to make deliberate choices about which details to include.

  • Actor. The actor is the entity — almost always a human user, but sometimes an external system — that initiates the interaction and has the goal the use case serves. Identifying the actor precisely matters because different actors may have different permissions, different data, and different success criteria for what looks like "the same" action. A customer browsing products and an inventory manager browsing products are different actors with different goals and different system behaviors available to them. Actors are described by their role, not by their name — "registered customer," not "Jane Smith."
  • Preconditions. Preconditions state what must already be true about the system and the actor before the use case can begin. They are not steps in the scenario; they are assumed facts. For example: "The user is logged in," or "The shopping cart contains at least one item," or "The requested document has been approved by a manager." Preconditions are important because they define the scope of the use case — they tell the reader what scenarios are handled elsewhere. If the user is not logged in, a different use case handles that.
  • Main success scenario (happy path). This is the numbered sequence of steps that describes the ideal interaction — the one where everything goes as expected and the actor achieves their goal. Steps alternate between actor actions and system responses. Each step should be atomic and observable. "The user completes the form and submits it" is too compressed. "The user fills in the required fields and clicks Submit" followed by "The system validates the input and displays a confirmation message" is better because each step is independently verifiable. The main success scenario is the backbone of the use case; all other components extend or qualify it.
  • Alternative flows (extensions). Real interactions rarely follow the happy path every time. Alternative flows document the branching logic: what happens when the user enters invalid data, when a network timeout occurs, when a required resource is unavailable, or when the user chooses an optional path. Each alternative flow is anchored to a specific step in the main scenario and describes how the interaction diverges from and, where possible, rejoins the main flow. For example: "At step 3, if the credit card number fails validation, the system highlights the card number field and displays the message 'Please check your card number.' The user may correct the entry and return to step 3, or cancel the transaction." Without alternative flows, a use case is incomplete — it describes only one of many possible realities.
  • Postconditions. Postconditions describe the state of the system after the use case completes — both on success and, where relevant, on failure. A success postcondition for an order placement use case might be: "A new order record exists in the system with status 'Confirmed,' and a confirmation email has been queued for delivery to the customer." A failure postcondition might be: "No order record has been created and the customer's payment method has not been charged." Postconditions matter because they define the boundary between this use case and whatever comes next, and they make the scenario testable: after executing the scenario, a tester can inspect the system and verify that the postcondition holds.

The table below summarizes each component, its purpose, and a brief example drawn from an e-commerce checkout scenario:

Component Purpose Example (E-commerce Checkout)
Actor Identifies who initiates and participates in the interaction Registered customer
Preconditions States what must be true before the scenario begins Customer is logged in; cart contains at least one item; item is in stock
Main success scenario Describes the ideal step-by-step interaction Customer reviews cart → enters shipping address → selects payment method → confirms order → system creates order and sends confirmation email
Alternative flows Documents divergences from the main path Payment is declined → system notifies customer and prompts for a different payment method
Postconditions Describes system state after the scenario completes Order record created with status "Confirmed"; inventory decremented; confirmation email queued

Use Cases vs. User Stories

Use cases and user stories are both user-centered requirements techniques, and they are often confused or conflated. Understanding the differences — and the legitimate uses of each — helps teams choose the right tool for their situation and avoid applying either technique poorly.

A user story is a short, informal statement of a user's need, typically written in the form: "As a [role], I want [capability] so that [benefit]." For example: "As a registered customer, I want to save my shipping address so that I don't have to re-enter it every time I check out." The story is intentionally brief. It is a placeholder for a conversation, not a complete specification. Details are worked out just in time, typically in a sprint planning meeting or a backlog refinement session.

A use case for the same capability would specify the actor, preconditions, the step-by-step interaction for saving an address, the steps for selecting a saved address during checkout, what happens when the user wants to edit or delete a saved address, what happens if the save fails, and what the system state looks like afterward. That level of detail is far more than a user story provides — and intentionally so, for different reasons.

  • Depth of detail. User stories defer detail to later conversations. Use cases capture detail upfront. Neither approach is universally superior; the right choice depends on project context, team size, stakeholder availability, and the cost of late-stage changes.
  • Alternative paths and edge cases. User stories typically describe only the happy path. Edge cases and error conditions are either captured as separate stories or discussed informally. Use cases explicitly require the team to document alternative flows, which means edge cases are identified and agreed upon before development begins rather than discovered during testing or after release.
  • Planning fit. User stories integrate naturally into agile iteration planning. Their brevity makes them easy to estimate, prioritize, and reorganize. Use cases are more naturally suited to environments where upfront specification is valued — regulated industries, large enterprise projects, or safety-critical systems where the cost of a misunderstood requirement is very high.
  • Shared emphasis on user goals. Despite their differences in format and granularity, both techniques share a foundational principle: the user's goal must remain central. A use case that drifts into describing database schemas has lost its purpose just as surely as a user story that describes an API endpoint. The discipline of keeping requirements user-centered is what both techniques, at their best, enforce.

In practice, many teams use both. User stories drive sprint planning and backlog management. For complex or high-risk features, the team elaborates the story into a full use case before development begins. This hybrid approach captures the planning flexibility of user stories and the analytical rigor of use cases without forcing a choice between them.

To make the comparison concrete, consider the same feature — "reset a forgotten password" — expressed both ways:

Aspect User Story Use Case Scenario
Format "As a registered user, I want to reset my password so that I can regain access to my account." Structured document with actor, preconditions, numbered steps, alternative flows, postconditions
Length One sentence One to several pages depending on complexity
Edge cases covered Implicitly deferred (e.g., link expires, email not found) Explicitly documented as alternative flows
Testability Requires elaboration before test cases can be written Steps map directly to test cases
Best suited for Agile sprint planning, backlog management Upfront specification, regulated or complex systems

Use Case Scenarios, then, are not a relic of a pre-agile era — they are a precise, powerful tool for making requirements concrete, shared, and verifiable. Whether a team uses them exclusively, alongside user stories, or selectively for complex features, the discipline of thinking through a user's complete interaction with a system — including what can go wrong — produces better software and fewer surprises at delivery time.

NotesConsider supplementing this topic with a hands-on activity where students take a vague feature statement and progressively build it into a full use case scenario, adding each component in turn. This reinforces the structural understanding and immediately shows students how much detail a feature list omits.
2

Videos on This Topic

▶

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.

3

Video 1: Understanding Use-Cases & User Stories | Use Case vs User Story | Object Oriented Design | Geekific

▶

Geekific · 10:09 · 79,554 views · 5y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: Use Case Description EXAMPLE [ Use Case Tutorial and Best Practices ]

▶

The Business Analysis Doctor - IIBA Certification · 18:22 · 40,283 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: UML use case diagrams: Everything you need to know

▶

Lucid Software · 12:42 · 1,027,119 views · 3y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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.

7

About These Videos

▶

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.

Identifying Stakeholders and Users

1

Identifying Stakeholders and Users

▶

Before a single use case can be written or a single requirement can be documented, a project team must answer a deceptively simple question: who cares about this system? The answer is almost never a short list. Systems are embedded in organizations, and organizations are webs of people, roles, departments, external partners, regulators, and automated processes — all of whom may have a stake in what the system does, how it does it, or what it produces. Stakeholder and user identification is the analytical work that makes this web visible, and it is foundational to everything that follows. When done well, it prevents requirement gaps, reduces late-stage change requests, and ensures the resulting system actually serves the people who need it. When done poorly — or skipped — teams discover missing requirements only after costly development work has already been completed.

Defining Stakeholders

A stakeholder is any individual, group, or organization that has an interest in a system's existence, behavior, or outcomes. This definition is deliberately broad, because the consequences of a system extend well beyond the people who sit at its keyboard. Stakeholders are typically organized into three categories that reflect how directly they are involved with the system.

Primary stakeholders directly use or operate the system on a day-to-day basis. They interact with the system's interface, enter data, trigger processes, and receive immediate outputs. A warehouse worker scanning barcodes into an inventory management system, a nurse entering patient vitals into an electronic health record, and a customer browsing products on an e-commerce site are all primary stakeholders. Because primary stakeholders experience the system most intensely, their needs tend to dominate discussions about usability, workflow efficiency, and error handling. Their input is essential during requirements gathering because they can identify friction points, workarounds, and task sequences that no document will reveal.

Secondary stakeholders are affected by the system's outputs without directly using it themselves. A hospital administrator who reviews reports generated by the patient records system is a secondary stakeholder — she never logs in, but the accuracy and timeliness of the system's output directly affects her decisions. Other examples include downstream departments that receive data exports, customers who receive invoices produced by a billing system, or regulatory bodies that audit system-generated logs. Secondary stakeholders are easy to overlook precisely because they are not present at the keyboard, yet their needs can impose significant requirements on the system. A secondary stakeholder who discovers six months into a project that the system cannot produce a legally required report has the potential to derail an entire release.

Key stakeholders possess formal authority over the project itself. They can approve or veto requirements, authorize budget and schedule changes, and ultimately decide whether the delivered system is acceptable. Project sponsors, product owners, department heads, and regulatory compliance officers fall into this category. Key stakeholders may or may not use the system directly, but their approval is required for the project to proceed. Requirements analysts must maintain close communication with key stakeholders because their priorities shape the scope, constraints, and acceptance criteria of the entire engagement.

Failing to identify all stakeholders is consistently cited as one of the leading causes of requirements gaps in software projects. When a stakeholder category is missed, its requirements are not gathered. Those requirements surface later — during testing, during a compliance audit, or after deployment — at a point when addressing them is far more expensive than it would have been during analysis. Systematic stakeholder identification is therefore not a preliminary formality; it is a risk mitigation activity.

Distinguishing Users from Stakeholders

Every user is a stakeholder, but not every stakeholder is a user. This distinction matters because use cases are organized around actors — the entities that interact directly with the system to accomplish goals — and confusing actors with the broader stakeholder population produces use cases that are either too broad or aimed at the wrong audience.

In use-case modeling, actors represent user roles, not named individuals. An actor is an abstraction that captures a coherent set of behaviors and goals. The actor "Loan Officer" represents every person who holds that role and interacts with the system in that capacity, not a specific employee named Maria Chen. This abstraction is important because it keeps use cases reusable and role-focused. When we write a use case for "Loan Officer," it applies to every loan officer in the organization, regardless of turnover, assignment, or branch location.

A single stakeholder may perform multiple actor roles across different scenarios. A hospital administrator might act as "Report Viewer" when reviewing dashboards and as "System Administrator" when configuring user accounts. Each role implies a different set of interactions, permissions, and goals, and should be modeled as a distinct actor even when the same human being performs both. Collapsing multiple roles into a single actor produces use cases that are ambiguous about preconditions, permissions, and expected outcomes.

Non-human actors deserve explicit attention. External systems, automated batch processes, hardware devices, and third-party APIs all interact with systems in ways that must be accounted for in use cases. A payment gateway that initiates a callback, a sensor that pushes telemetry data, or a nightly batch job that archives records — each of these is an actor. Omitting non-human actors from analysis causes teams to miss integration requirements, timing constraints, and error-handling scenarios that only arise at system boundaries.

Clearly separating users (actors) from the broader stakeholder population sharpens the focus of each use case. When analysts confuse the two, use cases drift toward describing organizational concerns — reporting hierarchies, approval authorities, business rules about who owns a process — rather than the concrete interactions between a role and the system. Stakeholder concerns inform the context of use cases (their preconditions, postconditions, and business rules), but the use case itself is structured around what an actor does with the system.

Stakeholder Needs vs. User Goals

Although stakeholders and users are related, their motivations operate at different levels of abstraction, and conflating the two leads to requirements that are either too vague to implement or too narrow to satisfy the organization.

Stakeholder needs tend to be high-level and strategic. A chief financial officer needs to reduce invoice processing costs. A compliance department needs to ensure that all data handling meets GDPR requirements. A VP of operations needs real-time visibility into fulfillment bottlenecks. These needs drive system objectives and constraints. They answer the question: why does this system need to exist? Stakeholder needs appear in project charters, business cases, and high-level requirements documents. They set the boundaries within which the system must operate.

User goals are tactical and task-oriented. A billing clerk needs to match a purchase order to an invoice in fewer than thirty seconds. A warehouse picker needs to find the correct bin location without navigating more than two screens. An IT administrator needs to reset a user's password without filing a support ticket. User goals drive the specific workflows, interface behaviors, and system responses that the system must support. They answer the question: what does this person need to accomplish right now? User goals are the raw material from which individual use cases are constructed.

Unresolved conflicts between stakeholder needs and user goals produce systems that are either unusable or non-compliant. Consider a case where a compliance stakeholder requires that every action be logged with a detailed audit trail, but users require a fast, keyboard-driven workflow with minimal confirmation dialogs. If this tension is not identified and resolved during requirements analysis, the team will either build a system that users abandon because it is too slow, or one that fails an audit because logging was silently omitted to meet performance targets. Surfacing these conflicts early — through workshops, prototypes, and negotiated acceptance criteria — is far less costly than discovering them after development.

A well-maintained requirements document traces each use case back to at least one stakeholder need. This traceability ensures that every use case can be justified by a real business objective, and that every stakeholder need is addressed by at least one use case. Traceability matrices are a common tool for maintaining this linkage throughout the project lifecycle.

User Roles and Permissions

Once actors have been identified, the next analytical step is to characterize each role's scope of interaction with the system. Different roles perform different tasks, have access to different data, and operate under different constraints. Treating all users as interchangeable produces systems that are either over-permissive (everyone can do everything) or under-specified (critical workflows are never modeled).

Each distinct role should have its own set of use cases or, where the workflows are similar, its own documented variation of a shared use case. A "Customer" and a "Customer Service Representative" might both perform a "Search Order History" task, but their access scope differs — the customer sees only her own orders, while the representative can search across all customers. This difference in scope has implications for system behavior, data filtering logic, and interface design. Modeling them as separate use cases or as separate actors in a shared use case makes this difference explicit.

Permissions and access restrictions should be captured in the preconditions of relevant use cases. Rather than burying access control in a separate security specification that no one reads alongside the use cases, analysts should state preconditions such as "The actor must be logged in with the Inventory Manager role" or "The actor must have Edit permissions on the target record." This keeps permission requirements visible to designers and developers working from the use case, reducing the likelihood that access control is implemented inconsistently.

Role analysis frequently reveals the need for administrative or configuration use cases that might otherwise be overlooked. When analysts discover that a "Store Manager" role can configure product pricing, they have identified a use case — "Configure Product Pricing" — that must be designed, built, and tested. Without systematic role analysis, configuration and administration capabilities are often deferred or discovered too late in the project. These capabilities are particularly prone to being forgotten because they are used infrequently and are not part of the primary business workflow that dominates requirements discussions.

User roles should be validated with actual representatives of those roles. Analysts who define roles entirely from org charts and job descriptions frequently discover, upon talking to real workers, that formal job titles do not map cleanly to system behaviors. A "Senior Analyst" may perform tasks listed under three different formal roles, or two people with the same title may have entirely different workflows depending on their team. Validation interviews and observation sessions — job shadowing, think-aloud protocol tests, or contextual inquiry — resolve these discrepancies before they propagate into the use case model.

Techniques for Stakeholder Identification

Stakeholder identification is not a one-time event. It is an iterative analytical process that benefits from multiple complementary techniques used across the life of the project.

Stakeholder mapping is a visual technique that places the system at the center of a diagram and maps the relationships between different stakeholder groups and the system, and between groups themselves. Mapping makes it easy to spot categories of stakeholders that have not been represented in analysis sessions, to identify stakeholders who have conflicting interests, and to communicate the stakeholder landscape to project sponsors who may not be familiar with requirements analysis methods. A simple power-interest grid — plotting stakeholders by their influence over the project against their level of interest in its outcomes — is a common variant that helps teams prioritize engagement effort.

Reviewing existing documentation surfaces stakeholders who are embedded in organizational processes but not immediately visible to the analysis team. Organizational charts reveal formal reporting structures and department boundaries. Process manuals and standard operating procedures identify roles that interact with current workflows. Service-level agreements and contracts identify external parties with formal interests in system behavior. Job descriptions reveal tasks that suggest system interactions. System architecture diagrams for existing systems reveal integration points that imply external actors. Each document type opens a different window onto the stakeholder landscape.

Interviews with domain experts are among the most effective techniques for discovering informal or hidden stakeholders. Domain experts — experienced workers who have operated within the organizational context for years — know about workarounds, unofficial processes, and informal coordination mechanisms that no document records. They are aware of the vendor representative who emails spreadsheets every Monday morning, of the auditor who requests ad-hoc data extracts twice a year, and of the remote team that relies on a data feed that no one has officially documented. Structured interviews with open-ended questions ("Who else receives the output of this process?" "Who has ever complained about the way this currently works?") reliably uncover stakeholders that a desk-based analysis would miss.

Iterating stakeholder identification throughout the project acknowledges that the stakeholder population is not static. New regulatory requirements may introduce compliance stakeholders midway through a project. An organizational restructuring may create new roles or eliminate existing ones. A merger may introduce an entirely new user base with its own needs and expectations. Requirements analysts who treat stakeholder identification as a closed activity completed in week one will be unprepared for these changes. Building regular stakeholder review checkpoints into the project schedule — aligned with phase gates, sprint reviews, or major milestone reviews — ensures that the stakeholder model remains current and that emerging stakeholder needs are captured before they become expensive surprises.

The table below summarizes the three stakeholder categories, their relationship to the system, and the primary risks of failing to engage them during requirements analysis.

Stakeholder Category Relationship to System Typical Representatives Risk of Omission
Primary Directly use or operate the system End users, operators, data entry staff, field workers Usability failures, workflow mismatches, high training burden, user rejection
Secondary Affected by system outputs without direct use Managers, downstream departments, customers, regulators, auditors Missing reporting requirements, compliance failures, downstream process breakdowns
Key Authority to approve or change requirements Project sponsors, product owners, department heads, compliance officers Scope creep, late-stage requirement reversals, failed acceptance reviews

Effective stakeholder identification is ultimately an act of organizational empathy — the analytical discipline of ensuring that every group affected by a system has a voice in defining what that system must do. It is the prerequisite for all other requirements activities, and the quality of every subsequent artifact — use cases, data models, acceptance criteria, test plans — depends directly on how thoroughly and accurately this foundational work is done.

NotesStudents often conflate the actor in a use case with the concept of a stakeholder. Reinforce the distinction: actors are roles that interact with the system (a subset of stakeholders), while stakeholders include anyone with an interest in the system's outcomes. Encourage students to build a simple stakeholder register alongside their use case diagrams and to trace each use case back to at least one identified stakeholder need. The role/permissions section pairs well with hands-on exercises where students map roles to CRUD (Create, Read, Update, Delete) permissions on key system entities.
2

Videos on This Topic

▶

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.

3

Video 1: Stakeholder Interviews 101

▶

NNgroup · 5:11 · 16,042 views · 2y ago · captions — Watch on YouTube

About this video

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.

Why this video

A second pass helps you separate stakeholder needs from user goals, which is the distinction most often confused when students begin writing scenarios.

4

Video 2: How to Identify Stakeholders Easily

▶

Adriana Girdler · 4:53 · 17,521 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: stakeholder and types | software Engineering lec 12

▶

Sumaira Maqbool · 7:09 · 15,758 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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).

7

About These Videos

▶

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.

Requirements Gathering Techniques

1

Requirements Gathering Techniques

▶

Requirements elicitation is the disciplined process of discovering, extracting, and articulating what a system must do and what qualities it must possess. It sits at the very foundation of any software or systems development effort, and the consequences of doing it poorly ripple outward through every subsequent phase of a project. Studies consistently identify poorly elicited or ambiguously documented requirements as the leading cause of project failure — not faulty code, not inadequate testing, and not poor project management, but a fundamental misunderstanding of what the system was supposed to accomplish in the first place. Understanding elicitation techniques thoroughly is therefore not an academic exercise; it is the most practical skill a business analyst, systems engineer, or product manager can develop.

A foundational insight is that no single elicitation technique is sufficient on its own. Every method has blind spots. Interviews reveal individual perspectives but may miss cross-functional conflicts. Workshops surface shared understanding but can be dominated by vocal stakeholders. Surveys reach large audiences but sacrifice depth. Document analysis reveals history but not future intent. Skilled practitioners treat these techniques as complementary instruments in an ensemble, selecting and combining them based on the nature of the project, the availability of stakeholders, and the type of information being sought.

A second critical insight is the distinction between explicit stated needs and implicit assumed behaviors. Explicit requirements are the ones stakeholders consciously articulate: "The system must allow a user to reset their password." Implicit requirements are the ones nobody mentions because everyone assumes they are obvious: "Of course the system won't display another user's private data." Implicit requirements are particularly dangerous because they go undocumented and therefore unverified. Effective elicitation actively hunts for implicit assumptions by asking probing follow-up questions, observing actual work practices, and reviewing analogous systems. The classic example is a stakeholder who requests "a faster horse" when what they actually need is reliable transportation — the stated request encodes an implicit assumption about the solution space that, if accepted literally, forecloses better alternatives.

Requirements elicitation is also iterative rather than a one-time event. Early in a project, stakeholders often cannot fully articulate their needs because they have not yet seen prototypes, encountered edge cases, or thought through complex scenarios. As the project progresses and stakeholders interact with wireframes, prototypes, and partial implementations, new requirements emerge and earlier ones are refined or even reversed. Agile methodologies formalize this reality by incorporating regular backlog refinement sessions and sprint reviews as ongoing elicitation activities. Even in plan-driven environments, change control processes exist precisely because elicitation never truly ends. Analysts who treat the initial requirements document as a sealed artifact do so at their peril.

Interviews and Contextual Inquiry represent the most personal and direct category of elicitation techniques. An interview is a structured or semi-structured conversation between an analyst and one or more stakeholders, conducted with the explicit goal of uncovering needs, constraints, goals, and concerns. The power of interviews lies in their directness: there is no intermediary, no survey form standing between the analyst and the stakeholder's knowledge.

Structured interviews follow a predetermined script of questions, ensuring that the same questions are asked of every participant. This consistency makes responses comparable across interviewees and is especially valuable when the analyst needs to identify patterns or disagreements across a stakeholder population. For example, if an analyst is gathering requirements for an expense management system and asks every department manager the same twelve questions about their approval workflow, the responses can be tabulated and analyzed systematically. The tradeoff is rigidity: a structured interview may miss information that falls outside the prepared question set, and it can feel impersonal to stakeholders who want to explain their situation in their own terms.

Unstructured interviews take the opposite approach. The analyst begins with a broad opening prompt — "Tell me about how you currently handle customer onboarding" — and then follows the stakeholder's train of thought, asking clarifying and probing questions as the conversation develops. Unstructured interviews are excellent for early-stage discovery when the analyst does not yet know enough about the domain to formulate specific questions. They surface unexpected concerns and reveal the stakeholder's mental model of the problem space. The tradeoff is that results are harder to compare across participants and the conversation can wander into topics that are not directly relevant.

In practice, most professional interviews are semi-structured: the analyst prepares a set of anchor questions to ensure that key topics are covered, but allows the conversation to diverge when productive threads emerge, then steers back to the remaining anchor questions. A well-prepared semi-structured interview guide for a new inventory management system might include anchor questions such as: What is the biggest pain point in your current inventory process? How do you currently handle discrepancies between physical stock and system records? What reports do you use most frequently, and what decisions do they support? Each of these anchors can spawn multiple follow-up probes depending on the answers given.

Contextual inquiry is a more immersive technique that combines interview with direct observation. Rather than asking a warehouse supervisor to describe how they receive shipments, the analyst visits the warehouse, watches the supervisor process an actual delivery, and asks questions in the moment: "I noticed you just cross-referenced that packing slip against a spreadsheet on your phone — is that a standard step in the process?" Contextual inquiry is particularly powerful for surfacing implicit requirements, because people routinely do things they would never think to mention in a traditional interview. The workaround spreadsheet, the sticky note on the monitor, the verbal confirmation shouted across the room — these workarounds and informal practices reveal gaps in existing systems and often point directly to high-value requirements in the new one.

Regardless of interview format, prompt review of notes and recordings is essential. Memory degrades rapidly after an interview, and context that seemed obvious in the moment becomes ambiguous hours later. Best practice is to write up a clean summary of each interview within 24 hours, noting not just what was said but the analyst's interpretations and any follow-up questions that need to be asked. Many analysts send a brief summary to the interviewee for confirmation, which both validates the interpretation and builds stakeholder trust.

Workshops and Focus Groups gather multiple stakeholders simultaneously to elicit requirements through facilitated group discussion. The fundamental advantage of a workshop over individual interviews is efficiency: a skilled facilitator can surface, discuss, and provisionally resolve a requirement in a two-hour workshop that would have required three separate interviews and two follow-up email chains to achieve the same result. More importantly, workshops surface divergent stakeholder perspectives in a forum where they can be negotiated directly rather than discovered later as conflicting requirements documents.

Consider a scenario in which the sales team and the finance team both have requirements for a new CRM system. In individual interviews, each group might describe their needs without awareness of the other's constraints. In a workshop, when the sales director says "the system should allow reps to offer custom pricing discounts without approval" and the CFO immediately responds "that would make revenue recognition impossible to manage," the conflict is surfaced and must be resolved before it becomes embedded in contradictory requirements. Workshops make this kind of cross-functional alignment possible.

Structured workshop activities are essential for keeping large groups productive. A scenario walkthrough asks participants to trace a complete business process step by step — for example, walking through the entire order-to-cash cycle from customer inquiry to payment receipt — and identifying where the current process breaks down and what the new system must do differently at each step. A requirements brainstorming session might use affinity mapping: participants write requirements on sticky notes, which are then grouped into themes on a whiteboard, giving the group a visual map of the requirement landscape. A prioritization exercise such as MoSCoW (Must Have, Should Have, Could Have, Won't Have) can help stakeholders reach consensus on scope before they leave the room.

Remote and distributed teams require additional deliberate effort to replicate the collaborative energy of in-person workshops. Tools such as Miro, MURAL, and Microsoft Whiteboard provide virtual sticky notes, diagrams, and voting features that support the same structured activities. Video conferencing with breakout rooms allows the facilitator to split a large group into smaller working groups for focused exercises. The key discipline for remote workshops is over-facilitation: in a physical room, body language signals confusion or disengagement; on a video call, silence is ambiguous. Remote facilitators must check in more frequently, call on participants by name, and use polls and visual artifacts to maintain active participation.

Surveys and Questionnaires are the appropriate tool when the analyst needs to reach a large or geographically dispersed stakeholder population, when statistical analysis of responses is desired, or when the project budget and timeline do not permit individual interviews with every affected user. A survey is an asynchronous, self-administered instrument — stakeholders complete it on their own time — which makes it scalable in a way that interviews and workshops are not.

Closed questions offer predefined response options: yes/no, multiple choice, Likert scales (e.g., "Rate your satisfaction with the current reporting feature on a scale of 1 to 5"), or ranked lists. Closed questions produce structured, quantifiable data. If 73% of respondents indicate that they find the current search feature "difficult" or "very difficult" to use, that is a statistically meaningful finding that can directly justify a requirement: "The new system's search functionality must achieve a usability rating of 4 or higher on a 5-point scale from at least 80% of users." Closed questions also make analysis efficient — responses can be aggregated automatically by any survey tool.

Open questions invite free-text responses: "What is the most frustrating aspect of the current system?" or "Describe a recent situation where the system failed to support your work." Open questions can surface entirely unexpected needs that the analyst would never have thought to ask about directly. A closed question asking about satisfaction with specific features assumes the analyst already knows which features matter; an open question about frustration might reveal that the real problem is something the analyst had not yet considered. The cost is analytical effort: free-text responses must be read, coded, and synthesized manually, which is time-consuming at scale.

Survey design quality is critical and frequently underestimated. Leading questions bias respondents toward the answer the question implies: "How much would you benefit from a faster dashboard?" presupposes that the current dashboard is too slow and that speed is a priority. A neutral formulation is: "How would you describe the current dashboard's loading speed?" Loaded questions, double-barreled questions ("Do you find the system fast and easy to use?" conflates two dimensions into one), and ambiguous terms ("frequently," "often," "large") all degrade the validity of survey data. Every survey should be piloted with a small group before broad distribution to catch these problems.

Response rates and sample representativeness determine how much confidence can be placed in survey results. A survey completed by 200 out of 1,000 users has a 20% response rate. If those 200 respondents are disproportionately power users, senior staff, or people with strong grievances, the data will not represent the full user population. Analysts should segment responses by user role, department, or experience level to check for representation gaps and should interpret results cautiously when response rates are low or sample composition is skewed. Following up with targeted outreach to underrepresented groups — or supplementing survey data with interviews from those groups — is often necessary to obtain a complete picture.

Document Analysis and Existing System Review is a form of elicitation that requires no live stakeholder interaction at all, yet can yield an enormous volume of requirements information. The premise is straightforward: the organization has been operating before this project began, and the artifacts it has produced — system documentation, process manuals, regulatory filings, training materials, screenshots, database schemas — encode a wealth of knowledge about current functionality, business rules, and user workflows.

Current system documentation — technical specifications, user manuals, API documentation, data dictionaries — establishes the baseline of what the existing system does. This baseline is critical for two reasons. First, it identifies functionality that must be preserved: if the current system generates 47 standard reports and the business depends on all of them, the new system must replicate that capability at minimum. Discovering this in the first week through document analysis is far better than discovering it in user acceptance testing. Second, baseline documentation reveals the technical constraints that the new system will need to accommodate: legacy data formats, integration points with other systems, and regulatory compliance requirements that are already baked into the current architecture.

Process manuals and standard operating procedures (SOPs) describe how work is supposed to be done. They capture the business rules, approval hierarchies, decision criteria, and workflow sequences that the new system must support. For example, an SOP for purchase order approval might specify that any purchase over $10,000 requires sign-off from a VP-level manager, while purchases under $500 can be approved by any team lead. These thresholds are explicit business rules that must be implemented in the new system and would easily be overlooked without document review.

However, documents describe the intended process, not necessarily the actual process. This gap is where gap analysis becomes essential. When document analysis is combined with contextual inquiry or interviews, analysts frequently discover that what people actually do differs significantly from what the manuals say they should do. A procurement manual might specify a three-quote requirement for all purchases over $5,000, but observations reveal that 40% of purchases in that range proceed with a single quote and a handwritten justification note. This discrepancy is itself a requirement: the new system needs to either enforce the three-quote rule (if the business wants to tighten compliance) or accommodate the single-quote exception workflow (if the workaround reflects legitimate business flexibility that the SOP failed to capture). Either way, it is a requirement that would have been invisible without comparing documented to observed behavior.

Legacy system constraints discovered during document review must be explicitly flagged as risks. An aging mainframe system may store customer records in a fixed-width flat-file format that cannot accommodate certain modern data structures. A legacy billing system may use a proprietary customer ID scheme that conflicts with the ID scheme the new system intends to use. These are not requirements for the new system per se, but they are constraints that will shape what the new system can and cannot do without costly data migration or integration work. Documenting them early — and flagging them as risks in the requirements documentation — ensures that architects, developers, and project managers are aware of them before they become expensive surprises late in the project.

The following table summarizes the primary elicitation techniques, their key strengths, their limitations, and the conditions under which each is most effective:

Technique Best Used When Key Strengths Key Limitations
Structured Interview Comparing responses across many stakeholders Consistent data; easy to compare; covers all planned topics May miss unanticipated issues; can feel rigid
Unstructured Interview Early discovery; exploring unknown domain Surfaces unexpected needs; builds rapport Hard to compare responses; can lose focus
Contextual Inquiry Surfacing implicit requirements; observing real workflows Reveals actual behavior; uncovers workarounds Time-intensive; requires site access; observer effect
Workshop / Focus Group Resolving cross-functional conflicts; shared processes Efficient; surfaces disagreements; builds consensus Risk of groupthink; dominant voices can skew results
Survey / Questionnaire Large or dispersed user population; quantitative data needed Scalable; anonymity encourages candor; comparable data Low response rates; limited depth; design errors bias results
Document Analysis Understanding baseline systems; discovering business rules Non-intrusive; comprehensive baseline; reveals legacy constraints Documents may be outdated; does not capture actual behavior

Bringing these techniques together in practice requires deliberate planning. A professional elicitation plan for a mid-size project might sequence the techniques as follows: begin with document analysis to understand the current system and business context before speaking with anyone; conduct unstructured discovery interviews with key stakeholders to understand priorities and pain points; follow up with contextual inquiry for high-complexity workflows to observe actual behavior; run a requirements workshop to synthesize findings, resolve conflicts, and prioritize; and deploy a survey to validate findings with a broader user population. Each technique informs and sharpens the next, and the combined output is far more complete and reliable than any single technique could produce alone.

The goal throughout is not simply to collect information but to build a shared, validated understanding of what the system must do — one that captures both what stakeholders say they need and what they actually need, one that makes implicit assumptions explicit, and one that is rich enough to support the writing of precise, testable use cases and requirements specifications. That shared understanding is the foundation on which every subsequent phase of the project depends.

NotesConsider supplementing this content with worked examples of interview question guides and sample survey instruments. The gap analysis concept pairs well with as-is / to-be process mapping exercises. The table provides a useful reference card students can return to when choosing techniques for case study assignments.
2

Videos on This Topic

▶

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.

3

Video 1: 5 Powerful Requirement Gathering Techniques Every Business Analyst Should Know

▶

Bridging the Gap - Resources for Business Analysts · 8:27 · 12,594 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: What are Contextual Inquiries?

▶

NNgroup · 3:01 · 19,608 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: Five User Interview Mistakes to Avoid (in 5 Minutes)

▶

NNgroup · 5:54 · 66,865 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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.

7

About These Videos

▶

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

1

Task Analysis

▶

Task analysis is the systematic study of how users actually perform their work — not how designers imagine they do, and not how a procedure manual says they should. Before a single use case can be written with confidence, analysts must develop a clear, accurate picture of the tasks users perform, the order in which they perform them, the decisions they make along the way, and the reasons behind those decisions. Without this foundation, use cases risk reflecting the assumptions of the development team rather than the reality of the people who will use the system. Task analysis bridges that gap, transforming observed or elicited user behavior into structured knowledge that directly shapes system requirements.

Task analysis is not a single technique but a family of complementary methods, each suited to different questions and contexts. At its core, every form of task analysis asks two intertwined questions: what do users do, and why do they do it? The "what" describes observable behavior — the clicks, keystrokes, form entries, phone calls, and physical actions that constitute a workflow. The "why" describes purpose, intent, and judgment — the goals users are trying to achieve, the constraints they are working within, and the knowledge they are drawing on. Answering both questions produces a richer, more reliable model than either alone.

One of the most practically important insights that task analysis surfaces is the mental model users bring to a system. A mental model is a user's internal representation of how a system works — often incomplete, sometimes incorrect, but always influential. When a user expects that clicking "Save" also submits a form, or that deleting a record also archives it for later retrieval, those expectations are mental model artifacts. Task analysis uncovers these models through observation, interviews, and think-aloud protocols, allowing designers and analysts to either align the system with users' existing mental models or to identify where training and interface design must bridge the gap. Ignoring mental models leads to systems that confuse and frustrate users even when they are technically correct.

Task analysis also functions as a diagnostic tool for existing workflows. When analysts observe users performing tasks in their current environment — whether paper-based, supported by a legacy system, or a patchwork of spreadsheets and email — they frequently discover inefficiencies: redundant data entry, unnecessary approval bottlenecks, steps that exist only because of limitations in old technology, or workarounds that users have invented to compensate for system deficiencies. These findings are valuable in two ways. First, they identify opportunities for the new system to add genuine value by eliminating unnecessary work. Second, they prevent the new system from simply automating a broken process — a common and costly failure mode in software projects.

The connection between task analysis and use case development is direct and structural. A use case describes an interaction between an actor and a system to achieve a goal. Task analysis identifies exactly those goals, the sequences of steps that lead to them, and the conditions that cause those sequences to vary. In practical terms, task analysis findings directly inform the step sequences in use case main flows. Each verified step in a task model becomes a candidate step in a use case. Decision points in the task become branching conditions that generate alternative flows. Error states and failure modes become exception flows. Task analysis, in short, supplies the raw material from which use cases are constructed — and it ensures that material is grounded in user reality rather than developer assumption.

Hierarchical Task Analysis (HTA) is the most widely used structured method for decomposing user tasks, and it is the natural starting point for analysts moving from task observation to use case writing. HTA begins with a single, high-level goal — for example, "Process a customer insurance claim" — and recursively decomposes it into sub-goals and eventually into discrete, observable actions. This decomposition continues until each leaf node represents a step that is atomic enough to be directly described in a use case or evaluated for interface design.

The defining structural element that separates HTA from a simple task list is the plan. Every node in an HTA that has children is accompanied by a plan that specifies the sequencing rules governing those children. Plans can express a variety of relationships:

  • Do in order (fixed sequence): Sub-tasks must be performed in a specific, unchanging order. For example, a user must authenticate before they can query a database.
  • Do in any order: Sub-tasks can be performed in whatever sequence the user prefers without affecting the outcome. For example, a user completing a profile form may fill in address fields in any order.
  • Do if condition (conditional execution): A sub-task is only performed if a specified condition is true. For example, "If the claim amount exceeds $10,000, obtain supervisor approval."
  • Do until condition: A sub-task is repeated until a condition is satisfied. For example, "Re-enter payment details until the transaction succeeds or three attempts are exhausted."
  • Do one of (selection): Exactly one sub-task from a set is performed depending on context. For example, a user either pays by credit card, bank transfer, or voucher.

These plans are not cosmetic annotations — they are the mechanism by which HTA captures the logic of a workflow, not just its components. When an analyst transfers HTA findings into use cases, the plans translate into the sequencing and branching structure of the use case flows. A fixed-sequence plan becomes a numbered list of main flow steps. A conditional plan becomes an alternative flow triggered by a stated condition. A selection plan becomes a branching point where the use case offers multiple paths.

Consider a partial HTA for the goal "Submit an online job application." The top-level goal decomposes as follows:

  • Goal 0: Submit an online job application — Plan: do 1, then 2, then 3, then 4 in order.
    • Sub-goal 1: Create or log into an account — Plan: do 1.1 if new user, else do 1.2.
      • Action 1.1: Complete registration form and verify email.
      • Action 1.2: Enter credentials and authenticate.
    • Sub-goal 2: Complete application form — Plan: do 2.1, 2.2, 2.3 in any order.
      • Action 2.1: Enter personal and contact information.
      • Action 2.2: Upload resume and supporting documents.
      • Action 2.3: Answer screening questions.
    • Sub-goal 3: Review application — Plan: do 3.1; if errors found, do 3.2 and return to sub-goal 2.
      • Action 3.1: Review all entered information for completeness and accuracy.
      • Action 3.2: Note fields requiring correction.
    • Action 4: Submit application and receive confirmation.

In this example, each leaf action (1.1, 1.2, 2.1, 2.2, 2.3, 3.1, 3.2, 4) represents a potential step in a use case scenario. Sub-goal 1's conditional plan directly maps to a branching condition in the use case's main or alternative flow. Sub-goal 3's error-handling plan maps to an exception or alternative flow. The HTA has done the analytical work; the use case writer's job is to translate it into the appropriate notation.

HTA diagrams — typically rendered as tree structures with plans annotated at each node — make complex workflows visible and communicable. This is not a trivial benefit. Stakeholders who would never read a dense textual task description can follow an HTA diagram in a review session, spot missing steps, correct misunderstandings, and validate the model against their own experience. HTA functions as a shared language between users, analysts, and developers, reducing the ambiguity that is the primary source of requirements defects.

Cognitive Task Analysis (CTA) addresses a fundamental limitation of behavioral methods like HTA: observable actions are only the surface of what users do. Behind every action lies a layer of perception, judgment, decision-making, and expertise that behavioral observation alone cannot reveal. CTA makes that invisible cognitive layer visible, and in doing so it captures the aspects of expert performance that are most likely to be omitted from requirements if not explicitly sought.

CTA is particularly indispensable in expert-intensive domains — fields where practitioners develop complex, situation-dependent judgment over years of experience. Physicians deciding whether a patient's symptoms warrant immediate intervention, air traffic controllers managing conflicts between flight paths, financial analysts assessing portfolio risk — all of these involve cognitive work that looks deceptively simple from the outside but is in fact the product of deep pattern recognition, probabilistic reasoning, and dynamic prioritization. A behavioral task analysis of a physician ordering a medication might capture the clicks involved; CTA would also capture the diagnostic reasoning that determined which medication to order, the contraindications checked, and the fallback decision made when the first-choice drug was unavailable.

CTA is conducted through several specialized techniques:

  • Critical Decision Method (CDM): Analysts work with experts to identify a challenging, non-routine incident from their experience, then probe it through structured interviews to surface the cues noticed, the options considered, the decisions made, and the outcomes assessed. Each decision point is a candidate for an alternative or exception flow in a use case.
  • Think-Aloud Protocol: Users verbalize their thoughts while performing a task. Analysts record not just what the user does but what they notice, what they are uncertain about, and what they are trying to avoid. This is particularly effective for revealing the conditions under which users deviate from the expected procedure.
  • Concept Mapping: Users draw or describe the relationships between key concepts in their domain. This surfaces the knowledge structures underlying their decisions and helps analysts understand why certain interface elements or data presentations will be meaningful (or confusing) to users.

The outputs of CTA feed directly into use case documentation in specific and valuable ways. The decision points uncovered by CTA — moments where the expert assesses a situation and chooses one of several possible actions — become the branching conditions that generate alternative flows. The failure recognition cues — the signals that tell an expert something has gone wrong — become the triggers for exception flows. For example, a CTA of a hospital pharmacist processing a prescription might reveal that the pharmacist checks for drug interactions with the patient's existing medications before dispensing. This cognitive step, invisible in a purely behavioral observation, would need to be represented in the use case: perhaps as a system-initiated check (an actor-system interaction step) or as a decision point that can trigger an exception flow when a dangerous interaction is detected.

The trade-off is real: CTA requires significantly more time and expertise to conduct than behavioral methods. Recruiting appropriate experts, conducting multiple CDM or think-aloud sessions, and analyzing the resulting qualitative data is resource-intensive. For routine, low-stakes tasks in non-expert domains, the investment may not be warranted. For safety-critical systems, systems supporting expert practitioners, or systems where errors have serious consequences, CTA is not optional — it is how analysts discover the requirements that would otherwise only be discovered in production, at great cost.

Mapping task analysis findings to use cases is the translation step that converts task models into requirements artifacts. The mapping is not mechanical — it requires judgment — but the structural correspondences are clear enough that analysts can follow a consistent approach. The following table summarizes the primary mappings:

Task Analysis Element Maps To in Use Cases Example
Major top-level task or sub-goal Distinct use case "Process insurance claim" becomes the use case Process Claim
Leaf action in a fixed sequence Numbered step in the main flow "User enters claim amount" becomes step 4 of the main flow
Conditional plan (do if condition) Branching condition introducing an alternative flow "If claim exceeds $10,000" triggers alternative flow A1: Supervisor Approval
Decision point from CTA Branching condition or system validation step Pharmacist's drug interaction check becomes a system-initiated validation at step 5
Error state or failure mode Exception flow "Document upload fails" becomes exception flow E2: Upload Failure
Repeated sub-task (do-until plan) Loop within a flow or separate use case with iteration noted "Re-enter payment until success" represented as a retry loop in the main flow
Selection among alternatives (do one of) Multiple alternative flows branching from a single step "Pay by card, transfer, or voucher" yields alternative flows A2, A3, A4

An important discipline in this mapping process is granularity management. HTA leaf nodes can sometimes be more fine-grained than is useful in a use case (for instance, "move mouse to Submit button" is a valid leaf node in an HTA but would never appear as a step in a use case). Analysts must apply judgment to select the appropriate level of abstraction — typically, steps that are meaningful from the actor's perspective and that represent a distinct interaction with the system. A useful heuristic is to ask: "Would omitting this step cause the system or the actor to misunderstand the interaction?" If yes, include it. If no, it may be safely collapsed.

Another key discipline is ensuring that task analysis findings are reviewed and validated with real users before use cases are written. Task models built entirely from analyst observation or stakeholder interviews without user feedback are systematically biased toward what is visible and what stakeholders believe happens, rather than what users actually do. Experienced users often perform tasks differently from novices; weekend usage patterns differ from weekday patterns; tasks performed under time pressure differ from tasks performed at leisure. All of these variations need to be captured in the task model to ensure that use cases reflect the full envelope of real-world behavior.

Validating task models with users is the final — and frequently underemphasized — step in task analysis. Validation is not a formality; it is the step that distinguishes a task model that is accurate from one that merely feels accurate. The core principle of user validation is to create conditions where discrepancies between the model and actual user behavior become visible and correctable before they propagate into requirements documents.

Effective validation sessions should include representatives of all major actor roles. If a system will be used by customers, customer service representatives, supervisors, and administrators, validation sessions should include participants from each group — not just the most accessible or most vocal stakeholders. Different actor roles often perform the same task in subtly different ways, or perform different sub-tasks entirely, and a task model that has been validated only with one actor type will contain blind spots for others.

The most effective validation technique is to ask users to perform or describe the task while the analyst tracks against the model. In a walkthrough session, the analyst presents the HTA or task flow (in whatever format is accessible to the user — often a simplified diagram or a plain-language numbered list rather than formal notation) and asks the user to follow along, flagging any step that does not match their experience. In a performance session, the user actually performs the task in their real environment while the analyst observes, comparing actual behavior to the model in real time. Discrepancies surface in several characteristic ways:

  • Missing steps: The user performs actions not represented in the model, often "invisible" steps that feel so automatic they were never mentioned in interviews.
  • Wrong sequence: The user performs steps in a different order than the model specifies, revealing that the plan annotations need correction.
  • Wrong conditions: The user applies a conditional plan under different circumstances than the model specifies, revealing that trigger conditions need refinement.
  • Absent variants: The user describes a scenario the model does not account for — a special case, an exception, or a role-specific variation that was never elicited.
  • Wrong granularity: The user experiences a "step" in the model as multiple distinct activities, or experiences multiple "steps" as a single, unified action, suggesting the decomposition level needs adjustment.

Every discrepancy discovered in a validation session must be resolved — not noted for later, not treated as an edge case to handle in implementation, but resolved by correcting the task model — before use cases are written. The cost of resolving a discrepancy in a task model is negligible. The cost of discovering the same discrepancy in a use case review is moderate. The cost of discovering it in testing or production is substantial. Validation sessions are the cheapest possible opportunity to catch errors in the analytical foundation of the requirements.

A validated task model is not merely a stepping stone to use cases — it is a durable artifact in its own right. When, months or years after initial development, a system needs to be updated, extended, or redesigned, the validated task model provides context that no use case document alone can supply. It explains why the system was designed the way it was, what user needs it was designed to address, and what the real-world workflow looks like. Teams that maintain task models alongside their use cases can make better-informed change decisions, avoid accidentally breaking workflows that depended on currently implemented behavior, and onboard new analysts far more efficiently than teams that have only use cases to work from.

In summary, task analysis — encompassing hierarchical decomposition through HTA, cognitive depth through CTA, systematic mapping to use case structures, and rigorous validation with real users — is the analytical foundation on which sound use case documentation is built. It replaces assumption with evidence, replaces developer-centric thinking with user-centric thinking, and replaces incomplete requirements with requirements that reflect the full complexity of the work the system must support.

NotesThe table mapping task analysis elements to use case constructs is a high-value study and reference aid — instructors may want to use it as a worksheet exercise where students map a sample HTA to use case flows. The job application HTA example can be replaced with a domain more relevant to the course (e.g., processing a bank loan, submitting an IT helpdesk ticket) without changing the structural lesson. The section on CTA is intentionally scoped to practical application in requirements work rather than the full academic literature on naturalistic decision-making, which would be excessive at this level.
2

Videos on This Topic

▶

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.

3

Video 1: Task Analysis

▶

Center for Community Engagement · 9:54 · 712 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: Cognitive Walkthroughs Help Assess Interface Learnability

▶

NNgroup · 4:45 · 14,522 views · 3y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: Difference between Work Breakdown Structure(WBS), PBS, RBS and OBS

▶

Pieter Rademeyer · 5:24 · 13,595 views · 2y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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).

7

About These Videos

▶

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.

Writing Use Case Scenarios

1

Writing Use Case Scenarios

▶

A use case scenario is one of the most powerful tools in a business analyst's or systems designer's repertoire. Where a use case itself describes what a system must support, the use case scenario describes precisely how that support unfolds — step by step, actor by actor, condition by condition. Writing good use case scenarios is both a discipline and a craft: the document must be rigorous enough to drive development and testing, yet clear enough that a business stakeholder can read it and confirm it matches their intent. This topic walks through every element of a well-constructed use case scenario, from the header that identifies and controls the document to the final postcondition that certifies a goal has been met.

The sections that follow treat each structural component in depth. Together they form a complete methodology for drafting use case scenarios that are traceable, testable, and unambiguous.

Structuring a Use Case Document

Before a single step of behavior is written, the use case document needs a solid structural skeleton. Structure is what makes a collection of use cases manageable across a large project and what allows any team member — developer, tester, or stakeholder — to locate exactly the information they need quickly.

Unique identifiers for traceability. Every use case must carry a unique identifier. A common convention is a prefix that signals the system or module followed by a sequential number: UC-001, UC-002, and so on. Some organizations include a category code, such as UC-ORD-001 for an order management use case. The identifier is not cosmetic; it is the anchor for traceability. When a developer implements a feature, they reference UC-012. When a tester writes a test case, they link it to UC-012. When a change request arrives, the team can immediately see which use cases are affected. Without unique identifiers, traceability collapses into a guessing game.

Use case names as verb phrases. The name of a use case should always be a short, purposeful verb phrase that captures the actor's goal. Good examples include Submit Order, Reset Password, Generate Monthly Sales Report, and Approve Leave Request. Poor names include Order Screen (names a screen, not a goal), Order Processing (vague and passive), or The User Does Something with the Cart (imprecise and not in phrase form). The verb-phrase convention keeps the team focused on outcomes rather than technology, and it makes a list of use cases readable as a catalog of system capabilities.

Uniform template application. Every use case in a project should be documented using the same template. This consistency is not bureaucratic rigidity — it is a practical necessity. When templates differ, reviewers must mentally re-orient with each document they open, and automated tools that parse use cases for requirements management cannot function reliably. Establish the template early, communicate it to all contributors, and enforce it in reviews. A minimal standard template typically includes fields for: identifier, name, description, actors, preconditions, main success scenario, alternative flows, exception flows, postconditions, and version history.

Version history and approval status. The document header should contain a version history table and an explicit approval status field. Version history allows the team to understand how the use case has evolved — critical when a late-breaking change is disputed and the team needs to know what was agreed to at project kickoff versus what was agreed to in sprint three. Approval status (Draft, Under Review, Approved, Deprecated) prevents a developer from implementing a scenario that is still being debated by stakeholders. The table below shows a typical header structure:

Field Example Value
Use Case ID UC-ORD-003
Use Case Name Submit Order
Author J. Morales
Date Created 2024-03-10
Last Updated 2024-04-02
Version 1.3
Status Approved
Approved By Product Owner — S. Chen

A version history section below the header would log each version with the date, the author, and a brief note describing what changed (for example, v1.2 — Added alternative flow A2 for guest checkout).

Writing the Main Success Scenario

The main success scenario (sometimes called the basic flow or happy path) describes the sequence of events that unfolds when everything goes as intended: the actor has the right permissions, the data is valid, the system is available, and the user achieves their goal. It is the spine of the use case; all alternative and exception flows branch from and return to it.

One discrete action or system response per step. Each numbered step must describe exactly one thing that happens. Compare these two approaches:

  • Weak: "The Customer logs in, navigates to the cart, reviews the items, and clicks Submit."
  • Strong: Step 3 — The Customer clicks the Submit Order button. Step 4 — The System validates the cart contents against current inventory. Step 5 — The System displays the order confirmation page with a unique order number.

The weak version bundles four distinct actions into one sentence. If step 3 fails during testing, testers cannot pinpoint which of the four actions failed. Atomic steps eliminate that ambiguity.

Active voice from the actor's or system's perspective. Every step should begin with the actor's name or the word "System" followed by a verb in the active, present tense. This convention makes it immediately clear who is responsible for each action. For example: "The Customer enters a shipping address in the Shipping Address field." Not: "A shipping address is entered." The passive voice obscures who acts, which matters enormously when the scenario is used to assign responsibilities or write tests.

Completeness for testability. A tester should be able to sit down with the main success scenario and verify each step independently. This means steps must be specific enough to be observable. "The System processes the payment" is not testable as written — a tester cannot observe "processes." Rewritten: "The System sends a charge request to the payment gateway and receives an approval response." Now the tester knows exactly what to look for in logs or on screen.

The final step confirms goal achievement. The last step of the main success scenario should always leave no doubt that the actor's goal has been fully achieved. For a Submit Order use case, an appropriate final step would be: "The System sends an order confirmation email to the Customer's registered email address." This closes the loop — the customer not only sees a confirmation on screen but receives durable proof of the transaction.

A condensed example of a main success scenario for Submit Order (UC-ORD-003) illustrates all four principles:

Main Success Scenario

1. The Customer clicks the "Proceed to Checkout" button from the Shopping Cart page.
2. The System displays the Checkout page pre-populated with the Customer's saved shipping address and default payment method.
3. The Customer reviews the order summary, shipping address, and payment details.
4. The Customer clicks the "Submit Order" button.
5. The System validates that all items in the cart are in stock.
6. The System submits a charge request to the Payment Gateway for the order total.
7. The Payment Gateway returns an approval code.
8. The System creates an order record in the database with status "Confirmed" and assigns a unique order number.
9. The System displays the Order Confirmation page showing the order number, itemized list, and estimated delivery date.
10. The System sends an order confirmation email to the Customer's registered email address.
    [Goal achieved: Customer has placed and received confirmation of a valid order.]

Documenting Alternative Flows

Alternative flows (also called alternative paths or extensions) represent choices or variations that are still valid and successful — they are not errors. They answer the question: "What if the user does something different, but still achieves a legitimate outcome?"

Different valid choices at a given step. An alternative flow always branches from a specific step in the main scenario. The reference must be explicit: "At step 3, if the Customer selects a different shipping address..." This anchoring prevents alternative flows from floating in isolation — a reader always knows exactly where in the main flow the variation occurs.

Indicating where the flow rejoins or diverges. Every alternative flow must specify two things: where it branches off and what happens afterward — specifically whether it rejoins the main scenario (and at which step), ends the use case with a different successful outcome, or leads into an exception flow. For example:

Alternative Flow A1: Customer uses a new shipping address

  Branches from: Step 3
  A1.1  The Customer clicks "Add New Address."
  A1.2  The System displays the Add Address form.
  A1.3  The Customer enters the new address details and clicks "Save."
  A1.4  The System validates the address format and saves the new address.
  A1.5  The System updates the Checkout page with the new address selected.
  Rejoins: Main flow at Step 3 (Customer continues reviewing checkout details).

Common types of alternative flows. Three categories of alternative flows appear repeatedly across use cases and deserve explicit attention:

  • Selecting different options: The user picks a non-default but equally valid choice, such as selecting a different payment method (credit card instead of saved PayPal account).
  • Using shortcuts: The user invokes a faster path to the same outcome, such as clicking a one-click purchase button that skips the checkout review page.
  • Canceling an action: The user deliberately abandons the current task. This is valid behavior and should be documented as an alternative flow, not an exception. The flow should confirm that the system returns the user to a stable, appropriate state and that no unintended changes are persisted.

Incorporating alternative flows from task analysis. During task analysis and stakeholder interviews, analysts discover many variations in how users approach a task. Each variation that represents a legitimate path to a valid outcome should be captured as an alternative flow. If a task analysis reveals that 30% of users access the checkout from a wish list rather than the main shopping cart, that is an alternative flow worth documenting. A systematic approach — cataloging all discovered variations, evaluating each as an alternative versus an exception, and assigning each a unique identifier (A1, A2, A3, etc.) — prevents flows from being overlooked and ensures completeness.

Documenting Exception Flows

Exception flows represent situations where something goes wrong — an error occurs, input is invalid, an external system fails, or the system reaches an unexpected state. Unlike alternative flows, exception flows are not the user choosing a different path; they are disruptions that must be handled gracefully.

Triggers for exception flows. An exception flow is triggered by one of three categories of problems:

  • Invalid input: The user enters data that fails validation (e.g., a malformed email address, a credit card number that fails the Luhn check).
  • System errors: An internal component fails (e.g., the database is unavailable, a timeout occurs during processing).
  • Unexpected states: The system discovers a condition it did not anticipate (e.g., an item that was in stock when added to the cart has since sold out).

Notifying the user of the problem. Every exception flow must describe exactly how the system communicates the problem to the user. Good exception handling is specific: the system must display a meaningful error message, not a generic "An error occurred." For example, if payment is declined, the message should indicate that payment was declined (without revealing security-sensitive details) and suggest what the user should do next. Vague error messages are a common complaint in usability studies and a direct symptom of poorly specified exception flows.

Recovery paths. Wherever the user can correct the problem and continue the main task, the exception flow must describe that recovery path explicitly. For example:

Exception Flow E2: Payment declined

  Triggered at: Step 6 (Payment Gateway returns a decline response)
  E2.1  The System displays a "Payment Declined" message on the Checkout page,
        advising the Customer to verify payment details or use a different method.
  E2.2  The System re-displays the Checkout page with the payment section highlighted.
  E2.3  The Customer updates payment details or selects a different payment method.
  Rejoins: Main flow at Step 4 (Customer clicks "Submit Order").

This recovery path means the user does not lose their cart contents or have to restart from the beginning — a critical usability and business requirement that would be missed if exception flows were undocumented.

Unrecoverable exceptions. Some exceptions cannot be resolved by the user during the session — for example, a complete database failure during order processing. For these cases, the exception flow must specify two things: how the system preserves any data the user has already provided (to avoid forcing them to re-enter everything if they try again), and how the system communicates the failure honestly. For example:

Exception Flow E4: System failure during order processing

  Triggered at: Step 8 (System fails to write order record to database)
  E4.1  The System rolls back the payment charge request to prevent billing without order creation.
  E4.2  The System logs the full error details to the system event log.
  E4.3  The System saves the Customer's cart contents to the session store for recovery.
  E4.4  The System displays a "Service Temporarily Unavailable" message with a reference number
        and instructs the Customer to try again in 10 minutes or contact support.
  [No rejoining of main flow; use case ends in failure state.]

Specifying rollback and data preservation in the exception flow is not just good UX practice — it is a direct requirement handed to developers about transactional integrity.

Specifying Preconditions and Postconditions

Preconditions and postconditions are the use case's contract with the world. They state what must be true for the scenario to begin and what will be true when it ends. Without them, use cases float in a context-free vacuum — testers cannot set up test environments correctly and developers cannot know what state the system must be in before their code runs.

Preconditions must be verifiable. A precondition is a statement about the state of the system and its actors that must be confirmed as true before the use case begins. The key word is verifiable: a precondition must be something a tester or the system itself can actually check. Compare:

  • Weak (vague): "The user is ready to order."
  • Strong (verifiable): "The Customer is authenticated. The Customer's shopping cart contains at least one item. All items in the cart have a current price in the product catalog."

The strong version gives developers and testers concrete, testable facts. Vague preconditions lead to misunderstandings about what the system is expected to handle versus what should be enforced upstream.

Postconditions for the main flow. The main success scenario's postcondition should state, in verifiable terms, what is true after the scenario completes successfully. For Submit Order: "An order record exists in the database with status 'Confirmed.' The Customer's cart is empty. A charge has been applied to the Customer's payment method for the order total. A confirmation email has been delivered to the Customer's registered address." Each clause is independently verifiable — a tester can check the database, inspect the cart, verify the charge, and confirm email delivery.

Postconditions for alternative flows. Alternative flows may end in states that differ from the main success postcondition. A Cancel Order alternative flow might have the postcondition: "The Customer's cart is preserved with its original contents. No charge has been applied. The Customer is on the Shopping Cart page." This is a valid and complete outcome, just different from the full success state. Documenting it explicitly prevents a tester from incorrectly marking a cancelled-order scenario as a failure because the order record was not created.

Direct usability as test case inputs. Well-written preconditions and postconditions transform use cases into test case templates almost automatically. The precondition becomes the test setup. The main flow steps become the test actions. The postcondition becomes the pass/fail criteria. This tight mapping between use case documentation and testing is one of the primary reasons rigorous pre/postcondition specification pays off in reduced testing effort and fewer defects.

Use Case Element Maps to Test Case Element
Preconditions Test setup / environment conditions
Main scenario steps Test steps / actions
Main postconditions Expected results / pass criteria
Alternative flow steps Alternative test path actions
Alternative postconditions Expected results for alternative paths
Exception flow triggers Negative test conditions
Exception flow outcomes Expected error handling / recovery results

Writing Clear and Unambiguous Steps

Even a perfectly structured use case can fail in practice if its steps are written unclearly. Ambiguous steps are a leading cause of misalignment between what stakeholders intended, what developers built, and what testers verified. The following principles, applied consistently, eliminate the most common sources of ambiguity.

Use specific verbs, not vague ones. Words like "handles," "manages," "processes," and "deals with" tell the reader almost nothing about what concretely happens. Replace them with verbs that describe observable, specific actions:

  • Instead of "The System processes the form," write "The System validates each required field for correct format and completeness."
  • Instead of "The User interacts with the cart," write "The Customer clicks the Remove button next to the selected item."
  • Preferred specific verbs include: clicks, enters, selects, displays, submits, navigates to, highlights, enables, disables, saves, redirects, sends, receives, validates, calculates.

Name the actor explicitly. Pronouns introduce ambiguity as soon as a use case involves more than one actor. In a system where a Customer, a Store Manager, and an automated Notification Service all participate, a step that reads "They confirm the change" is genuinely unclear. Always name the actor: "The Store Manager clicks the Confirm button." This applies to the system as well — write "The System" rather than "it."

One action per step, not compound sequences. Compound steps — those that describe two or more actions joined by "and" or "then" — violate the atomicity principle. If one action in a compound step fails, it is impossible to know precisely where the failure occurred. Consider:

  • Compound (avoid): "The Customer enters a username and password and clicks Login."
  • Atomic (preferred): Step 1 — The Customer enters a username in the Username field. Step 2 — The Customer enters a password in the Password field. Step 3 — The Customer clicks the Login button.

The atomic version looks more verbose, but it is far more useful during testing, debugging, and UI design — each interaction with the interface is separately accountable.

Managing technical jargon. Use cases are shared documents — read by developers, but also by product owners, business stakeholders, and QA teams with varying technical backgrounds. Technical terms should be used only when they add precision that everyday language cannot provide, and only if they are defined in a project glossary. For example, "The System executes a RESTful POST request to the payment endpoint" may be appropriate in a developer-facing specification, but in a use case reviewed by the Finance department, "The System submits the payment details to the payment service" conveys the same intent with far less confusion. Establishing and linking to a project glossary lets analysts use necessary technical terms without alienating non-technical readers.

The table below summarizes common step-writing pitfalls and their corrections:

Pitfall Example of the Problem Corrected Version
Vague verb The System handles the request. The System validates the request parameters and returns an HTTP 200 response.
Pronoun instead of actor name They click Submit. The Customer clicks the Submit button.
Compound step The Customer fills in the form and submits it. Step 4: The Customer completes all required fields. Step 5: The Customer clicks Submit.
Passive voice obscuring actor The order is confirmed. The System displays an order confirmation message to the Customer.
Undefined jargon The System fires a webhook. The System sends an automated notification to the fulfillment service. [If "webhook" is in the glossary, it may be used as a parenthetical clarification.]
Non-verifiable step The System processes the payment quickly. The System submits the charge request and receives a response within 5 seconds.

Taken together, these principles — structural rigor, a complete main scenario, systematically documented alternative and exception flows, verifiable pre/postconditions, and precise step writing — produce use case scenarios that serve every audience on a project. Developers get unambiguous implementation targets. Testers get ready-made test blueprints. Stakeholders get a readable narrative of system behavior they can validate against their real-world needs. And the organization gets a traceable, maintainable requirements artifact that can survive the inevitable changes of any project lifecycle.

NotesStudents should practice writing a complete use case scenario from scratch using a provided template. A good exercise is to take a familiar task (such as resetting a password or booking a meeting room) and draft all six components: header with identifier and version history, main success scenario, at least two alternative flows, at least two exception flows (one recoverable, one not), and explicit pre/postconditions. Peer review sessions should focus on checking for vague verbs, compound steps, and unverifiable conditions.
2

Videos on This Topic

▶

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.

3

Video 1: Use Case Description EXAMPLE [ Use Case Tutorial and Best Practices ]

▶

The Business Analysis Doctor - IIBA Certification · 18:22 · 40,283 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: Use Case Diagram Tutorial and EXAMPLE ( How to Draw Use Case Diagram )

▶

The Business Analysis Doctor - IIBA Certification · 13:14 · 29,893 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: 5 Effective Types of Requirements Documentation for Business Analysts

▶

Bridging the Gap - Resources for Business Analysts · 14:21 · 13,532 views · 3y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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).

7

About These Videos

▶

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.

Enumerating Usage Paths and Edge Cases

1

Enumerating Usage Paths and Edge Cases

▶

When designing systems, applications, or services, it is tempting to focus exclusively on the smooth, idealized path a user takes to accomplish a goal — often called the "happy path." However, real-world usage is rarely so tidy. Users make unexpected choices, enter unexpected data, operate under unexpected conditions, and arrive at the system with varying levels of experience, ability, and context. A comprehensive use case set must account for this full spectrum of usage, from the most routine workflow to the rarest boundary condition. This is the discipline of enumerating usage paths and edge cases: systematically identifying, documenting, and prioritizing every meaningful scenario the system must handle, not just the ones that feel comfortable or obvious.

Thorough enumeration serves multiple stakeholder groups simultaneously. Designers use it to ensure no user is left without a viable path. Developers use it to write code that handles all permitted inputs and states without crashing or producing incorrect results. Testers use it to construct test cases that exercise the system's boundaries. Product owners use it to make informed prioritization decisions. When edge cases are discovered late — during testing, in production, or after a user complaint — the cost of remediation rises dramatically. The goal of this discipline is to surface those scenarios early, when they are cheapest to address.

What Are Edge Cases?

An edge case is a scenario that occurs at the extreme end of a parameter's range, at the boundary between two system states, or at the intersection of two or more unusual but valid conditions. The term "edge" is borrowed from mathematics, where the edge of a domain is the region near its boundary. In system design, edge cases are not necessarily rare in the sense of being theoretically unlikely — some occur frequently in practice — but they are distinct from the central, well-understood scenarios that drive the initial design.

One of the most common categories of edge case involves boundary conditions. Every system parameter that accepts a numeric, textual, or temporal value has an implicit or explicit range. A username field might accept between 3 and 64 characters. A financial transaction amount might have a minimum of $0.01 and a maximum determined by account balance or regulatory limit. An age field might require a value of 0 or greater and 150 or less. The boundary values themselves — the minimum, the maximum, and values immediately above and below those limits — are precisely where software defects most frequently appear. A system that correctly handles 63-character usernames may fail on a 64-character one because a developer inadvertently used a strictly-less-than comparison instead of less-than-or-equal. Designing and testing at these boundaries, rather than only in the comfortable middle of the range, catches these defects early.

A second category involves unusual but permitted combinations of user choices or system states. Consider an e-commerce checkout flow. Most users add items, enter a shipping address, enter payment information, and confirm. But what happens when a user applies a discount code that reduces the total to exactly zero? What happens when a user's session expires midway through checkout? What if a user has two browser tabs open simultaneously, adds different items in each, and submits both? Each of these is an edge case: unusual, but not impossible, and potentially not prohibited by business rules. Systems that are not designed to handle these combinations either crash, produce incorrect results, or leave the user stranded without a recovery path. These outcomes damage trust and, in the case of financial or safety-critical systems, can cause real harm.

A third important characteristic of edge cases is that unintentionally unaddressed edge cases are handled inconsistently. When a development team has not explicitly discussed what should happen when a user submits an empty required field with only whitespace characters, different developers on different screens will make different decisions. One might trim and reject; another might pass the whitespace to the database; a third might raise an unhandled exception. This inconsistency is not just an aesthetic problem — it is a functional and security problem. Attackers specifically probe for the edge cases that developers forgot to handle, because those are the places where unexpected behavior can be exploited.

The most reliable sources for identifying real-world edge cases are user research and task analysis. Observational research — watching real users attempt real tasks — consistently surfaces behaviors that analysts did not anticipate. Users paste content from other applications, causing encoding edge cases. They use the Tab key instead of clicking, revealing focus-order defects. They leave forms open for hours before submitting, triggering session timeout edge cases. Task analysis, which decomposes a goal into its constituent steps and decision points, provides a structured way to ask at every branch: "What if the user does not have the information required here? What if the data entered is valid but unusual? What if the system is in an unexpected state at this point?" These questions, applied systematically, generate a rich catalog of edge cases before a single line of code is written.

Techniques for Enumerating Usage Paths

Identifying edge cases informally — by brainstorming or relying on the imagination of a single analyst — produces incomplete results. Structured techniques provide a repeatable, comprehensive approach to enumerating the full set of usage paths a system must support.

Flow analysis begins with a task model or activity diagram that maps every step a user takes to accomplish a goal, including every decision point and every branch. The analyst traces each branch systematically, asking whether it has been captured as a use case. In a simple login flow, the main path is: enter credentials, submit, authenticate successfully, land on home screen. But flow analysis surfaces additional paths: what if authentication fails once? What if it fails three times and the account is locked? What if the user clicks "forgot password" instead? What if the user's account is inactive? What if the system's authentication service is unavailable? Each branch represents a distinct usage path that requires a design decision and, ultimately, an implementation. Flow analysis ensures that no branch is left unmapped.

Boundary value analysis is a formal technique derived from software testing practice and applied here at the requirements stage. For every input parameter, the analyst identifies the minimum acceptable value, the maximum acceptable value, and the values immediately outside those limits. These five points — minimum, minimum plus one, a nominal middle value, maximum minus one, and maximum — are the most informative test points and, by extension, the most important design points. If a text field accepts up to 255 characters, the system must be designed to handle exactly 255 characters correctly, to reject 256 characters with a clear error message, and to handle the empty string appropriately. Applying boundary value analysis to every parameter in a system generates a comprehensive list of boundary edge cases that can be directly mapped to use cases and test cases.

Negative testing considers what users might attempt that the system should reject or handle gracefully. This is distinct from boundary value analysis because it addresses not just out-of-range numeric values but also qualitatively wrong inputs: a letter where a number is expected, a date that does not exist on the calendar (such as February 30), a file of the wrong type uploaded to a form that expects images, an SQL injection attempt in a name field, an extremely long string intended to overflow a buffer. Negative testing also covers behavioral negatives: what if a user navigates backward through a multi-step form after completing payment? What if a user bookmarks a page that requires a logged-in session and returns to it days later? What if a user submits a form twice in rapid succession by double-clicking the submit button? Each of these is a usage path the system must handle, even though it represents a deviation from intended behavior.

Scenario-based reviews with diverse stakeholders complement analytical techniques by introducing perspectives that analysts may lack. A customer service representative who handles escalations daily knows which edge cases cause the most user confusion. A compliance officer knows which regulatory scenarios must be handled correctly even if they are rare. A database administrator knows which data states are technically possible even if the application tries to prevent them. An accessibility specialist knows which interaction patterns break down for users of assistive technology. Structured workshops in which stakeholders are asked to walk through the system's task models and challenge assumptions about what users will do, what data will be entered, and what system states will occur, consistently produce edge cases that no individual analyst would have identified alone.

User Diversity and Context Variation

A single system is used by a population of users who differ from each other in ways that create distinct usage paths. Treating the user as a homogeneous actor is one of the most common sources of incomplete use case sets.

New and experienced users often follow fundamentally different paths to accomplish the same goal. An experienced user of a content management system may navigate directly to a specific configuration panel using a keyboard shortcut they memorized. A new user may search for the same function using a help feature, attempt to find it through the navigation menu, and ultimately reach it via a different route. Both are valid paths. The system must support both, and the design of each path must be appropriate for the likely user at that point. Onboarding flows, contextual help, and progressive disclosure are design patterns that serve new users; power-user shortcuts and batch operations serve experienced users. Use cases must explicitly represent these divergent paths rather than assuming a single user model.

Accessibility requirements create additional distinct flows that must be enumerated explicitly. A user who navigates entirely by keyboard follows a different sequence of interactions than a mouse user: they Tab through controls in a defined order, use Enter or Space to activate buttons, and use arrow keys to select from menus. A user of a screen reader interacts with the system's accessibility tree, which may present information in a different order than the visual layout. A user with a motor impairment may use a switch control that activates elements sequentially. Each of these interaction modalities creates a distinct usage path through every task in the system. If these paths are not explicitly documented as use cases and reviewed for correctness, they will be overlooked during design and testing, and the resulting system will be inaccessible to users who depend on those modalities.

Device and connectivity constraints create conditional flows that must be designed for explicitly. A user completing a multi-step insurance claim on a mobile device with an intermittent cellular connection may lose connectivity midway through. The system must have a defined path for this scenario: does it save progress automatically? Does it present a clear error message with a retry option? Does it prevent the user from submitting duplicate data when connectivity is restored? A user on a low-powered device may experience timeouts or rendering failures that a high-powered desktop user would never encounter. These are not hypothetical: mobile users frequently experience interrupted connectivity, and designing for this context is not optional if the system is intended to serve mobile users.

Cultural and localization differences affect usage paths in ways that are easy to overlook if the design team operates from a single cultural context. Date formats vary: in the United States, 04/05/2024 means April 5, while in the United Kingdom it means May 4. Numeric formats vary: in Germany, 1.000,00 represents one thousand, while in the United States the same value is written 1,000.00. Names vary: some cultures use a single name, some use names with special characters, some use names that are very long by Western standards. Address formats vary: not all countries have states, postal codes, or the same concept of a street address. Error messages and instructions written in idiomatic English may be confusing or offensive when translated literally. Each of these variations creates usage paths that must be tested and validated, and the failure to account for them produces systems that work correctly only for users from the same cultural context as the design team.

Documenting Frequency and Priority

Once a comprehensive set of usage paths has been enumerated, the team must make decisions about which paths to invest in most heavily. Not all use cases deserve equal design and testing effort. A structured approach to documenting frequency and priority ensures that effort is allocated rationally rather than arbitrarily.

High-frequency use cases — those that the majority of users will encounter on most sessions — warrant the most design iteration, the most usability testing, and the most performance optimization. The login flow, the primary search function, the main content creation or data entry screen: these paths are traversed millions of times in the lifetime of a deployed system. Even a small usability friction in a high-frequency path compounds into an enormous cumulative cost in user effort and abandonment. Design teams should spend more time on these paths, test them with larger and more diverse user samples, and revisit them more frequently as the system evolves.

Low-frequency but high-consequence use cases require equal rigor for entirely different reasons. An emergency shutdown procedure for an industrial control system may be executed once a year, but when it is executed, it must work correctly the first time under conditions of stress and urgency. A data export function used only for regulatory audits may be needed once per quarter, but an error in that export could result in a compliance violation. A password reset flow may be needed by only a small fraction of users on any given day, but for the user who cannot access their account, it is the only thing that matters. These paths must be designed carefully, tested thoroughly, and documented clearly even if they will not receive the most user testing sessions or design iterations in absolute terms.

Priority ratings must be agreed upon by stakeholders, not assigned unilaterally by analysts. An analyst may assess a use case as low priority based on estimated frequency, while a compliance officer knows it is critical for regulatory reasons, a customer service manager knows it generates the most support calls, and a security engineer knows it is a common attack vector. Priority is an inherently multidimensional judgment that requires input from people with different perspectives and accountabilities. A structured prioritization workshop — using a technique such as a weighted scoring matrix or a MoSCoW classification — produces priority ratings that reflect the organization's actual values and constraints rather than a single individual's assumptions.

The following table illustrates how frequency and consequence combine to influence priority classification for a set of example use cases:

Use Case Frequency Consequence of Failure Recommended Priority
User login Very high — every session High — blocks all access Critical
Password reset Low — only when locked out High — user cannot proceed High
Profile photo upload Low — once per user Low — cosmetic only Medium
Emergency data export Very low — quarterly or less Very high — regulatory violation Critical
Bulk record import Medium — periodic by admins High — data integrity risk High
Theme color preference Very low — once per user Very low — aesthetic only Low

Frequency and priority metadata recorded alongside each use case become invaluable when scope must be constrained. In every real project, requirements eventually exceed available time and resources. When that happens, the team must make cuts. Having explicit, stakeholder-agreed priority ratings and frequency estimates means those decisions can be made on the basis of evidence rather than the loudest voice in the room or the personal preferences of whoever controls the backlog. A low-frequency, low-consequence use case can be deferred to a later release with confidence; a low-frequency, high-consequence use case cannot.

Reviewing for Completeness

Enumerating usage paths is not a one-time activity completed at the beginning of a project. Requirements change, new actors are identified, integrations introduce new states, and user research surfaces unexpected behaviors. A systematic approach to reviewing the use case set for completeness must be built into the project's ongoing processes.

Actor-to-use-case matrices are among the most effective tools for visualizing coverage. An actor is any entity — human user, external system, automated process — that interacts with the system. A matrix lists all actors along one axis and all use cases along the other, with a mark at each intersection where an actor participates in a use case. This visualization immediately reveals actors that participate in only one or two use cases, which may indicate that important scenarios for those actors have not been identified. It also reveals use cases with no actor, which indicates an orphaned requirement. Constructing and reviewing this matrix at regular intervals keeps coverage visible to the whole team.

The following is an example of a simplified actor-to-use-case coverage matrix:

Use Case Registered User Guest User Administrator External Payment System
Browse product catalog ✓ ✓
Add item to cart ✓ ✓
Complete checkout ✓ ✓
Manage user accounts ✓
View order history ✓ ✓
Process refund ✓ ✓

In this matrix, the Guest User column contains only two marks. A reviewer should ask: can guest users view their order history after creating an account? Can they retrieve a cart they started as a guest? Are there error scenarios specific to guest users that have not been documented? The matrix prompts these questions in a way that an unstructured review might not.

Goal-to-use-case traceability ensures that every stakeholder need — every business goal, user goal, or system quality requirement — is addressed by at least one use case. Traceability is typically maintained in a requirements traceability matrix that links each high-level goal to the use cases that address it, and each use case to the test cases that verify it. A goal with no corresponding use case is a gap in the design. A use case with no corresponding goal is potentially scope creep — work being done that does not serve an identified need. Regular review of the traceability matrix catches both types of misalignment.

Peer reviews by developers and testers bring technical perspectives that business analysts and designers may lack. A developer who has implemented similar functionality before will recognize technical edge cases — race conditions, transaction rollback scenarios, cache invalidation states — that do not appear in business-focused analysis. A tester who has written test cases for similar systems will ask about equivalence classes and boundary conditions that the use case documentation has not addressed. Formally scheduling peer reviews of use case documentation — not just reviews of code or test plans — integrates these perspectives at the point where they can most efficiently influence the design.

Iterative reviews must be scheduled as a standing activity, not a one-time gate. When a new requirement is added, the analyst should ask: does this requirement create new actors, new paths, new boundary conditions, or new combinations of state that are not covered by existing use cases? When an existing requirement changes, the analyst should ask: does this change invalidate any existing use case, create a new edge case at the boundary between the old and new behavior, or affect any other use case through shared state or shared components? A project that reviews its use case set only at the beginning of analysis will find, at the end of implementation, that the set is riddled with gaps created by the changes that occurred in between. Building review into the rhythm of the project — at the end of each sprint, at each major requirement change, at each new round of user research — keeps the use case set accurate and complete throughout the project's life.

The discipline of enumerating usage paths and edge cases is ultimately an act of intellectual humility: an acknowledgment that no individual analyst, designer, or developer can anticipate everything that real users will do in real contexts. By applying structured techniques, incorporating diverse perspectives, documenting frequency and consequence, and reviewing iteratively, teams build use case sets that are comprehensive enough to guide the design and implementation of systems that work correctly not just for the idealized user on the happy path, but for every user the system is meant to serve.

NotesInstructors may wish to supplement this topic with a hands-on workshop exercise in which students take a provided task model for a simple system (e.g., a library book reservation application) and apply each enumeration technique in sequence, comparing the edge cases surfaced by each method. The actor-to-use-case matrix and goal-to-use-case traceability sections pair well with structured lab activities using a shared spreadsheet or requirements management tool. Emphasize that completeness is a process discipline, not a one-time deliverable.
2

Videos on This Topic

▶

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.

3

Video 1: Why Edge Cases are Important in UX | Google UX Design Certificate

▶

Grow with Google · 3:06 · 3,588 views · 5y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: Functional vs Non-functional Requirements | Requirement Engineering | Software Engineering

▶

Gate Smashers · 5:03 · 844,915 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: UML use case diagrams: Everything you need to know

▶

Lucid Software · 12:42 · 1,027,119 views · 3y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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.

7

About These Videos

▶

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.

Documenting and Communicating Requirements

1

Documenting and Communicating Requirements

▶

Well-written use cases represent a significant investment of time, thought, and collaboration. Yet that investment pays dividends only when the resulting documents are organized so people can find what they need, communicated in ways that different audiences can absorb, kept accurate as the project evolves, and actively used to drive the design and testing work that follows. This topic covers the full lifecycle of use case documentation — from setting up a repository to feeding finished use cases into interface design and acceptance testing.

Think of a use case repository, a traceability matrix, a stakeholder walkthrough, and a change log not as bureaucratic overhead but as the connective tissue that holds a project together. Without them, even the most carefully written use case becomes an island: disconnected from the business goal that motivated it, invisible to the developer building the feature, and unverifiable by the tester who must confirm the system works.

Organizing a Use Case Repository

A use case repository is the single authoritative location — a wiki, a requirements management tool, a shared document library, or a version-controlled folder — where all use case documents live. The first and most consequential organizational decision is how to group them. Three common schemes each serve different project needs:

  • By actor: All use cases initiated by the Customer are grouped together, all use cases initiated by the Administrator are grouped together, and so on. This scheme is intuitive when the project is primarily concerned with distinct user populations and their journeys through the system. A product owner responsible for the customer experience can navigate directly to every scenario that affects their users.
  • By functional area: Use cases for Order Management sit in one folder, use cases for Inventory sit in another, and use cases for Reporting sit in a third. This mirrors how business domains are often organized and makes it easy for subject-matter experts who own a domain to review everything relevant to them at once.
  • By system module: Use cases are grouped according to the software component or microservice that implements them — Payment Service, Notification Engine, User Profile Service. This scheme is most useful in technical reviews and during implementation, because a developer assigned to a module can quickly locate every use case that governs its behavior.

In practice, many projects use a hybrid: a primary grouping by functional area, with tags or cross-reference links by actor and by module. What matters most is that the scheme is consistent and documented so that every new use case has an obvious, agreed-upon home.

A naming and numbering convention is equally important. A use case named "UC-ORD-007: Place Order" communicates the functional area (ORD = Orders), a unique sequence number, and a descriptive title in a single identifier. This identifier appears in design documents, test plans, defect tickets, and meeting notes, allowing anyone reading any artifact to trace it back to the governing use case without ambiguity. Without a consistent scheme, references accumulate — "the checkout use case," "the order placement scenario," "UC12," "Order Flow v2" — and traceability collapses.

Version control for use cases is not optional on any project of meaningful size. Requirements evolve; use cases approved in iteration one will be revised by iteration three. Version control — whether provided by a dedicated requirements tool like Jama or Doors, a wiki with page history, or a Git repository — ensures that:

  • Every change is recorded with a timestamp and the name of the person who made it.
  • Previous versions remain recoverable, which is essential when a change introduces problems and the team must understand what was agreed earlier.
  • Two people cannot silently overwrite each other's edits.
  • Released or baselined versions of use cases can be clearly distinguished from drafts under active revision.

Finally, access permissions must be configured deliberately. Business stakeholders, developers, testers, and project managers all need read access so they can consult use cases at any time. But write access — the ability to change an approved use case — should be restricted to authorized roles such as the business analyst or requirements lead. This prevents well-intentioned but uncoordinated edits from corrupting the baseline. Stakeholders who want a change should submit it through the change request process described later in this topic; they should not edit the document directly.

Traceability Between Requirements and Use Cases

Traceability is the ability to follow a requirement forward through design and implementation, and backward from a test case to the need that motivated the feature. It answers two of the most important questions in software development: "Does everything we are building trace back to a genuine stakeholder need?" and "Is every stakeholder need covered by something we are building and testing?"

Backward traceability — also called upstream traceability — links each use case to the source requirement, stakeholder need, or business goal that motivated it. For example:

  • Business Goal BG-04: Reduce customer abandonment at checkout → Stakeholder Need SN-12: Allow customers to save a cart and return later → Use Case UC-ORD-007: Place Order (including the alternative flow for resuming a saved cart).

This chain proves that UC-ORD-007 exists for a documented reason. It also means that if BG-04 is deprioritized or removed, the team can immediately identify which use cases are affected and decide whether to keep, revise, or retire them.

Forward traceability — also called downstream traceability — links use cases to the design elements and implementation tasks derived from them. A use case step sequence might link to a wireframe, an API endpoint specification, a database schema change, and a sprint backlog item. This chain proves that every requirement has been addressed in design and implementation. It also enables impact analysis: if a use case changes, forward traceability immediately reveals which wireframes must be revised, which API contracts are affected, and which sprint tasks must be revisited.

Test traceability links test cases back to the use cases they verify. UC-ORD-007 might link to ten test cases: one for the main success scenario, one for each alternative flow, and one for each exception flow. This linkage serves two purposes: it ensures that every path through a use case is tested (coverage), and it allows the team to quickly identify which tests must be re-run when a use case changes (regression scope).

The mechanism for recording all of this is the traceability matrix — a table that maps identifiers across levels. A simple version might look like this:

Business Goal Stakeholder Need Use Case Design Artifact Test Case(s)
BG-04 SN-12 UC-ORD-007 WF-014, API-ORD-03 TC-087, TC-088, TC-089
BG-01 SN-03 UC-AUTH-002 WF-002, API-AUTH-01 TC-010, TC-011
BG-07 SN-19 UC-RPT-005 WF-031, DB-RPT-02 TC-102, TC-103, TC-104

The matrix is a living artifact. Whenever a use case is added, revised, or retired — or whenever a new design artifact or test case is created — the matrix must be updated. On larger projects this is maintained in a requirements management tool that generates the matrix automatically from linked records. On smaller projects a spreadsheet can suffice, provided someone is explicitly responsible for keeping it current.

Communicating Use Cases to Stakeholders

Use cases are authored by analysts but consumed by a wide range of people: executives evaluating scope, developers interpreting requirements, testers designing test scenarios, and business domain experts validating correctness. A single communication format does not serve all of these audiences equally well. Effective communication means tailoring the presentation to the audience without creating multiple competing versions of the truth.

Executive summaries give business stakeholders a high-level view of what the system will and will not do. An executive summary of use case coverage might list each functional area, the number of use cases in it, the actors involved, and a one-sentence description of the primary goal. Executives do not need to read step-by-step flows; they need to answer questions like "Does this system handle our B2B customers differently from our B2C customers?" and "Are returns and refunds in scope for this release?" A coverage summary lets them answer those questions without wading through technical detail.

Use case diagrams (from the UML standard) are the standard visual tool for high-level communication. A use case diagram shows actors as stick figures on the left and right of the diagram, the system boundary as a rectangle, and use cases as ovals within the boundary, with lines (associations) connecting actors to the use cases they participate in. The diagram does not describe how anything works; it shows who does what at a glance. For a business stakeholder unfamiliar with structured requirements documents, a well-drawn use case diagram is often the most productive starting point for a conversation about scope. It answers the question "Is this what we agreed to build?" before anyone has to read a single numbered step.

Walkthroughs — sometimes called structured walkthroughs or scenario walkthroughs — are facilitated sessions in which the analyst guides stakeholders through a use case step by step, asking them to imagine performing each action and to flag anything that does not match their mental model of the process. Walkthroughs are substantially more effective than asking stakeholders to read and comment on documents independently, for several reasons:

  • Reading a document is a passive activity; walking through a scenario engages the stakeholder's procedural memory and surfaces tacit knowledge ("Oh, but what happens if the customer has a store credit? We always apply that first").
  • Misunderstandings surface in real time and can be resolved on the spot rather than accumulating as written comments that require additional clarification rounds.
  • Stakeholders who would never find time to read a forty-page requirements document will often spend ninety minutes in a walkthrough session.

Walkthroughs should be structured: the analyst explains the preconditions, reads or paraphrases each step, pauses for questions, and explicitly asks about alternative and exception flows ("What if the payment is declined? What if the customer enters an invalid address?"). Notes taken during the walkthrough feed directly into the next revision of the use case.

Technical audiences — developers, architects, database engineers, testers — need the full detailed specification. This means the complete step-by-step main flow, every alternative flow numbered and labeled, every exception flow with its trigger and system response, all preconditions and postconditions, business rules referenced by identifier, and any supplemental notes about data constraints or integration points. Providing technical audiences with only an executive summary or a use case diagram and expecting them to fill in the details themselves is a common and costly mistake. The details are exactly what they need, and when those details are absent, developers invent them — often incorrectly.

Maintaining Use Cases Through Change

Requirements change. This is not a failure of planning; it is the normal trajectory of a project as stakeholders learn more about what the system can and should do. The goal is not to prevent change but to manage it in a controlled way so that the team always shares a single, current, accurate understanding of what is being built.

A formal change request process is the foundation of controlled change. Any stakeholder — business owner, developer, tester, or analyst — who believes a use case needs to change submits a change request that describes the proposed change, the reason for it, and the requestor's name and date. The change request is reviewed (typically by a change control board or its lightweight equivalent: the project manager, lead analyst, and a business representative) who decide to approve, reject, or defer it. Only approved changes are incorporated into the baseline use cases. This process prevents the repository from being silently edited by anyone with a browser and a strong opinion, and it creates an auditable record of every decision made about scope.

Impact analysis is performed before a change is approved. The analyst examines the traceability matrix and asks: if this use case changes, what else is affected? A change to UC-ORD-007 might affect the wireframe for the checkout screen, the API contract for the order submission endpoint, three test cases, and — if the change touches shared business rules — two other use cases that reference the same rule. Impact analysis prevents the team from approving a seemingly small change without realizing that it requires rework across a dozen downstream artifacts. The output of impact analysis is an estimate of the effort required to implement the change consistently, which informs the approval decision.

Once a change is approved and incorporated, the updated use case must be re-reviewed and re-approved by the stakeholders who originally approved it. This step is sometimes skipped under time pressure, and it is almost always regretted: a change that seemed unambiguous in a change request form often turns out, when written into the actual step sequence, to have implications that the approver did not anticipate. Re-approval closes the loop and ensures that the signed-off use case actually says what the stakeholder intended.

Each use case document should contain a changelog — a table at the beginning or end of the document that records every version, the date it was created, the name of the person who made the change, and a brief description of what changed. For example:

Version Date Author Description of Change
1.0 2024-02-10 A. Reyes Initial approved version.
1.1 2024-03-05 A. Reyes Added alternative flow 3a: Apply store credit. Per CR-047.
1.2 2024-04-18 M. Okafor Revised postcondition to reflect new order confirmation email requirement. Per CR-061.

The changelog means that anyone reading the use case can immediately see its history without digging through a version control log. It also provides the audit trail that is often required for compliance, contractual, or regulatory reasons.

Use Cases as Input to Design and Testing

A use case is not just a requirements document; it is a specification for behavior that directly drives two downstream activities: interface design and testing. Making this connection explicit — and involving designers and testers early — dramatically improves the quality of both the use cases and the artifacts derived from them.

Each flow maps to at least one design scenario. The main success scenario of UC-ORD-007 describes the happy path: the customer selects items, provides a valid address, enters valid payment information, and the system confirms the order. This scenario maps directly to the primary wireframe or prototype screen for the checkout flow. Alternative flow 3a — applying store credit — maps to a design variation showing the store credit deduction in the order summary. The designer who is handed a fully written use case with all its flows has a checklist of scenarios the interface must support; gaps in the use case become gaps in the interface design.

Exception flows identify error states the interface must address. Exception flow 4b — "Payment authorization fails" — is not a nice-to-have edge case; it is a scenario that will occur for a meaningful percentage of real users. The use case specifies that the system should display an error message and allow the customer to re-enter payment details. The designer must therefore design that error state: what does the message say? Where does it appear? Which fields are cleared and which are retained? Without the exception flow documented in the use case, the error state is easily overlooked in interface design, and the first time it is noticed is when a tester or — worse — a real customer encounters it.

Acceptance test cases can be derived directly from use case flows. Each step sequence in a use case, combined with its preconditions and postconditions, contains almost everything needed to write an acceptance test case. Consider a simplified use case excerpt:

Precondition: Customer is logged in. Cart contains at least one item.
Main Flow:
  Step 1. Customer navigates to checkout.
  Step 2. System displays order summary with items, subtotal, and delivery options.
  Step 3. Customer selects a delivery option.
  Step 4. Customer enters a valid delivery address.
  Step 5. Customer enters valid payment details.
  Step 6. Customer confirms the order.
  Step 7. System processes payment and creates an order record.
  Step 8. System displays an order confirmation page with a unique order number.
Postcondition: Order record exists in system with status "Confirmed." 
               Confirmation email sent to customer.

From this, a tester can immediately derive a test case: set up a logged-in customer account with a cart containing one item; execute steps 1 through 6; verify that step 7 creates an order record and step 8 displays an order number; verify the postconditions by checking the database and the email log. Every alternative flow and exception flow generates an additional test case in the same way. A project that maintains well-written use cases with complete flows effectively has a first draft of its acceptance test suite embedded in its requirements documentation.

Early involvement of designers and testers in use case review pays compounding returns. When a designer reviews a use case before it is baselined, they ask questions like: "In exception flow 4b, you say 'display an error message' — what information should that message contain? Should the customer be able to save their cart at that point?" These questions improve the use case before it is approved. When a tester reviews a use case before it is baselined, they ask: "How will we verify the postcondition that the confirmation email was sent? Is there a test email environment available?" These questions surface infrastructure and environment requirements that would otherwise be discovered mid-sprint. The cost of revising a use case before approval is negligible; the cost of the same revision after design and implementation have begun is far higher. Early cross-functional review of use cases is one of the highest-return practices in requirements management.

NotesThe topic integrates all four subtopic clusters — repository organization, traceability, stakeholder communication, change management, and design/testing input — into a single cohesive narrative. The two HTML tables (traceability matrix and changelog) illustrate concepts that benefit from tabular presentation. The code block demonstrates how a concrete use case excerpt maps to derived test cases, grounding the abstract principle in a tangible example.
2

Videos on This Topic

▶

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.

3

Video 1: Software Requirements Specification (SRS) | Software Engineering

▶

Gate Smashers · 9:36 · 1,061,702 views · 4y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

4

Video 2: Collaborating With Stakeholders

▶

NNgroup · 4:10 · 15,246 views · 5y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

5

Video 3: Three Ways to Analyze Requirements Traceability in MATLAB

▶

MATLAB · 4:32 · 1,311 views · 2y ago · captions — Watch on YouTube

About this video

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.

Why this video

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.

6

How These Videos Support the Learning Outcomes

▶

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.

7

About These Videos

▶

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.