Stop 03 · Requirements Analysis & DocumentationTopics · 5/10

Use Cases & Use Case Diagrams

In short

A use case tells the story of one person using a system to get one thing done, including what happens when things go wrong. It's a great way to spot missing steps before anyone builds.

A use case describes a specific interaction between a user (actor) and a system to achieve a goal, often visualized in a use case diagram — a traditional, more structured alternative to Agile user stories.

The purple blob stands at a railway ticket counter window holding a ticket.

Think of it like this

The railway counter routine

At a reservation counter: you give the form, the clerk checks seats, takes payment and hands a ticket. But what if no seats are left? You get a waitlist ticket. The main routine plus the 'what if' paths is exactly a use case.

Watch it happen

Use case: withdraw cash at an ATM

Customer

ATM

Bank system

Insert card + PIN

1/6The actor, the customer, starts the use case with a goal: get cash.

The big ideas

What you need to know

Actor and goal

An actor is anyone or anything outside the system that uses it: a customer, an admin, another system.

Main flow first

Write the normal, successful path as numbered steps, alternating between actor action and system response.

Alternate flows

Then list what can go wrong or differ at each step, like a wrong PIN or low balance, and how it's handled.

The diagram is a map

A use case diagram shows stick-figure actors linked to oval use cases inside a system box. It's an overview, not the detail.

See it in code

Walk through the code

text

1Use case: UC-02 Withdraw cash2Actor: Bank customer3Precondition: ATM is online and has cash.4Main flow:5  1. Customer inserts card and enters PIN.6  2. System verifies the PIN with the bank.7  3. Customer chooses an amount.8  4. System checks balance and dispenses cash.9  5. System returns the card and the receipt.10Alternate flows:11  2a. Wrong PIN: ask again, block card after the allowed tries.12  4a. Low balance: show a message, return to step 3.13Postcondition: Balance is reduced by the amount.

1/4Name, actor and precondition: what must already be true before this starts.

A written use case. The diagram gives the overview; this text holds the detail developers and testers need.

Save yourself the pain

Common mistakes

Oops

Drawing a use case diagram and calling the requirements done.

Do this instead

The diagram is just a map. Each oval needs a written use case with flows and alternates.

Oops

Writing use cases full of button clicks and screen colours.

Do this instead

Describe intent ('Customer chooses an amount'), not UI detail. Design decides the buttons later.

Your mission

Write a use case

~30 min

Quick check

In a use case, what is an alternate flow?

Go deeper

1Write a detailed use case for a common system interaction, including alternate flows.
2Sketch a simple use case diagram showing actors and their interactions with a system.
3Compare use cases to user stories and note when each format fits better.