The use case diagram is a visual scoping tool you use as an analyst to plan the boundaries of the business system that you’re analyzing, the expectations of the system (the use case name), and the potential user of the system.
It’s a very useful diagram because it gives the project team a high-level view of the solution scope and allows you and the designer to consider multiple implementation strategies. Because it’s so clear, it makes presenting the project scope information to all stakeholders easy and helps build consensus on the scope.
A use case diagram contains the following components:
Automation boundary: Indicated by a rectangle in the center of the diagram, the automation boundary represents the system under discussion.
Actors: These items are the stick figures documented with a descriptive name of the role of the actor. The actor represents a resource interacting with the system and can be a human or another system.
Associations: Associations are marked by a line connecting the actor to a use case, indicating that the actor is involved with the use case. An actor can be associated with multiple use cases, and a use case can have many actors associated with it.
Use cases: These items are represented by ovals inside the automation boundary and indicate the software system’s goals. They contain a brief name (usually verb + noun) to describe what they do.
Credit: Illustration by Wiley, Composition Services Graphics
The use case diagram is possibly the easiest diagram to create, so the design process doesn’t take much:
Draw the automation boundary in the middle of the workspace.
You can draw it on paper or a whiteboard or create it in Microsoft Visio or Microsoft Word (it doesn’t matter).
In the center of the automation boundary, identify the use cases that need to be detailed out and give them a brief description.
A combination of verb + noun (or noun phrase) is a very concise way to describe the use cases. In the example, the use cases are Create Order, Pay for Order, Verify Order, and so on.
Identify the actors who will be working within your system.
To find actors, ask “Who uses the software? Who provides the information to the software? What systems does the software interact with? Does anything happen at a predetermined time?” In the example, you can see both human actors (Customer, Cashier, and so on) and nonhuman actors (Google Maps, for example).
Because actors can be people or systems, label them by their roles rather than their specific names.
Connect the actors to the use cases with the association line.
This line indicates which actors interact with which use cases. Anywhere an association line crosses the automation boundary, you need an interface — that is, a way for the user to communicate with the operating system. Make note of these interfaces because you have to address each one when designing the solution.
Review the completed use case diagram with stakeholders to get their validation.
Better yet, have them participate interactively as you create the diagram.