What is the Use Case Diagram?

Use Case Diagram captures the system’s functionality and requirements by

using actors and use cases. Use Cases model the services, tasks, function
that a system needs to perform. Use cases represent high-level functionalities
and how a user will handle the system. Use-cases are the core concepts of
Unified Modelling language modeling.
In this UML Diagram tutorial, you will learn more about:

 Why Use-Case diagram?

 Use-case diagram notations
 How to draw a use-case diagram?
 Tips for drawing a use-case diagram
 An example of a use-case diagram
 When to use a use-case diagram?

Why Use-Case diagram?

A Use Case consists of use cases, persons, or various things that are
invoking the features called as actors and the elements that are responsible
for implementing the use cases. Use case diagrams capture the dynamic
behaviour of a live system. It models how an external entity interacts with the
system to make it work. Use case diagrams are responsible for visualizing the
external things that interact with the part of the system.

Use-case diagram notations

Following are the common notations used in a use case diagram:

Use-case:

Use cases are used to represent high-level functionalities and how the user
will handle the system. A use case represents a distinct functionality of a
system, a component, a package, or a class. It is denoted by an oval shape
with the name of a use case written inside the oval shape. The notation of a
use case in UML is given below:
 UML UseCase Notation
Actor:

It is used inside use case diagrams. The actor is an entity that interacts with
the system. A user is the best example of an actor. An actor is an entity that
initiates the use case from outside the scope of a use case. It can be any
element that can trigger an interaction with the use case. One actor can be
associated with multiple use cases in the system. The actor notation in UML is
given below.

UML Actor Notation

How to draw a use-case diagram?

To draw a use case diagram in UML first one need to analyse the entire
system carefully. You have to find out every single function that is provided by
the system. After all the functionalities of a system are found out, then these
functionalities are converted into various use cases which will be used in the
use case diagram.

A use case is nothing but a core functionality of any working system. After
organizing the use cases, we have to enlist the various actors or things that
are going to interact with the system. These actors are responsible for
invoking the functionality of a system. Actors can be a person or a thing. It can
also be a private entity of a system. These actors must be relevant to the
functionality or a system they are interacting with.

After the actors and use cases are enlisted, then you have to explore the
relationship of a particular actor with the use case or a system. One must
identify the total number of ways an actor could interact with the system. A
single actor can interact with multiple use cases at the same time, or it can
interact with numerous use cases simultaneously.

Following rules must be followed while drawing use-case for any system:

1. The name of an actor or a use case must be meaningful and relevant to

the system.
2. Interaction of an actor with the use case must be defined clearly and in
an understandable way.
3. Annotations must be used wherever they are required.
4. If a use case or an actor has multiple relationships, then only significant
interactions must be displayed.

Tips for drawing a use-case diagram

1. A use case diagram should be as simple as possible.
2. A use case diagram should be complete.
3. A use case diagram should represent all interactions with the use case.
4. If there are too many use cases or actors, then only the essential use
cases should be represented.
5. A use case diagram should describe at least a single module of a
system.
6. If the use case diagram is large, then it should be generalized.

An example of a use-case diagram

Following use case diagram represents the working of the student
management system:
 UML UseCase Diagram
In the above use case diagram, there are two actors named student and a
teacher. There are a total of five use cases that represent the specific
functionality of a student management system. Each actor interacts with a
particular use case. A student actor can check attendance, timetable as well
as test marks on the application or a system. This actor can perform only
these interactions with the system even though other use cases are remaining
in the system.

It is not necessary that each actor should interact with all the use cases, but it
can happen.

The second actor named teacher can interact with all the functionalities or use
cases of the system. This actor can also update the attendance of a student
and marks of the student. These interactions of both student and a teacher
actor together sums up the entire student management application.
When to use a use-case diagram?
A use case is a unique functionality of a system which is accomplished by a
user. A purpose of use case diagram is to capture core functionalities of a
system and visualize the interactions of various things called as actors with
the use case. This is the general use of a use case diagram.

The use case diagrams represent the core parts of a system and the workflow
between them. In use case, implementation details are hidden from the
external use only the event flow is represented.

With the help of use case diagrams, we can find out pre and post conditions
after the interaction with the actor. These conditions can be determined using
various test cases.

In general use case diagrams are used for:

1. Analyzing the requirements of a system

2. High-level visual software designing
3. Capturing the functionalities of a system
4. Modeling the basic idea behind the system
5. Forward and reverse engineering of a system using various test cases.

Use cases are intended to convey desired functionality so the exact scope of
a use case may vary according to the system and the purpose of creating
UML model.

a use case with example

Use case: A use case outlines the success and failure scenarios that can occur
when the actor(s) interact with the system. In this section, you'd establish the main
success scenario, i.e., the most desirable outcome between the actor and the system

What Is a Use Case?

By Nicky Daly, April 25, 2022
Articulating how a customer will interact with a product or system is essential for
requirements gathering and high-level stakeholder communication. A use case
model diagram is a visual representation of a product’s users, how they will
interact with the product, and what the product does. But what is a use case,
exactly, and why is it an important tool for project managers?

Though commonly used to break down complex ideas in a software development

environment, use cases in project management can be just as vital for gathering
requirements and establishing a project’s scope.

Learn more about how to write a use case and how a use case model tool can be
used when establishing essential project requirements.

What is a use case? Use cases

explained
A use case is a description of the ways in which a user interacts with a system or
product. A use case may establish the success scenarios, the failure scenarios,
and any critical variations or exceptions. A use case can be written or made
visual with the help of a use case model tool.

The history of the use case

Swedish computer scientist Ivar Jacobson presented the first article on use
cases in 1987, describing how the technique was used at telecommunications
company Ericsson to capture system requirements. In 1992, Jacobson co-
authored the book "Object-Oriented Software Engineering — A Use Case Driven
Approach," which helped popularize use cases for specifying functional
requirements in software development.
Jacobson later joined American software engineers Grady Booch and James
Rumbaugh to create the Unified Modeling Language (UML), which introduced a
standard way to visualize the design of a system. Since then, the technique has
been adapted into use case writing "templates" to streamline the capture of high-
level requirements.

Remove barriers, find clarity, exceed goals

Anything is possible with the most powerful work management software at your
fingertips

Try for free

What is the purpose of a use case?

The purpose of a use case is to:

 Manage scope

 Establish requirements

 Outline the ways a user will interact with the system

 Visualize system architecture

 Communicate technical requirements to business stakeholders

 Risk management

Why do project managers need to know

about use cases?
Project managers need to know about use cases because they help
communicate strategy to stakeholders and bridge the gap between business
justification and technical requirements.

PMI also notes that “use cases provide a structure for gathering customer
requirements and setting the project scope.” But what does that mean in practical
terms?

Let’s say that you are a project manager for an education tech firm. Your
company’s latest product idea is an app for students where they can receive live
tuition for a monthly subscription fee. Creating a use case for this application can
tell stakeholders and the project team who the customer is, how the customer will
interact with the product, and what the scope gap meaning and requirements of
the project will be.

How to write a use case for a project

When presented in written form, a use case can be a helpful piece of project
documentation. Use cases are a common requirements artifact, and they can
smoothen communication across technical and business stakeholders.

Depending on the intended audience and system under discussion, the use case
can be as detailed or basic as needed. A use case document should establish
and identify a few key components — these are:

 System: A system is the product, service, or software under discussion.

 Actors: An actor is a user or anything else that exhibits behavior when

interacting with the system. The actor could be another system, a piece of
hardware, or an entire organization. There are four types of actors: a system
under discussion, an internal actor, a primary actor, and a secondary actor.
The most commonly referred to are the latter two systems. A primary actor
 initiates the interaction with the system, while a secondary actor may provide
a service to the system.

 Scenario: In “Applying UML and Patterns,” Larman notes that “a scenario is

a specific sequence of actions and interactions between actors and the
system under discussion; it is also called a use case instance.”

 Use case: A use case outlines the success and failure scenarios that can
occur when the actor(s) interact with the system. In this section, you’d
establish the main success scenario, i.e., the most desirable outcome
between the actor and the system. You would also establish the alternative
paths, which explain what happens in the event of failure or error.

Let’s take a look at a simple use case

example:
 Use case for meal delivery application: Individuals can use an app to
place food orders directly to restaurants. When the user places an order,
they are prompted to pay through the app or pay when the food arrives.
Once that is confirmed, the restaurant will receive a request through their
system. The food will then be prepared, packaged, and delivered to the
individual. In this case, the app must be able to receive orders, process
payments, and communicate with the restaurant electronically.

 System: Food delivery application

 Primary actor: Customer ordering a meal

 Scenario: The user browses restaurant options. Once the preferred

restaurant is selected, they place an order through the application. The user
pays online or verifies they will pay in person. The order is sent from the app
to the restaurant’s internal system. The restaurant worker receives and
processes the electronic order.

This use case illustrates how both the customer and restaurant employee
(the actors) interact with the food delivery application (the system) and the
 expected outcome of each interaction.

This helps sketch a framework for what is expected in the development

stage. The app must be able to process payments, for example.

What is a use case model?

A use case model is a visual representation of the interactions between an actor
and a system. As PMI also notes, use case models depict processes, which
helps to further express preconditions and triggers.

A use case model is commonly expressed using UML (Universal Modeling

Language). In these visualizations, there are three main components: the
system, the actors, and the use case.

The system is represented by a rectangle or “boundary box." Actors are shown

as stick people outside of the boundary box, while the use cases are presented
as text in ovals within the box. Solid and dashed lines represent the association
between the actors and the system’s use cases.

Use case model example:

 (Source: Visual Paradigm Online)

What is the difference between a use

case model and a use case diagram?
A use case diagram is simply a type of use case model. A use case model
diagram uses text and shapes to represent the relationship between a user and a
system.

Primarily, use case model diagrams are used to:

 Visualize the flow and behavior of the system

 Illustrate the functionality of the system

  Represent key system-user interactions

Depending on the system, a use case model diagram can vary in complexity,
showing basic associations or expanding to show multiple exceptions.

Use Case
Last updated: September 23, 2014
What Does Use Case Mean?
A use case is a software and system engineering term that describes how a
user uses a system to accomplish a particular goal. A use case acts as a
software modeling technique that defines the features to be implemented
and the resolution of any errors that may be encountered.

Advertisement
Techopedia Explains Use Case
Use cases define interactions between external actors and the system to
attain particular goals. There are three basic elements that make up a use
case:

 Actors: Actors are the type of users that interact with the system.
 System: Use cases capture functional requirements that specify the
intended behavior of the system.
 Goals: Use cases are typically initiated by a user to fulfill goals
describing the activities and variants involved in attaining the goal.

Use cases are modeled using unified modeling language and are represented
by ovals containing the names of the use case. Actors are represented using
lines with the name of the actor written below the line. To represent an
actor's participation in a system, a line is drawn between the actor and the
use case. Boxes around the use case represent the system boundary.

Characteristics associated with use cases are:

 Organizing functional requirements

 Modeling the goals of system user interactions
 Recording scenarios from trigger events to ultimate goals
 Describing the basic course of actions and exceptional flow of events
 Permitting a user to access the functionality of another event
The steps in designing use cases are:

 Identify the users of the system

 For each category of users, create a user profile. This includes all roles
played by the users relevant to the system.
 Identify significant goals associated with each role to support the
system. The system’s value proposition identifies the significant role.
 Create use cases for every goal associated with a use case template
and maintain the same abstraction level throughout the use case.
Higher level use case steps are treated as goals for the lower level.
 Structure the use cases
 Review and validate the users

Purpose of Use Case Diagrams

The purpose of use case diagram is to capture the dynamic aspect of a system.
However, this definition is too generic to describe the purpose, as other four diagrams
(activity, sequence, collaboration, and Statechart) also have the same purpose. We will
look into some specific purpose, which will distinguish it from other four diagrams.
Use case diagrams are used to gather the requirements of a system including internal
and external influences. These requirements are mostly design requirements. Hence,
when a system is analyzed to gather its functionalities, use cases are prepared and
actors are identified.
When the initial task is complete, use case diagrams are modelled to present the
outside view.
In brief, the purposes of use case diagrams can be said to be as follows −
 Used to gather the requirements of a system.
 Used to get an outside view of a system.
 Identify the external and internal factors influencing the system.
 Show the interaction among the requirements are actors.

How to Draw a Use Case Diagram?

Use case diagrams are considered for high level requirement analysis of a system.
When the requirements of a system are analyzed, the functionalities are captured in use
cases.
We can say that use cases are nothing but the system functionalities written in an
organized manner. The second thing which is relevant to use cases are the actors.
Actors can be defined as something that interacts with the system.
Actors can be a human user, some internal applications, or may be some external
applications. When we are planning to draw a use case diagram, we should have the
following items identified.
  Functionalities to be represented as use case
 Actors
 Relationships among the use cases and actors.
Use case diagrams are drawn to capture the functional requirements of a system. After
identifying the above items, we have to use the following guidelines to draw an efficient
use case diagram
 The name of a use case is very important. The name should be chosen in such a
way so that it can identify the functionalities performed.
 Give a suitable name for actors.
 Show relationships and dependencies clearly in the diagram.
 Do not try to include all types of relationships, as the main purpose of the diagram
is to identify the requirements.
 Use notes whenever required to clarify some important points.
Following is a sample use case diagram representing the order management system.
Hence, if we look into the diagram then we will find three use cases (Order,
SpecialOrder, and NormalOrder) and one actor which is the customer.
The SpecialOrder and NormalOrder use cases are extended from Order use case.
Hence, they have extended relationship. Another important point is to identify the
system boundary, which is shown in the picture. The actor Customer lies outside the
system as it is an external user of the system.

Where to Use a Use Case Diagram?

As we have already discussed there are five diagrams in UML to model the dynamic
view of a system. Now each and every model has some specific purpose to use.
Actually these specific purposes are different angles of a running system.
To understand the dynamics of a system, we need to use different types of diagrams.
Use case diagram is one of them and its specific purpose is to gather system
requirements and actors.
Use case diagrams specify the events of a system and their flows. But use case
diagram never describes how they are implemented. Use case diagram can be
imagined as a black box where only the input, output, and the function of the black box
is known.
These diagrams are used at a very high level of design. This high level design is refined
again and again to get a complete and practical picture of the system. A well-structured
use case also describes the pre-condition, post condition, and exceptions. These extra
elements are used to make test cases when performing the testing.
Although use case is not a good candidate for forward and reverse engineering, still
they are used in a slightly different way to make forward and reverse engineering. The
same is true for reverse engineering. Use case diagram is used differently to make it
suitable for reverse engineering.
In forward engineering, use case diagrams are used to make test cases and in reverse
engineering use cases are used to prepare the requirement details from the existing
application.
Use case diagrams can be used for −
 Requirement analysis and high level design.
 Model the context of a system.
 Reverse engineering.
 Forward engineering.