How to Create a Use Case Diagram (Part 1)

Posted by Mohamed Elgendy on February 22, 2016
6 minutes read

In this article, I'll discuss the following:

So, without further ado, let's get started.

What is a use case diagram? top

Use case diagrams represent a graphical overview of the functionality provided by the system in terms of actors, their goals, and dependencies between them.

Why create a use case? top

  • A great way to show how the functionality works
  • To represent how the system responds to the end user interactions by illustrating the interaction between the end user and the system from the user’s perspective
  • Very easy to understand by non-technical stakeholders

Let's take a look at a food ordering app (e.g. a service like GrubHub or Seamless) example below:

Image from the "3D Business Analyst" book.

In the above example, you can see some actors and functions (use cases) connected by a bunch of relationships (associations) to define the interactions between them. Before we get into the use case components, let's understand the system described in the above example:

  1. The system will be used by three types of actors: Waiters, Customers and a Cook
  2. Customers will place their order. Customers can also order a drink
  3. Customers will enter their information and pay for food
  4. Waiters will recieve the order and send it to the Cook
  5. The Cook will prepare the food and send a notification to the Waiter
  6. Waiters will finalize the order and deliver it to the Customer's address

What are the components of a use case? top

Use Cases contain two main deliverables: use case diagram and a use case document. Some organizations require both from the BA and others require just one of them. This depends on the project nature, your audience and the organization's PMO methodologies. In this post, I'll cover the use case diagram. You can read the use case document and download a free template in part 2.

Image from the "3D Business Analyst" book.
  1. Actors: top
    • Actors are not part of the system; they represent any person or system that interacts with the application
    • The actor represents a specific role - not all users playing that role. In the above example, you can have more than one waiter but they are all represented by one actor
    • We do not have control over actors – actors are free to do what they want, we can only control our system
  2. Use Cases: top
    • A use case typically represents a complete functionality that the actor can use in a system
    • A use case must deliver something of value to an actor
    • A group of use cases (functions) for a system defines the ways the system can be used.
    Ask the following questions to identify the system's use cases:
    • What are the goals of each actor?
    • How can each actor achieve their goal?
    • Will any actor create, store, modify, delete, or read information from the system?
    • Does any actor need to be notified about certain occurrences in the system?

Once you have identified your actors and their goals, you have now created your initial list of high level use cases. Remember, effective use cases must have understandable actors and goals.

  • 3. Use Case Relationships (Associations): top
    • Indicate the communication between an actor and a use case
    • Can flow in both directions - actor to use case and use case to actor
    • Represented with a solid line connecting the two parties and in some cases with an arrowhead

    Three Types of Use Case Associations top

    • 3.1. Generalization Relationship
    • “A taxonomic relationship between a more general classifier and a more specific classifier. Each instance of the specific classifier is also an indirect instance of the general classifier. Thus the specific classifier indirectly has features of the more general classifier.” ~ UML2.0

        ♣ In a generalization relationship, think of the general use case as a “parent” use case
        ♣ Specific use cases inherit the behavior of the general use case

    • 3.2. Include Relationship
    • Include relationships describe a required (non-optional) behavior included in the base use case. It is a relationship created between a use case (base) that “uses” the functionality of another use case (included). Generally, it is assumed that the included use case will be called every time the basic path is run.

        ♣ The base use case “uses” the included uses case
        ♣ A base use case cannot function until it gets information from the included use case

    • 3.3. Extend Relationship
    • In this relationship, an extension use case is created to extend the behavior of the extended (base) use case when exceptional circumstances are encountered. An extend relationship is used to represent an optional or exceptional behavior.

  • If you are still confused about the different types of relationships, please see the comments - I've added another example that will make things more clear. :)
  • 4. System Boundary: top
  • The system boundary box is a rectangular shape drawn around the concerned use case to represent the system’s scope. Only the use cases contained within that boundary box are considered to be in-scope, and anything outside is considered out-of-scope.

    Step-by-step Guide to Creating a Use Case top

    Tools to Create a Use Case top

    There are several tools that can be used to develop UML diagrams. Depending on the organization you are working for, they may use any of the following tools:

  • Rational Rose: it comes with the Rational Suite (created by IBM). Rational Rose is the most respected in the business, but it is only used for huge projects because its license is very expensive
  • Ms Visio: it is the most common used by many organizations (Microsoft Product)
  • Visual Paradigm: it is very similar to Ms Visio for Macintosh users
  • The best of all - Draw.io: is a FREE web app that is very similar to MS Visio

  • You might also like to read: