What is a use case? Definition, examples and diagrams

TL;DR — Use cases in 30 seconds

A use case is a description of how a user (called an “actor”) interacts with a system to achieve a specific goal. Use cases capture functional requirements as sequences of steps showing the user-system interaction, including main flow, alternate flows, and exception handling. Standard structure: actor → preconditions → main flow (numbered steps) → alternate flows → postconditions → business rules. Notation: UML use case diagrams (ovals connected to stick figures via lines) plus written use case specifications. Use case vs user story: use cases are detailed and complete (full interaction flow), while user stories are short and focused on user value (“As a user, I want X so that Y”). Most modern teams use both — user stories for backlog grooming, use cases for detailed requirements analysis on complex features. Tools: Visual Paradigm, Lucidchart, draw.io, Enterprise Architect. Common applications: requirements engineering, system design, test case derivation, stakeholder communication.

Definition of Use Cases

A use case is a structured description of an interaction between a user or external system (an actor) and an information system to achieve a specific goal. It shows how the system should respond to the actor, from the actor’s perspective, and is a key element of systems analysis and requirements engineering.

The technique was introduced by Ivar Jacobson and spread through object-oriented methods in the 1990s; it has since become a foundational component of requirements engineering. They bridge the gap between business requirements and technical implementation by describing desired system behavior in a format that is understandable to all parties involved. Unlike purely technical specifications, use cases employ natural language that can be understood by both domain experts and developers.

History of Use Cases

Ivar Jacobson began developing the use case concept while working on telecom systems at Ericsson in the 1980s. He presented it to a wider audience in his OOPSLA 1987 paper “Object-Oriented Development in an Industrial Environment”, and described the full method in the 1992 book Object-Oriented Software Engineering: A Use Case Driven Approach.

When Jacobson, Grady Booch and James Rumbaugh merged their methods into the Unified Modeling Language, use case diagrams became part of UML, which the Object Management Group adopted as a standard in 1997. Alistair Cockburn’s Writing Effective Use Cases (Addison-Wesley, 2001) then shaped how use cases are written in practice — including the goal levels and the “fully dressed” template used by most teams today. In 2011 Jacobson, Ian Spence and Kurt Bittner published Use-Case 2.0, which adapts the technique to agile work by splitting use cases into “slices” small enough to fit into a sprint.

How Use Cases Work

Use cases describe the flow of interaction between an actor and the system in a chronological sequence of steps. The process begins with a triggering event that initiates the use case and ends with the achievement of a defined goal or the occurrence of an alternative outcome.

Each use case defines a main flow (also called the happy path) that describes the ideal interaction sequence, as well as alternative flows that handle variations and exceptions. The main flow describes the step sequence when everything works as expected. Alternative flows address situations where the user makes different decisions or the system must respond to unexpected conditions. Exception flows describe how the system handles errors and invalid inputs.

This structured description enables developers to consider all relevant scenarios and ensure that the system responds appropriately in every situation. Use cases serve as a contract between stakeholders and the development team, defining what the system should do without prescribing how it should be implemented.

Key Elements of Use Cases

Actors

Actors are users or external systems that interact with the system. They are classified by their role rather than by specific individuals. Primary actors initiate the interaction to achieve a goal, while secondary actors are called upon by the system to support the use case. Actors can include human users, external systems, hardware devices, or time-triggered processes.

Scenarios

Scenarios describe the sequence of steps that lead to the actor’s goal. Each step describes either an action by the actor or a response by the system. A well-written scenario is concrete enough to clearly communicate the desired behavior but abstract enough not to prescribe the implementation approach.

Goal

The goal defines the result the actor wants to achieve by interacting with the system. Goals can be defined at different levels, from strategic business goals to operational user goals. Alistair Cockburn’s goal levels framework distinguishes between summary-level, user-goal-level, and subfunction-level use cases, helping teams write use cases at the appropriate level of abstraction.

Preconditions and Postconditions

Preconditions describe the state of the system that must be satisfied before the use case can be executed. Postconditions describe the guaranteed state of the system after successful execution. These conditions help define system boundaries and facilitate the integration of different use cases into a coherent system specification.

Variants and Extensions

Variants describe alternative paths that may occur during use case execution. Extensions are optional flows that augment the main flow with additional functionality. The systematic capture of all variants is critical for the completeness of requirements elicitation and ensures no edge cases are overlooked.

Use Case Diagrams

Use case diagrams are graphical representations of use cases that show the relationships between actors and the system. They are created in the Unified Modeling Language (UML) and help visualize the functionality of the system and the communication between different actors.

Elements of a Use Case Diagram

A use case diagram consists of actors represented as stick figures, use cases represented as ellipses within a system boundary, and relationships between actors and use cases shown as lines. Additionally, relationships between use cases such as include (one use case contains another) and extend (one use case optionally extends another) can be represented. Generalization relationships between actors indicate inheritance of roles.

Practical Usage

Use case diagrams serve as an overview of system functionality and are particularly useful for stakeholder presentations and initial project planning. They show at a glance which functions the system provides and who uses them without diving into the details of individual interactions. However, diagrams alone are insufficient and must be accompanied by detailed textual use case descriptions.

Writing a Use Case Description

A diagram shows that a use case exists; the use case description states what happens inside it. The standard structure below is filled in for one goal — a customer returning a delivered order — so the working level of detail is visible rather than described.

Use case: Return a delivered order.

Primary actor: Customer. Secondary actor: Payment provider.

Preconditions: The customer is authenticated, and the order is marked delivered within the return window.

Main flow: (1) The customer opens a delivered order and requests a return. (2) The system lists the items still eligible for return. (3) The customer selects items and states a reason. (4) The system issues a return label and reserves the refund amount. (5) The warehouse confirms physical receipt. (6) The system instructs the payment provider to refund. (7) The system notifies the customer.

Alternate flow (3a): The customer selects an item outside the return window. The system explains why that item is excluded and continues with the remaining ones.

Exception flow (6a): The payment provider rejects the refund. The system records the failure, leaves the return open and raises a task for support rather than silently closing it.

Postconditions: The refund is either settled or an open support task exists for it. No return is left in an undefined state.

Note the discipline: every step is either an actor action or a system response, never both, and the postconditions hold for the failure path too. That is what makes the description testable.

More Use Case Examples

Two short examples show how the same structure applies to different kinds of goals.

Withdraw cash (ATM). Primary actor: bank customer. Secondary actor: the bank’s core system. Precondition: the ATM is in service. Main flow: (1) the customer inserts a card; (2) the system asks for the PIN; (3) the customer enters the PIN; (4) the system validates it with the core system; (5) the customer selects an amount; (6) the system checks the balance and dispenses the cash; (7) the system returns the card and prints a receipt on request. Alternate and exception flows: wrong PIN (3a, with a limit of attempts), insufficient funds (6a), not enough cash in the ATM (6b), card retained after too many failed attempts. Postcondition: the account is debited only if the cash was dispensed.

Generate the monthly regulatory report (system actor). Primary actor: a scheduler — a time-triggered actor rather than a person. Main flow: on the first working day of the month the system extracts data, validates it against the regulator’s schema, generates the file and submits it. Exception flow: validation fails, the system stops the submission and assigns a task to the compliance team. This kind of use case is easy to forget in workshops focused on human users — and it often carries legal deadlines.

Use Case vs User Story

The two are often confused because both describe what a user wants from a system. They serve different purposes:

	Use case	User story
Form	Structured description with numbered steps	One sentence: “As a [role], I want [goal] so that [benefit]“
Scope	Complete interaction, including alternate and exception flows	One piece of user value, small enough for one iteration
Purpose	Specify behaviour precisely; derive tests	Plan and prioritise the backlog; start a conversation
Detail	Up front, in the document	Added later through conversation and acceptance criteria
Typical context	Complex, regulated or integration-heavy features	Agile product development

In practice, many teams use both. A use case describes the full “Return a delivered order” interaction; its main flow and each important alternate flow become user stories, and the exception flows become acceptance criteria. Use-Case 2.0 formalises this approach through use case slices.

Use Cases and Business Process Models

A use case describes one actor’s goal within the system. A business process spans several actors, departments and often several systems — from a customer’s complaint to the refund and the quality review. The two levels complement each other: the process model shows the order of work and the hand-offs, and each user task within the process is a candidate for a use case. Our guide to BPMN 2.0 in practice shows how to model the process level before ordering software, and our article on functional and non-functional requirements covers the requirements that use cases alone do not capture — performance, security and availability.

The Process of Creating Use Cases

Identifying Actors and Goals

The use case creation process begins with identifying all actors and their goals. This is accomplished through stakeholder interviews, analysis of existing business processes, and observation of current workflows. Each identified actor is documented with their specific goals and the context in which they interact with the system.

Defining Interaction Scenarios

For each identified goal, interaction scenarios are defined that describe the steps to achieve the goal. It is important that use cases are understandable and precise, so they are often accompanied by use case diagrams that visualize the interactions between actors and the system. Each scenario should focus on a single complete interaction rather than combining multiple goals.

Review and Verification

Once created, use cases are reviewed and verified to ensure they accurately reflect actual requirements. Review sessions with stakeholders, domain experts, and developers help identify gaps, inconsistencies, and ambiguities. Use cases should be traceable to business requirements and testable through acceptance criteria.

Benefits of Use Cases

Use cases offer numerous benefits in software development. They improve communication between technical and non-technical stakeholders through the use of a common, understandable language. They help identify requirements gaps and inconsistencies early in the project lifecycle. Use cases form the basis for test planning since test cases can be derived from each use case scenario. They support project planning and effort estimation by clearly defining the scope of system functionality.

They are also valuable in regulated industries, where they form part of the requirements documentation needed for compliance, and they support scope management by listing the functionality stakeholders have agreed on.

Challenges of Creating Use Cases

Level of Detail

One of the greatest challenges is finding the right level of detail. Use cases should be detailed enough to be useful but not so complicated that they become difficult to understand. Overly detailed use cases can constrain implementation, while overly abstract use cases fail to provide sufficient guidance for developers.

Avoiding Implementation Details

It is important to avoid describing user interfaces or business rules that should be included in other parts of the documentation. Use cases should describe the what, not the how of implementation. Mixing interface design with behavioral requirements reduces the longevity and flexibility of use case documentation.

Consistency and Completeness

Ensuring that use cases are consistent with the actual needs of users and stakeholders and cover all relevant scenarios requires a systematic approach and regular reviews. Cross-referencing between use cases helps identify dependencies and potential conflicts.

Managing Complexity

In large systems, the number of use cases can quickly become overwhelming. Clear structuring and hierarchization of use cases is necessary to maintain clarity. Organizing use cases by business domain or actor group helps manage complexity.

Best Practices in Creating Use Cases

Involve stakeholders, review use cases regularly and keep them in a standard template.

It is advisable to build use cases around user goals rather than system functions, use consistent structure and terminology, and link use cases with user stories and acceptance criteria. Using templates and checklists helps ensure the quality and consistency of use cases. Teams should also consider maintaining a glossary of terms to ensure consistent language across all use cases.

Tools for Use Cases

Various tools are available for creating and managing use cases. Enterprise Architect, Visual Paradigm, and StarUML support the creation of UML diagrams and textual use case descriptions. Confluence and Notion are suitable for collaborative documentation, while Jira and Azure DevOps enable linking use cases with development tasks and tracking their implementation status.

ARDURA Consulting and Requirements Engineering

ARDURA Consulting helps organizations acquire qualified business analysts and requirements engineers with deep experience in creating and managing use cases. With a network of over 500 senior IT specialists, ARDURA Consulting can provide experts who structure the requirements elicitation process and improve communication between business and technical teams.

Summary

A use case describes how an actor reaches a goal with the system — main flow, alternate and exception flows, preconditions and postconditions — and a UML use case diagram gives the overview. Written at the right level of detail and combined with user stories and process models, use cases remain one of the most reliable ways to make requirements complete and testable.