Introduction to Use Cases

Foundations

Use Case

A description of interactions between actors and a system that delivers an observable result of value to an actor.

Why Use Cases

They capture functional requirements in the language of user goals, making them clear and testable.

Functional Requirement

A statement of what the system must do; use cases capture most functional requirements.

Observable Value

Each use case must deliver a result the actor cares about, or it is not a real use case.

Actors

Actor

Someone or something outside the system that interacts with it to achieve a goal; a role, not a person.

Primary Actor

The actor who initiates a use case to achieve a goal.

Secondary Actor

A supporting actor, often another system, that helps the system fulfill the use case.

Identifying Actors

Finding the roles that interact with the system by asking who uses it and what other systems connect.

Structure

Use Case Diagram

A UML diagram showing actors, use cases, and their associations for a quick scope overview.

Use Case Model

The set of actors, use cases, and relationships that defines system scope and value.

Identifying Use Cases

Finding use cases by asking what goals each actor wants to accomplish with the system.

Writing

Use Case Specification

The detailed text: name, actors, preconditions, postconditions, basic flow, and alternate flows.

Basic Flow

The main success scenario where everything goes as expected and the actor achieves the goal.

Alternate Flows

Variations and exceptions to the basic flow that cover the full range of behavior.

Preconditions

Conditions that must be true before a use case begins.

Postconditions

Conditions guaranteed true after the use case completes, describing the resulting state.

Scenario

A single specific path through a use case — the basic flow plus chosen alternates.

Step Writing Style

Each step is a simple subject-verb-object statement describing one interaction.

Quality

Right Level of Detail

Detailed enough to be testable and unambiguous, but not so detailed it becomes design.

Avoiding UI Detail

Describing what the actor and system do, not how the screen looks, to keep use cases stable.

Good Use Case

Clear, goal-focused, delivers value, and covers exceptions without unnecessary complexity.

Applying It

Use Cases in the Process

Use cases drive analysis, design, and testing, connecting requirements to the rest of development.