Use case diagram

Use case diagrams are unfashionable and still useful for one job: agreeing scope with people who do not read technical diagrams. The boundary line is the whole point.

Keep the use cases at the level of goals, not steps.

#When to draw one

• Scoping conversations with non-technical stakeholders.

• Requirements documents where the actors matter.

• Explaining what a system does without explaining how.

#What is on the diagram

#A worked example

Actors, a boundary, and include and extend relationships:

The source, which you can paste into a new diagram and edit:

@startuml
left to right direction
actor Customer
actor "Support agent" as Agent
actor "Payment provider" as Pay

rectangle "Online shop" {
  usecase "Browse catalogue" as UC1
  usecase "Place order" as UC2
  usecase "Pay for order" as UC3
  usecase "Apply discount code" as UC4
  usecase "Refund order" as UC5
}

Customer --> UC1
Customer --> UC2
Agent --> UC5
UC2 ..> UC3 : include
UC4 ..> UC2 : extend
UC3 --> Pay
@enduml

#A few things that catch people out

• Include means always; extend means sometimes. Swapping them changes the meaning.

• Actors go outside the boundary. An actor inside it is a component, not an actor.

• Keep use cases to goals. "Click the save button" is a step, not a use case.

#Related

Four types cover most of it.