A business use case diagram applies UML use case notation to a whole organisation instead of a software system. The boundary is the business, actors are outside parties (customers, partners, regulators), and each use case is a service the business delivers to them. The sample shows an insurance company and, in a variant, the business goals those services exist for.
1. The Diagram
The large rectangle is the business system, Harbor Insurance. Everything inside is something the company does; nothing about IT yet.
Actors with a slash are business actors: external parties who get value from or impose rules on the business.
The Broker buys and renews policies on a client's behalf; the Policyholder renews, pays premiums and files claims.
Buy policy and Renew policy both includeAssess risk: underwriting always happens and is modelled once.
File claim includes Settle claim, the part the policyholder actually cares about.
On the right, the Regulator receives solvency reports and the Reinsurer takes on transferred risk. Stakeholders who never buy anything still shape the business.
2. How to Read It
The slash on actor and ellipse is the Rational Unified Process (RUP) convention for the business level; plain shapes mean a system use case. UML 2.5 itself expresses the same idea with stereotypes such as «business actor». Goals are not core UML; they are commonly added as stereotyped classes or notes.
3. Variant: Goals Mapped to Use Cases
Stakeholders care about outcomes. Linking each business use case to a measurable goal shows why it exists and which ones deserve investment. A use case that supports no goal is a candidate for removal; a goal with no use case is an unmet strategy.
4. Pros, Cons, and When to Use
Pros
Gives executives and analysts a one-page map of what the business does and for whom.
Uses familiar UML shapes, so it flows into system use cases later.
Highlights stakeholders who are easy to forget, such as regulators.
Good scoping tool before a transformation or new system.
Very little notation to learn.
Cons
Shows no order, timing or decisions; you need BPMN or activity diagrams for that.
The slash notation comes from RUP and is not supported by every tool.
Include and extend are often misused as a flowchart.
Too abstract for developers on its own.
Goals sit outside core UML and need a convention.
When to use
Early discovery and scoping workshops.
Explaining the business to new team members or vendors.
Deciding which business services a new system must support.
When not to use
Detailing process steps (use BPMN or a swimlane flowchart).
Specifying software behaviour (use system use cases with written scenarios).
5. As Diagrams-as-Code
PlantUML has built-in business variants: actor/ and usecase/ draw the slashed shapes.
@startuml
left to right direction
actor/ "Broker" as BR
actor/ "Policyholder" as PH
actor/ "Regulator" as RG
actor/ "Reinsurer" as RI
rectangle "Harbor Insurance" <<business system>> {
usecase/ "Buy policy" as Buy
usecase/ "Renew policy" as Renew
usecase/ "Pay premium" as Pay
usecase/ "File claim" as File
usecase/ "Assess risk" as Risk
usecase/ "Settle claim" as Settle
usecase/ "Report solvency" as Report
usecase/ "Transfer risk" as Transfer
}
BR -- Buy
BR -- Renew
PH -- Renew
PH -- Pay
PH -- File
Buy ..> Risk : <<include>>
Renew ..> Risk : <<include>>
File ..> Settle : <<include>>
Report -- RG
Transfer -- RI
@enduml