# Use Case

**In short:** A use case is a structured description of how a system responds to requests from outside actors. It organizes requirements around user goals and can be kept brief or written in detail.

## Explanation

A use case is a structured description of how a system behaves when an outside party, called an actor, makes a request. An actor can be a person or another system. Use cases organize requirements as a narrative of how users relate to the system and use it to reach their goals.

Jacobson described the technique in a 1987 OOPSLA paper. It was based on work at Ericsson, where it captured and specified a system's requirements. The UML use case diagram comes from his Objectory notation. UML is the Unified Modeling Language (see the article Unified Modeling Language (UML)).

**Levels of detail**

Cockburn describes a more detailed structure for a use case. He allows teams to simplify it when less detail is needed. Many teams write use cases from a structured template, though informal writing also works. The article Use Case Template covers the structure.

Cockburn also suggests marking each use case with a symbol for its goal level. The article Use Case Goal Level explains this.

**Diagrams**

A use case diagram combined with short use case briefs is a handy, lightweight tool. See the article Use Case Diagram.

**Compared with user stories**

Stories are finer-grained chunks used for planning. The article User Stories vs. Use Cases compares the two.

## Example

A bank describes a use case called "Change PIN" for its cash machine. The actor is the customer. The text describes the requests the customer makes and how the system responds. A one-paragraph brief gives the overview. A fuller template adds detail for readers who need it.

## Trade-offs

Use cases are often too large to estimate usefully. Teams that plan work in small chunks may therefore need finer-grained user stories as well. Detailed templates give more precision but take more effort. They can be simplified when less detail is needed.



## Checks

- Each use case is written as a structured description of how the system responds to requests from external actors.
- The level of detail of each use case fits its audience, and the template is simplified where less detail is needed.
- Each use case is marked with its goal level.

## Related

- [Use Case Template](https://arc.fuet.ch/concepts/functional-requirements/use-case-template.md)
- [Use Case Goal Level](https://arc.fuet.ch/concepts/functional-requirements/use-case-goal-levels.md)
- [Use Case Diagram](https://arc.fuet.ch/concepts/modeling-uml/use-case-diagram.md)
- [User Stories vs. Use Cases](https://arc.fuet.ch/concepts/functional-requirements/user-story-vs-use-case.md)
- [User Story](https://arc.fuet.ch/concepts/functional-requirements/user-story.md)
- [Use Case Completeness Check](https://arc.fuet.ch/concepts/functional-requirements/use-case-completeness-check.md)
- [Use Case Goal Hierarchy with Include Relationships](https://arc.fuet.ch/concepts/modeling-uml/use-case-goal-hierarchy-with-include-relationships.md)
- [Unified Modeling Language (UML)](https://arc.fuet.ch/concepts/modeling-uml/uml-unified-modeling-language.md)

## Sources

- [Use Cases And Stories](https://martinfowler.com/bliki/UseCasesAndStories.html) — martinfowler.com, accessed 2026-11-09
- [Use case - Wikipedia](https://en.wikipedia.org/wiki/Use_case) — en.wikipedia.org, accessed 2026-11-09
- [Advantages of User Stories over Requirements and Use Cases - Mountain Goat Software](https://www.mountaingoatsoftware.com/agile/advantages-of-user-stories-for-requirements) — mountaingoatsoftware.com, accessed 2026-11-09