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?
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 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:
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:
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:
The relationships between different use cases. There are two different types of relationships, the Extend relationship and the Include relationship.
purchase itemuse case above might Include a
update inventoryuse case that is also included by
receive inventoryuse case. Include relationships are indicated by a dotted-line arrow pointing from the use case that includes the generic use case, to the use case that is being included, with the label “<<include>>” added to the arrow. Note that in Visio an Include relationship is called a
Usesrelationship. Like the example below:
Uses) relationships are mandatory and always uses when the
parentuse case is called, while
Extendrelationships are optional and may not be called every time the
Use Case Diagrams have several characteristics that separate them from other diagrams and models used in requirements work.
wideview of a system, but not a deep one. The use cases contained in the diagram are very high-level functions such as
Take Photograph, instead of deep ones such as
Fire Flash, or
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]
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.
Decide which system you are going to model. This may be a full system, or a component of a larger system.Example
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.
After I place the system boundary to start the diagram, it looks like this:
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:
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. 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.
Quality & Testing Analyst
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:
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:
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:
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:
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.
In general, your Use Case Diagrams should comply with the following rules in order to be “valid”: