In the previous chapter, we introduced prototypes as tools that help us explore and test our design before writing code.

One of the most useful behavioural prototypes is the use case.

Although the names sound similar, use cases and user stories are not the same thing.

A user story describes what someone wants to accomplish.

A use case describes how the system and an actor interact to accomplish that goal. Be careful – however – a use case won’t say (for example) that “the user presses a button” and then the “system responds”.

In other words, a use case expands a requirement or user story into a step-by-step description of the conversation between an actor and the system.

What Is A Use Case?

A use case models how a system responds when an actor performs a particular task.

An actor is anyone or anything that interacts with the system. In many cases this is a person, but actors can also be external systems, devices, or services.

A good use case describes both sides of the interaction:

• what the actor does, and
• how the system responds.

If a description includes only what the user does, or only what the system does, it is not a complete use case.

The goal is to describe the complete interaction from beginning to end.

Three Types Of Use Cases

The amount of detail included in a use case depends on the size and complexity of the project.

Three common formats are used.

Brief Use Case

A brief use case is a short paragraph describing the main interaction between the actor and the system.

It focuses only on the happy path – the situation where everything works as expected.

Brief use cases are often used early in the design process or for relatively simple functionality.

Casual Use Case

A casual use case expands on the brief version by including alternative flows.

Alternative flows describe what happens when something unexpected occurs, such as:

• invalid user input,
• missing information,
• communication failures, or
• other error conditions.

These alternatives help the design team think beyond the ideal scenario and ensure the system responds appropriately when problems occur.

Fully Dressed Use Case

A fully dressed use case provides the greatest level of detail.

Instead of being written as paragraphs, it is organized into sections that typically include:

• the use case name or identifier,
• primary and secondary actors,
• preconditions,
• the main flow,
• alternative flows, and
• postconditions.

The main flow is usually presented as a numbered sequence of interactions.

Alternative flows reference the step where they branch away from the main flow before describing how the system responds.

This format is common on large or complex projects where many developers need a precise understanding of system behaviour.

Writing A Use Case

Most use cases begin with a requirement or user story.

Select one requirement and ask a simple question: What does the system do in response to the actor?

Start by writing the main flow.

Assume that everything works correctly. Describe one interaction at a time, alternating between the actor’s actions and the system’s responses.

Once the main flow is complete, consider situations where something might not go as planned.

Ask questions such as:

• What happens if the user enters incorrect information?
• What happens if required information is missing?
• What happens if another system cannot be reached?
• What happens if validation fails?
• What happens if the actor cancels the process?

Each answer becomes an alternative flow.

Thinking about these situations early helps uncover missing requirements before development begins.

Good Practices

Regardless of which format you choose, several guidelines apply to every use case.

Give each use case a meaningful name or identifier.

This makes it easy to reference related functionality.

For example:

• 1.0 Create Account
• 2.0 Log Into the System
• 3.0 Reset Password

Later use cases can reference earlier ones instead of repeating the same information.

End every flow in a stable state.

A stable state does not necessarily mean the actor achieved their goal.

For example, a failed login attempt is still a stable outcome if the system displays an error message and returns the user to the login screen, ready to try again.

The important point is that the system remains functional regardless of the outcome.

Example: Logging Into The System

Suppose we begin with the following user story: As a user, I want to log into the system so that I can access my account.

Note, in the brief use case example:

• “connected to the main server” is a pre-existing condition,
• both the system and the actor are described as doing things, and
• the use case ends in a stable state.

You should notice that the casual use case looks very similar to the brief use case, save for adding the alternate flow (bolded, and shown in red). Further, you should notice that:

• other use cases are referenced (specifically 1.0 Create an account, and 3.0 Reset forgotten password),
• both the main and alternate flows end in a stable state.

Notice that all three formats describe the same interaction.

The difference is simply the amount of detail they include.

Choosing The Right Format

The appropriate use case format depends on the project.

Small projects often benefit from brief or casual use cases because they are quick to write and easy to revise.

Larger projects usually require fully dressed use cases so that everyone involved has a consistent understanding of the system’s behaviour.

Regardless of the format, the goal remains the same:

Use cases help us understand how the system should respond before we begin implementing it.

Looking Ahead

Use cases describe how a system behaves.

In the following chapters, we’ll explore additional behavioural prototypes that model interactions from different perspectives, helping us better understand both the structure and operation of the software we’re designing.