Use Case Diagram For Cont

In this article, I'll discuss the following:

What is a Use Case?
Why Create a Use Case?
What are the Components of a Use Case?

Actors
Use Cases
Relationships (Associations)
Boundaries

Step-by-step Guide to Creating a Use Case
Tools to Create Use Cases

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:

The system will be used by three types of actors: Waiters, Customers and a Cook
Customers will place their order. Customers can also order a drink
Customers will enter their information and pay for food
Waiters will recieve the order and send it to the Cook
The Cook will prepare the food and send a notification to the Waiter
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.

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

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