Before anyone designs classes or services, the team should agree on what the system is for. A UML use case diagram lists the people and outside systems that use the shop (actors) and the goals each of them can reach (use cases), inside a box that marks the system boundary.
It is the one-page scope statement of the project.
1. The Diagram
Three actors sit outside the boundary: Customer and Admin are people; the Payment provider is another system, drawn on the right because it takes part but does not start these goals.
The customer has six goals, from Browse catalog to Request refund. A plain line means the actor takes part in that use case.
Place order (highlighted) includesPay for order and Log in: every order always pays and always needs a signed-in user. The dashed arrow points from the base case to the included one.
Track order includes Log in too, so the shared step is written once.
Apply discount codeextends Place order: it only happens sometimes. The extend arrow points the other way, from the optional case to the base.
The admin manages products, processes refunds (which also involves the payment provider) and views sales reports.
2. How to Read It
Use case names are short verb phrases written from the actor's point of view. Each ellipse is backed by a written description: preconditions, main steps and alternative flows. The diagram is the index; the text holds the detail.
3. Variant: Actor Generalization and Extension Points
A Registered customer can do everything a Guest can, plus place orders; the hollow triangle says the registered customer is a kind of guest and inherits its use cases. The Place order ellipse also names its extension point, and a note gives the condition under which the extension runs.
4. Pros and Cons
Pros
Fits on one page and reads well for business people, testers and developers.
Defines scope: what is inside the system and what is not.
Each use case becomes a natural unit for user stories, acceptance tests and estimates.
Shows outside systems you must integrate with, such as payment providers.
Cons
Shows no order, steps or data; the real content lives in the written use case text.
Include versus extend confuses many readers and is often misused.
Easy to drift into drawing functions ("Validate card") instead of user goals.
Adds little for small internal tools with one obvious user.
5. When to Use It
Use it when
Starting a project and agreeing on scope with stakeholders.
Planning releases: which goals ship first.
Finding every actor, including other systems, before designing interfaces.