Drawing a Use Case Diagram
Drawing a Use Case Diagram
A use case diagram is the most widely used model in requirements engineering for communicating what a system does — not how it does it. It shows, at a glance, every type of user who interacts with the system and every goal they can achieve through it. Before you write a single requirement, sketch a use case diagram: it surfaces missing actors, reveals hidden goals, and gives stakeholders something concrete to react to.
This lesson covers every notation element you need and walks you through building a complete diagram step by step using a realistic clinic booking scenario.
The Four Notation Elements
The UML standard defines exactly four visual elements for use case diagrams. Master these and you can draw any use case diagram correctly.
1. Actor — the Stick Figure
An actor represents any entity outside the system that interacts with it. Actors are drawn as a simple stick figure with a name label below. An actor is not a person per se — it is a role. The same individual may play multiple actor roles (a clinic receptionist who also views reports plays two roles). External systems that call your system are also drawn as actors.
2. Use Case — the Oval
A use case represents a goal that an actor can achieve using the system. Each use case is drawn as a named ellipse (<ellipse> in SVG terms). Name it with a verb phrase from the actor's perspective: Book Appointment, Cancel Appointment, View Schedule. Avoid technical names like INSERT_APPOINTMENT — those belong to design, not analysis.
3. System Boundary — the Rectangle
The system boundary is a plain rectangle that encloses all use cases belonging to the system being analyzed. Use cases sit inside the boundary; actors sit outside it. The system name appears at the top of the rectangle. The boundary makes explicit what is in scope and what is not — a critical communication tool when negotiating project scope with sponsors.
4. Association — the Plain Line
An association is a solid line connecting an actor to a use case it participates in. There are no arrowheads on a basic association — the line simply states that a relationship exists. An actor can be associated with multiple use cases; a use case can be associated with multiple actors.
«include» and «extend» relationships, which are covered in the next lesson.
Diagram 1 — Notation Reference
The diagram below shows each notation element labeled clearly before we move to a full example.
Step-by-Step: Drawing the Clinic Booking System
Let us apply the notation to a realistic scenario. A community health clinic wants to computerize its appointment booking. After stakeholder interviews, the analyst has identified the following facts:
- A Patient can register an account, log in, search for available slots, book an appointment, and cancel an appointment.
- A Receptionist can log in, book an appointment on behalf of a walk-in patient, cancel an appointment, and view the daily schedule.
- A Doctor can log in and view their own schedule for the day.
- An external SMS Gateway (a third-party service) receives booking confirmations and sends SMS reminders to patients.
Follow these four steps to convert this information into a use case diagram:
- Identify all actors. List every role that initiates an interaction with the system or receives output from it. Here: Patient, Receptionist, Doctor, SMS Gateway.
- Identify all use cases. For each actor, ask: "What goal do they want to achieve?" Each distinct goal becomes one use case oval.
- Draw the system boundary. Create a rectangle labeled "Clinic Booking System." Place all use cases inside it; place all actors outside it.
- Draw associations. Connect each actor to the use cases it participates in with a plain solid line.
Diagram 2 — Clinic Booking System Use Case Diagram
Reading the Diagram
Once drawn, a use case diagram can be read by any stakeholder, technical or not. Walk through it systematically:
- Identify scope. Every oval inside the rectangle is in scope. Anything left outside is explicitly out of scope. The diagram shows that payroll and billing are not part of this system.
- Identify who does what. Follow each association line: a Patient can Register, Log In, Search, Book, and Cancel. A Receptionist can Log In, Book, Cancel, and View the Schedule. A Doctor can only View the Schedule.
- Identify shared use cases. Book Appointment is associated with both Patient and Receptionist — both actors participate in the same goal through the same system. Cancel Appointment is similarly shared. This immediately prompts the analyst to check: do both actors follow the same steps, or does the Receptionist's cancellation flow differ?
- Identify external system interactions. The SMS Gateway is associated with Send SMS Reminder — it is a recipient of output, not a person.
What Belongs Inside vs Outside the Boundary
A question that trips up beginners: where do I draw the line? Apply this test: if the system you are building owns and executes the behavior, it goes inside. If an actor or another system merely triggers, receives, or provides data for that behavior, it stays outside.
- Inside: Register Account, Search Available Slots, Book Appointment, Cancel Appointment, View Schedule, Send SMS Reminder (the clinic system triggers the SMS gateway but the gateway executes the sending — this is a judgment call; if you own the SMS logic, put it inside).
- Outside: Patient portal app (a client, not the system itself), doctor's personal calendar (an external system that might be integrated later), payment processing (a separate bounded context).
Summary
- A use case diagram uses exactly four notation elements: actor (stick figure), use case (oval), system boundary (rectangle), and association (plain line).
- Actors are roles, not individuals; they live outside the boundary.
- Use cases are goals, not features or functions; they live inside the boundary.
- Associations have no arrowheads — arrows are reserved for include/extend (next lesson).
- The system boundary rectangle is a powerful scope-management tool — keep it visible in every stakeholder review.