Use Cases and Scenarios
A use case describes how an actor, a person or an external system, interacts with a solution to achieve a goal. It enumerates the possible outcomes of an attempt: the path where everything succeeds, the paths that still reach the goal another way and the ones that fail. Each of these paths is a scenario, a sequence of steps by the actor and the solution. The case is the container, the scenarios are the paths and the use-case diagram is the map that shows which actors touch which goals. The technique is written from the actor's point of view and as a black box: what the solution does, seen from outside.
Goal
A use case answers a question: for a given goal an actor pursues through the solution, what are all the ways the attempt can unfold? It gathers into a single artifact the nominal path, the variants that still reach the goal and the failures, and it attaches to each what must remain true at the end. The decision it supports is one of functional scope: what the solution must let people do, expressed in terms of actor goals rather than technical functions. Each case carries its business value in the named goal, which stops a team from writing a capability nobody has any reason to exercise.
The deliverable has two faces. The textual face is the case itself: an imperative name, a goal, the actors, the trigger, the preconditions, the numbered main scenario with its alternatives and exceptions and the exit guarantees. The graphical face is the use-case diagram, which sets the system boundary and shows at a glance which actors take part in which cases and which cases reuse others. The text carries the behaviour, the diagram carries the scope. A project needs both.
The technique originated with Ivar Jacobson, who presented the use case at the OOPSLA conference in 1987 and developed it within his Objectory method, then in his 1992 book. Jacobson later became one of the three authors of UML, which is why the diagram notation is standardised today by the Object Management Group. The way scenarios are written owes most to Alistair Cockburn, whose 2001 book fixes the goal levels and the main-scenario-plus-extensions structure that analysts use daily.
Usage
When to use it
- Framing a solution's functional scope: the diagram shows the actors' goals and where the system boundary runs.
- Rich interaction between an actor and a system: several paths, conditions, failure outcomes to specify together.
- Need for a stakeholder-readable language: the narrative flow is understood without training, unlike a formal specification.
- Actor goals already identified: the list of actors and their goals, from stakeholder analysis, feeds the cases directly.
- Basis for testing and design: each scenario is a candidate test case, each guarantee an assertion to verify.
- Behaviour to fix before development: the case states what the system must do, independent of how it will be built.
When not to use it
- Need still vague, to be explored by conversation: take user stories, negotiable and sized for a sprint.
- The study is about rules and decisions: take business rules analysis, which manages them separately.
- The study is about the look and layout of screens: take prototyping, where interface detail belongs.
Description
The case, the scenario, the diagram
Three objects overlap and are confused with one another. The use case is the goal-directed unit: the set of ways an attempt to reach a goal can unfold. A scenario is one concrete path through that case, a single sequence of steps. The main scenario, the one where everything goes right, is the shortest and simplest path to the goal. Alternate scenarios reach the goal by another path, exception scenarios end without reaching it. The use-case diagram tells no scenario: above all of this, it shows which actors take part in which cases and how the cases relate. Cockburn's formulation is the most compact: a use case is a main scenario plus a set of extensions, each extension being a condition and the steps it triggers.
The elements of a use case
The name is a verb followed by an object naming the actor's action and its target: "Renew a subscription", never a static heading like "Subscription management". The goal describes in one sentence the successful outcome from the primary actor's point of view, and it serves as the case's summary. The actors are the people or systems external to the solution that interact with it, designated by the role they play. The primary actor has the goal and most often triggers the case; the secondary actors, such as a payment system, provide a service the solution calls on to succeed. Some schools advise against treating a system or an event as an actor; the practice is a minority one.
The precondition states what must be true before the case can begin. The case assumes it true at the start and leaves it outside its run: writing "the holder is authenticated" as a precondition spares adding an authentication step to the scenario. The trigger is the event that launches the flow, most often an action by the primary actor, sometimes a temporal event such as an end-of-day routine or an end-of-month reconciliation. The guarantees, or postconditions, state what must be true when the case ends, and they split in two: the success guarantee holds on the successful path, the minimal guarantee holds even on failure and protects security and data integrity. A guarantee must hold for all scenarios, main and alternate alike, or it is merely a wish attached to the main scenario alone.
Choosing the goal level
A use case is written at a level, and choosing the level is the one most often got wrong. Cockburn offers a scale for it, the sea-level one. The user-goal level, the surface of the water, is where a single actor reaches a single goal in a single sitting: that is where an analyst writes. Above it, the summary level covers a process spanning several user goals ("Manage the account"): too broad to write in one piece, it is decomposed. Below it, the subfunction level describes a step reused by several cases ("Authenticate", "Make the payment"): a candidate for factoring out as an included case. The test is one question: can an actor accomplish it in one go and leave having gained something of value?
Two failures follow from a wrong level. The first is the case written too high, which becomes a catch-all where the goal dissolves. The second, more insidious, is the CRUD pattern: turning Create, Read, Update, Delete into four use cases per entity. These are subfunctions; they inflate the model and teach nothing about the actor's intent. Nobody logs in to "update a subscription row", they log in to renew their subscription. The user-goal level is the guard-rail against both failures.
Writing the main scenario as a black box
The main scenario is written in numbered steps, alternating actor and solution, from the actor's point of view and above all as a black box: each step says what the system does, seen from outside. Three to nine steps are enough for a healthy case. This black-box principle is the guideline easiest to betray, in two ways.
The first is the interface leaking into the flow: "the holder clicks the blue button", "picks from the dropdown", "the modal appears". The flow says what the system accomplishes. Interface detail belongs to prototyping, where it is designed and tested without prematurely freezing the behaviour. The second is burying business rules in the steps: hard-coding a fee scale, a rate table, an eligibility rule along the scenario. These rules are managed separately, through business rules analysis, and the step refers to them. A case that locks in a rule becomes wrong the day the rule changes, and the rule stays buried in a document nobody rereads.
Deriving alternates and exceptions
Once the main scenario is set, you walk each step and ask: what else could happen here? Each branch is marked by the number of the step it leaves, a letter distinguishing the branches of one step: 5a, 6a. An alternate still reaches the goal by another path and rejoins the main flow. An exception ends without the goal, and you then state the exit: what the system does and which guarantee holds despite the failure. This is where the minimal guarantee earns its meaning, naming what stays true when the goal is not reached. Exhaustiveness is a trap: the loose format invites capturing every micro-variant, and a case drowned under forty branches is no longer read. Keep the real paths, drop the laboratory hypotheses.
Reading the use-case diagram
The diagram sets the system boundary and distributes the actors' goals around it. The notation, standardised by UML, comes down to a few signs for anyone who wants to read it. An actor is a stick figure, placed outside the boundary: a role. A use case is an oval, placed inside, bearing the verb-plus-object name. The system boundary is a rectangle enclosing the ovals; label it with the system's name. An association is a solid line linking an actor to a case: it marks that the actor takes part in the case and reaches the functionality described.
Two relationships link the cases to each other, and readers miss this distinction more than any other. «include» is a dashed open-headed arrow, marked with the keyword, running from the base case to the included case: the base case always runs the included behaviour. It is used to factor out behaviour shared by several cases, "Make the payment" reused by "Renew a subscription" and by "Buy a ticket". «extend» is also a dashed open-headed arrow, but it points from the extending case to the base case, which surprises most readers: the arrow aims at the base case. The extension adds conditional behaviour, at a defined extension point, and the base case stays complete and functional without it. The rule fits in one line: «include» means "always and reused", «extend» means "sometimes and optional". Using one for the other or drawing the «extend» arrow toward the extending case is the commonest UML error. A generalization also exists, a solid line ending in a hollow triangle, for an actor or a case that is a specialised kind of another; it is the least-used relationship.
The notation stops there for the business analyst: these few signs are enough to read a use-case diagram and discuss it with stakeholders. UML's fine semantics, its other diagrams and the advanced use of «include» and «extend» belong to dedicated modelling training. Over-decomposing a model into nested includes is functional decomposition in disguise, which loses the goal the case was meant to carry.
Running the exercise
- Identify the actors and their goals
From the stakeholder list, name each external role that interacts with the solution and the goal it pursues. - Name each case by its goal
A verb, an object, at user-goal level. - Write the main scenario
Numbered steps, black box, from the actor's point of view. No screen mechanics, no hard-coded business rule. - Derive the alternates and exceptions
Walk each step, label the branches against the step they leave, state an exit for each exception. - Define precondition, trigger and guarantees
What must already be true, what launches the case, what holds at the end on success and even on failure. - Draw the diagram
Actors outside the boundary, cases as ovals inside, associations as solid lines, shared behaviour as «include», optional behaviour as «extend». Keep rules and decisions out of the steps and refer to them.
Use case or user story
The confusion with the user story is worth clearing up, since the two cover the same ground. A user story is a short, negotiable placeholder for a conversation, "as a traveller, I want to renew my subscription so that I can keep travelling", sized to fit a sprint. A use case is a fuller behavioural specification of one goal, with all its flows and guarantees. The two are complementary: a story whose interaction turns out to be complex is elaborated into a use case when the time comes to fix the paths and outcomes. You choose by the risk and the maturity of the need, one to open the discussion, the other to settle the behaviour.
AI considerations
The first worthwhile use is drafting. From an interview transcript, a process description or a set of user stories, a language model proposes a first numbered main scenario and a list of candidate alternates and exceptions. It is fast at this mechanical part, and it leaves the analyst the sorting work rather than the blank page. The second use is where the machine excels: enumerating what can go wrong at step N. Payment declined, session expired, item no longer available, concurrent edit: a model rolls these exceptions out as a checklist, and the business analyst keeps only the ones that can occur.
The third use is structural checking. You ask the model whether every step has a defined outcome, whether the guarantees hold across all flows, whether a precondition is assumed without being written, whether two cases overlap. It spots the structural omissions; how much they matter is still a judgement. The fourth use is naming and levelling: flagging that a "case" is really a CRUD subfunction or a summary and proposing verb-plus-object names. The fifth is format conversion, moving from a full case to an informal paragraph or the reverse and preparing the multilingual versions.
What AI cannot carry lies in the nature of the technique. Identifying the actors and goals is an act of elicitation and a political judgement: who the real stakeholders are, which goals matter, where the system boundary runs. The model will invent plausible, wrong actors. The real behaviour of the system cannot be guessed: only the stakeholders and the solution's constraints define what the system does, and a flow produced by a model is a hypothesis to validate. The validity of edge cases mixes real risks and fiction in the same breath: a human decides which are in scope, which are handled elsewhere, which cannot occur. Finally the model must not bury guessed eligibility rules, rates or personal-data handling in the steps. AI drafts and stress-tests the flows, the business analyst owns the actors, the scope and what is true.
Examples
A self-service portal where a customer manages their transport subscriptions online. The case "Renew a subscription" exercises the diagram's two relationships: "Make the payment" is shared with buying a ticket, so it is included, and a discount voucher is optional, so it is an extension.
Read the scope first. The diagram places the holder and the payment system on either side of the boundary, splits the holder's goals into distinct cases and shows what those cases share. The association links the actor to the case it takes part in. The «include» arrow pulls "Make the payment" out of the two cases that reuse it, making the shared behaviour visible without copying it. The «extend» arrow hooks "Apply a discount voucher" onto the renewal by pointing at the base case, which stays complete and functional without the extension.
The written artifact tells the same story more closely: identity and guarantees first, then the scenarios gathered in a single table where each row carries its path type.
Use case
Renew a subscription
| Step | Actor or system action | Flow type |
|---|---|---|
| 1 | The holder selects the subscription to renew. | Main |
| 2 | The system displays the proposed validity period and the renewal price. | Main |
| 3 | The holder confirms the period. | Main |
| 3a | The holder applies a discount voucher before confirming; the system recomputes the price shown at step 2, then the flow continues. | Extension «extend» |
| 4 | The system checks eligibility for renewal. | Main |
| 5 | The holder chooses the means of payment. | Main |
| 5a | The holder chooses a card already on file; the flow resumes at step 6 with no new entry. | Alternate |
| 6 | The system obtains authorization from the payment system. («include» Make the payment) | Main |
| 6a | The payment system declines authorization; the system offers another means. If none succeeds, the case ends without renewal. | Exception |
| 7 | The system records the renewal and updates the validity on the SwissPass. | Main |
| 8 | The system confirms the renewal to the holder. | Main |
A scenario is a path through this case: the main one runs 1 to 8, the alternate 5a substitutes a step and rejoins the flow, the exception 6a ends it without the goal and the minimal guarantee then holds since nothing is charged or recorded. What the diagram adds to the text is the scope: "Make the payment" is included by "Renew a subscription" as by "Buy a ticket", and that sharing justifies pulling it out as an included case rather than copying it into each scenario.
Visualizations
Two figures carry the example. The use-case diagram shows the scope: the holder and the payment system on either side of a rectangular boundary, the cases as ovals inside, the association as a solid line, «include» and «extend» as dashed arrows, the «extend» arrow pointing at the base case to make visible the direction intuition reverses. The scenario table shows the behaviour: the same case walked as several labelled paths. The first answers "who touches what and what is shared", the second "how the attempt unfolds".
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Medium | The actors, goals and scope must be established before writing, through elicitation and stakeholder analysis. That is where the case's accuracy is decided. |
| Execution | Medium | A user-goal case is written in one session. The cost rises with the number of alternates and exceptions to derive, whatever the size of the system. |
| Documentation | High | Cases are kept up to date as behaviour, rules or scope change, and mapping them to the software design demands development effort. |
Tools
A word processor is enough to write a case, and a template, Cockburn's for instance, ensures no field is forgotten: scope, level, primary actor, stakeholders, preconditions, guarantees, trigger, main scenario, extensions. A spreadsheet holds the numbered scenario table well, and a whiteboard is enough to sketch a first boundary and two or three ovals. These generic tools serve as long as the cases stay few and loosely linked.
For the diagram, general-purpose drawing tools, diagrams.net, Lucidchart or Visio, carry decent use-case stencils; their contribution stops at the drawing. UML modelling tools, Enterprise Architect, Visual Paradigm or Modelio, hold the case and its diagram as objects of one model, trace them to the diagrams that realise them and flag a misdirected «extend» arrow or a case without an actor. When cases number in the dozens and serve as a basis for testing, requirements and ALM tools, Jama, Polarion, Azure DevOps or DOORS, link them to requirements, test cases and versions and make visible a scenario's coverage by its tests.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.47 Use Cases and Scenarios: the definition, the list of elements (actors, preconditions, trigger, main flow, alternate and exception flows, guarantees), the use-case diagram and the deferral to UML for its notation.
- Ivar Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992: the founding work on the use case, from the Objectory method and presented at OOPSLA 1987.
- Alistair Cockburn, Writing Effective Use Cases, Addison-Wesley, 2001: the goal levels (the sea-level scale), the main-scenario-plus-extensions structure, the actor vocabulary and the full and casual formats.
- Object Management Group, Unified Modeling Language (UML), version 2.5.1 (formal/17-12-05, 2017): the standardised notation of the use-case diagram, actor, case, boundary, association, «include», «extend» and generalization.