Use Case Diagrams

DISCLAIMER: I am not a big fan of Use Case Diagrams. And because I don't use them much, it is entirely possible that there are mistakes in this wiki article. I have done my best to make it accurate though, and my sources are documented at the bottom. If you wonder what I suggest as an alternative, please see my blog post: Do We Really Need Use Case Diagrams?

What is it?

Originally developed by Ivar Jacobson when he was still at Erickson, a Use Case Diagram is a visual model that depicts key system functions accessed by those outside the system and the actors that interact with those functions. It is one of the most-widely use UML models and most business analysts should be familiar enough with them to at least use them casually.

Use Case Components

Use Case Diagrams are made up of five standard components. They are:

The system being modeled. The system is generally represented as simple rectangle into which the use cases are placed. The system name is commonly added just inside the top border of the rectangle.


The actors who interact with the functions of the system being modeled. Actors are always placed outside the system boundary and represent general roles, not specific individuals. For example, an Actor would be “Student”, but not “Bill Jones”, and probably not even “12th Grade Student”. Actors can also be other systems that interact with the system being modeled. Human actors are generally represented by stick figures while system actors are generally represented by rectangles with the other system name enclosed in double triangle brackets (i.e. <<system name>>. An example of human actor is below:

Use Case Diagram - Actor Symbol

The use cases of the system. These are high-level functions that will be further documented in the form of the textual use cases, not diagrams. They are what an Actor would like the system to do; and are usually named in the form of a present tense verb+object pair, such as “Update Inventory”, “Hire Employee”, “Order Food”, and similar names. Use cases are represented in the diagram by ellipse like this:

Use Case Diagram - Use Case Symbol  

The associations between actors and use cases. Sometimes also referred to as Connections. These associations indicate that the use case will be initiated by the actor(s), or that they participate in the Use Case or benefit from it. There seem to be two different standards for how Associations are represented. In some cases it is by a simple line (not an arrow) between the actor and any use cases they directly interact with; and in other cases it is a solid line arrow leading from the initiating actor to the use case or from the use case to any participating or benefiting actors. An example of the simple line option is below:

Use Case Diagram - Association  

The relationships between different use cases. There are two different types of relationships, the Extend relationship and the Include relationship.

Use Case Diagram - Extend Relationship Use Case Diagram - Uses Relationship    


Use Case Diagrams have several characteristics that separate them from other diagrams and models used in requirements work.[3]


Mis-Use Cases

You can use the exact same format of Use Case Diagrams to instead make Abuse Case or MisUse Case diagrams.

Rather than diagramming functions that actors want the system to do, you instead diagram use cases that are things you don’t want someone to do. See Reference item 6 for the basic concept, while Reference item 7 significantly expands on the idea.[6. 7]


Why do it?

Use Case Diagrams describe the relationships between requirements, users, and the major components of a system. It does not describe the requirements in detail. Thus, they are high-level requirements artifacts.

Use Case Diagrams are created to help identify:


Use Case Diagrams are frequently among the earliest models or diagrams created during the enterprise analysis or requirements elicitation work.

These initial Use Case Diagrams are then elaborated, supplemented, and expanded through (descriptive) Use Cases (non-diagram Use Cases), additional models and diagrams (such as UML Activity, Sequence, and Class Diagrams), or in other more-detailed requirements artifacts (detailed functional and non-functional requirements) as more information is learned and as more detailed requirements are defined.

How do I do it?

Step 1

Decide which system you are going to model.  This may be a full system, or a component of a larger system.


As an example, I am going to walk through the process of creating a Use Case Diagram for a simplified (but not too simple) Requirements Management System.

I am going to use Visio for this, so that may limit my options for the diagram.


Step 2

After I place the system boundary to start the diagram, it looks like this:


Use Case Diagram - Step 2

Step 3

Define the actors. One way to identify actors is that they are things that cannot be controlled by the system yet which interact with it. This helps to identify both human and non-human (other system) actors.


For my Requirements Management System, I identify the following actors:


As a result of defining those actors and adding them to my diagram, it now looks like this:

Use Case Diagram - Step 3

Step 4

Start adding the use cases. As a guide, any functionality that is not interacted with by an actor should not be included in the Use Cases that are part of the diagram. Also, the use case should be of sufficiently high-level that is should make sense for an actor to do ONLY that thing during a session.[3] To use the photograph metaphor above, it makes sense for a user to Take Photograph and do nothing else. It does not make sense for a user to Open Shutter and do nothing else.

A good place to start with defining use cases is with any goals you have specified that your system should meet. Depending on the level of detail you have defined your goals at, the goals may be use cases in themselves, or can be decomposed into functionality (use cases) needed to meet the goal.

After the goals, you should also engage with representatives of your actor types (your SME’s and/or stakeholders) and ask them for list of things they would expect to be able to do with the system you are defining.


So I go to each actor and ask them what they would want the new system to do, and get the following results.

Business Analyst


Project Manager




Quality & Testing Analyst


System Support

So after that gathering the information above, one thing to notice is that many of the verbs are very specific (such as Define) and that the user may actually want more functionality than that. So I often use the verb Manage instead, and clarify with the project team that Manage includes verbs like create, edit, and delete.

With some changes to the verbs and objects, I add the Use Cases to my diagram so that it looks like the one below:

Use Case Diagram - Step 4  

Step 5

Add the connections. Generally, the only connections that should be included in your model are connections between actors and use cases. You should not employ a use case diagram to show interactions between actors as the use case diagram is system focused.


Using my list of who wanted what, I add the connections and get the diagram below:

Use Case Diagram - Step 5

Step 6

Refine any use cases by adding Relationships.


Looking at the last version, the diagram is bit busy, but not too overwhelming. However, now it’s time to start thinking about Relationships. So I make the following changes:

When all of those changes are made, the result is a diagram like the one below:

Use Case Diagram - Step 6  

Step 7

Review, validate, and further elaborate.


I this example, I believe I have captured the various use cases, so I just try to clean up the diagram slightly to make it more understandable. I could try and break up the diagram into separate smaller diagrams that are more focused on specific functional areas (requirements creation and management, project management, system management, reviews and approvals, etc.), but that violates the general goal of modeling a system (rather than just parts of them).

So the results final look like this:

Use Case Diagram - Step 7  

What Should the Results be?

The final diagram should look something like the one in Step 7 above. Hopefully, your system is much simpler or you are much better than I am at creating Use Case Diagrams.

Validation Rules

In general, your Use Case Diagrams should comply with the following rules in order to be “valid”:









  1. Book:  Modern System Analysis and Design, Fifth Edition - Chapter 7 Appendix: Object-Oriented Analysis and Design. By Hoffer, George, and Valacich. Pearson Prentice Hall.  2008.
  2. Book: Business Analysis Techniques - 72 Essential Tools for Success. By Cadle, Paul, and Turner. BCS. 2010
  3. Article: UML Use Case Diagrams - Tips and FAQ. By Rus Heywood. From the 1999 Carnegie Mellon University Object-Oriented Analysis and Design course.
  4. Article:  UML Use Case Diagrams – Reference.  By Microsoft.
  5. Article:  Use Case Diagrams. By Scott Ambler.
  6. Research Paper:  Using Abuse Case Models for Security Requirements Analysis. By John McDermott and Chris Fox. Computer Security Applications. 1999.
  7. Research Paper:  Eliciting Security Requirements with MisUse Cases. By Guttorm Sindre and Andreas L. Opdahl. Requirements Engineering. 2005.

Related Resources