# Use Case Goal Hierarchy with Include Relationships

**In short:** An include relationship links a base use case to another use case whose behavior it always runs as part of its own flow. Shared steps such as Authenticate are written once and reused by many goals.

## Explanation

A use case describes how a user reaches a goal with a system (see the article Use Case). Big goals often need smaller steps. The include relationship shows this in a use case diagram (see Use Case Diagram).

**What include means**

A base use case includes another use case as part of its own flow. The included behavior runs in full. Then the base use case continues where it left off. So the included step is mandatory, much like a subroutine call.

**Arrow direction**

The arrow starts at the base use case. The arrowhead points at the included use case. Read it as "the base needs the included one."

**Why use it: reuse**

The main purpose is reuse. When two or more use cases share the same behavior, you move it into its own use case. Authenticate is a typical example. Each goal that needs it includes it, so the behavior is described only once.

**Include versus extend**

Extend differs in one key way. An extending use case adds optional behavior to a base use case. An included use case is not optional.

**Building a goal hierarchy**

Include relationships stack goals into levels. A larger goal sits on top. It includes smaller use cases that serve as steps toward it. Goal levels are covered in Use Case Goal Level. The link from goal levels to building blocks is covered in Goal Hierarchy to Component Mapping.

**Use in documentation**

Use cases feed the runtime view in arc42 (see Runtime View). That view shows how building blocks carry out the important use cases. Scenarios are chosen by architectural relevance. You do not need one for every use case or every included step.

## Example

A bank's ATM supports the goal Change PIN.

- Change PIN includes Define New PIN.
- Change PIN also includes Authenticate.
- Withdraw Cash includes Authenticate too.

Authenticate is described once. Both goals reuse it. In the diagram, each arrow starts at the goal and points at the included use case.

## Trade-offs

Splitting out shared behavior avoids repeating it. But splitting too far creates many tiny use cases. That means more documents to write and read. Use cases are a requirements technique whose value lies in short, readable text. Heavy documentation effort before development starts is a warning sign. Include only behavior that is shared or clearly worth naming. In the runtime view, pick scenarios by architectural relevance, not by counting included steps.

Two goals include the shared Authenticate use case. Arrows point from base to included.

```plantuml
@startuml
left to right direction
actor Customer
rectangle ATM {
  usecase "Change PIN" as CP
  usecase "Withdraw Cash" as WC
  usecase "Define New PIN" as DN
  usecase "Authenticate" as AU
}
Customer --> CP
Customer --> WC
CP ..> DN : <<include>>
CP ..> AU : <<include>>
WC ..> AU : <<include>>
@enduml
```

## Checks

- Each include arrow starts at the base use case and points at the included use case.
- Included use cases describe mandatory behavior; optional behavior is modeled with extend instead.
- Behavior shared by several use cases, such as Authenticate, is factored out into one included use case.
- Runtime view scenarios are chosen for architectural relevance, not one per use case or included step.

## Related

- [Use Case](https://arc.fuet.ch/concepts/functional-requirements/use-case.md)
- [Use Case Diagram](https://arc.fuet.ch/concepts/modeling-uml/use-case-diagram.md)
- [Use Case Goal Level](https://arc.fuet.ch/concepts/functional-requirements/use-case-goal-levels.md)
- [Goal Hierarchy to Component Mapping](https://arc.fuet.ch/concepts/functional-requirements/goal-hierarchy-to-component-mapping.md)
- [Common Use Case Diagram Errors](https://arc.fuet.ch/concepts/modeling-uml/use-case-diagram-modeling-mistakes.md)
- [Runtime View](https://arc.fuet.ch/concepts/documentation/runtime-view.md)
- [Use Case Template](https://arc.fuet.ch/concepts/functional-requirements/use-case-template.md)
- [UML Generalization and Specialization](https://arc.fuet.ch/concepts/modeling-uml/generalization-and-specialization.md)

## Sources

- [Guideline: Include-Relationship](https://swi.cs.vsb.cz/RUPLarge/core.base_rup/guidances/guidelines/include-relationship_5AE2718.html) — swi.cs.vsb.cz, accessed 2026-11-09
- [“Include” and “Extend” Use Cases - Visual Paradigm Blog](https://blog.visual-paradigm.com/include-and-extend-use-cases/) — blog.visual-paradigm.com, accessed 2026-11-09
- [6 - Runtime view | arc42 Documentation](https://docs.arc42.org/section-6/) — docs.arc42.org, accessed 2026-11-09
- [Use Case](https://martinfowler.com/bliki/UseCase.html) — martinfowler.com, accessed 2026-11-09