Use Case Modeling
Requirements Engineering
1
Use Case Modeling- Definition
Use case diagram is a behavioral UML diagram type
Frequently used to analyze various systems.
Enable you to visualize the different types of roles in a system &
how those roles interact with the system.
Use case diagram model help capture the requirements of the
system.
Describe the high-level functions and scope of a system.
Identify the interactions between the system and its actors.
Use cases & actors describe what the system does & how the
actors use it.
But NOT how the system operates internally.
The purposes of use case diagrams
Used to capture the requirements of a system.
Used to get an outside view of a system.
Validate a systems architecture (hardware, software,
functions, data
& people).
Identify the external and internal factors influencing the
system.
Show the interaction among the requirements and actors.
Drive implementation and generate test cases.
Provide a high-level view of the system & convey in non-
When To Use Use-Case Diagram?
• Before starting a project
• It is very important that all participants are very clear on what
they want to do and
• How they want to do before starting the project.
• While gathering requirements
• You can create use-case diagrams to capture the system
requirements and
• To present to others what the system should do.
• During the analysis and design phases
• You can use the use cases and actors from your use-case
diagrams to identify the classes that the system requires.
• Classes are a collection of actors and processes (capable of
performing the behavior needed to make the system function
successfully). A blueprint used to create an object (Student,
College, Customer, Bank, etc.).
• During the testing phase
Importance of Use Case Diagrams
• To identify functions and how roles interact with them
• The primary purpose of use case diagrams.
• High-level view of the system
• Highlight the roles that interact with the system.
• Highlight the functionality of the system.
• Without going deep into inner workings of the system.
• To identify internal and external factors
• A use case diagram shows the interaction between the
system & entities external to the system.
• External entities are referred to as actors which represent
roles.
Guidelines for drawing Use Case diagrams
General guidelines
Determine the system boundary.
Ensure that individual actors have well-defined
purpose.
A use case diagram should be as simple as possible.
A use case diagram should be complete.
A use case diagram should represent all interactions
with the use cases.
Associate the actors and use cases
There shouldn't be any actor/use case floating
without any connection.
Use include relationship to encapsulate common
behavior among use cases , if any.
Use Case Modeling
Use to represent software requirements
Show how user interact with system
There are two components of use-case modeling:
Use-case Diagrams
Textual Description - templates or structured
format for documenting the details of individual
use cases.
Use Case Diagram Notation
Use-Case Diagram
Notation
Actors Use-cases
Only Use Cases (functions) - turn into code.
Actors - never turn into code.
Use Case Diagram Elements
Use cases
Each use case describes a unit of complete and useful
functionality that system provides to its users; and
How external user interacts with a system to achieve a
desired result.
(use case examples: Place order, Deposit funds, Buy
ticket, etc..)
Actors
Represents a role of a user that interacts with the system
that you are modeling.
Can be a human user, an organization, a machine, or
another external system.
Subsystems
A subsystem is used for defining one part of a (large)
system.
Use Case Diagram Elements
Relationships in use-case diagrams
A relationship is a connection between model
elements.
A relationship is a type of model element that adds
semantics to a model by defining the structure and
behavior between the model elements.
Used to represent a connection between structural,
behavioral, or grouping things.
It is also called a link that describes how two or
more things can relate to each other during the
Actors
Actor is any entity that performs a role in one given
system.
Actors are anything that DIRECTLY interacts with the
system.
Actors play a role not an instance.
Actor could be a person, organization or an external
system.
Actors are usually drawn like skeleton shown below.
Types of Actors
Primary Actors
Actors who get service from system.
Initiate a use case and hence are somewhat
independent.
Placed at the left side to the boundary of the system.
(in ATM system primary actor is CUSTOMER).
Secondary Actors (supporting actor)
Actors who give services to system.
Used by the system.
They do not interact with the system on their own.
Placed to the right of the boundary of the system.
Actors that the system needs assistance from to achieve
the primary actor’s goal. (administrative or maintenance
tasks).
Types of Actors
Offstage actors
Actor who do not interact with system
Actor who has an interest in the behavior but is not primary or
secondary.
Neither initiates nor helps complete the use case but may be
notified about some aspect of it (e.g., for keeping records).
Why identify? To ensure that all necessary interests are
identified and satisfied.
Government does not interact with system but imposes tax on
the system.
A stakeholder with interest in the outcome that must be
satisfied, but who is not playing an active role in the use case.
Use-Case
System function (process - automated or manual).
A use case represent a major function that a system performs to
achieve the user’s goal.
A use case must yield an observable result that is of value to the
user of the system.
Use to capture functional requirement of the system.
Use-case should not be too big or too small. (One use case = 1
service)
It is placed inside the system boundary.
Use-
It is labeled with a descriptive phrase. case
It’s drawn as an oval and named with the function.
The Association Relationship
Links an actor with the use case(s) with which it interacts.
An association is the relationship between an actor & a
business use case.
Association indicates that an actor can use a certain
functionality of the business system.
The only relationship allowed is between actors and use
cases
Use Case Modeling
Reuse Mechanisms
Three reuse mechanisms
• Include Relationship
• Extend Relationship
• Generalization Relationship
The Include Relationship
The include relationship is between two use cases.
A base use case includes a second use case.
Include helps in breaking a large use case into smaller
manageable use cases.
A base use case can have multiple included use cases.
Include also helps in not repeating a specific behavior,
which is commonly referred to by different use cases.
Include relationship between use-cases which is shown by
a dashed arrow with an open arrowhead.
from the base use-case to the included use-
case.
When the base case is executed, the included case will happen
every time.
The Include Relationship
Important
Include relationship between use cases denote that
the behavior of the included use case is part of the
base use case.
Include also helps in not repeating a specific behavior,
which is commonly referred to by different use cases.
The including use case needs the included use case
for completion.
The Include Relationship
<<include>>
Base Inclusion
Use Case Use Case
The Include Relationship
The included behavior can be added
anywhere to the Base use case.
<<include>>
Base Inclusion
Use Case Use Case
Incomplete Complete
-
The Include Relationship
The <<include>> relationship adds additional
functionality not specified in the base use case.
The <<Include>> relationship is used to include
common behavior from an included use case into a
base use case in order to support the reuse of common
behavior.
The Include Relationship
• Find a product" includes the "Search for product" use
case.
• “Find a product” is intended for reusing behavior
modeled by another use case.
• Include means compulsory.
The Include Relationship
Examples
In ATM, consider a use case called ‘Withdraw Cash' ,this
use case depends on the 'check available balance’.
In ATM we can not withdraw money if Pin is not entered.
So, we represent the relation between ‘Withdraw Cash’
and ‘Pin’ by include.
The Include Relationship
• Validate Pin could be a tightly coupled component with
withdraw cash.
• Validate Pin could be a tightly couple component with deposit
cash.
• Withdraw cash & deposit cash are functionally decomposed
(broken down) to separate out validate pin.
• Validate Pin could be a reusable action for both withdraw &
Withdraw <<include>>
deposit. Cash Validate
PIN
l ud e > >
< < inc
Deposit
Cash This is OK!
The Extend Relationship
Extend relationship adds up behavior sequence to the base
use case.
It is similar to the include relationship but the direction of
adding behavior to the base use case is opposite.
The Extension use case extends the Base use case with
additional behavior.
Depict with a directed arrow having a dotted line.
The tip of arrowhead points to the base use case.
Base
<<extend>> Extension
Use Use Case
Case [Condition]
The Extend Relationship
In the include relationship, the base use case incorporates
the include use case every time.
When the base case is executed , the extend case will
happen sometimes but not every time.
Include means compulsory and Extend means Optional.
Both ‘include’ and ‘extended’ relationship both add up behavior
sequence to the base use case.
Base Extensio
Use <<extend>> n Use
Case Case
[Condition]
Complete Incomplete
+
The Extend Relationship
The Extend Relationship
In ATM after transaction Printing receipt is optional and it
does not affect transaction.
The Generalization Relationship
The behavior in the child use case is a specific version of
the behavior in the general use case.
A generalization relationship means that a child use case
inherits the behavior and meaning of the parent use case.
The child may add or override the behavior of the parent.
General
Use Case
Specific
Use
Case
Generalization Relationship Examples
Generalization Relationship
Sub-class inherits from super-class (attributes,
functions)
Actor Generalization
An actor can inherit the role of the other actor
Use case description – Flow of Events :
When and how the use case starts and ends.
What interaction the use case has with the
actors.
What data is needed by the use case.
The normal sequence of events for the use
case.
The description of any alternate or exceptional
flows.
Three types of flow of event:
Basic Flow of Events.
Alternate Flow of Events.
Exceptional Flow of Events (extension points).
Flow of Events
The Basic Flow
An unconditional set of steps that describe how the use
case goal
can be achieved and all related stakeholder interests can be
satisfied.
Each step is essential to achieving the use case goal (no
step can be skipped), and each step succeeds.
Flow of Events
An Alternative Flow
A conditional set of steps that are an alternative to one or
more steps in another flow (the alternative flow is
performed instead of the other step or steps), after which
the use case continues to pursue its goal.
Flow of Events
An Exception Flow
A conditional set of steps that are a response to the
failure of a step in another flow (the exception flow is
performed after the other step), after which the use case
abandons the pursuit of its goal.
Failed step
Abandon the pursuit of its goal
Does not join another flow
Example:
What will be the basic , alternate and
exceptional Flow of Events for Online Ticket
Booking?
Examples: Ticket Booking
Basic Flow
1. The use case begins when the customer selects the option
to view flight information.
2. The system prompts for the departure and destination
cities and the departure and return dates.
3. The user enters the departure and destination city,
departure date, and return date.
4. The system displays a list of available flights, including the
fare.
A1: There are no available flights.
5. The user selects the flight they would like to reserve.
6. The system displays all available fare options for that flight.
7. The user selects the fare option they would like to reserve.
A2: The user selects a free ticket through
frequent−flyer membership.
Ticket Booking …
8. The system displays the fare that the user will pay.
9. The user confirms the rate.
[Link] system prompts for a credit card type, number,
name, and expiration date.
[Link] user enters the card type, number, name, and
expiration date.
[Link] system submits the credit purchase.
A3: Account not found
A4: Insufficient funds
E1: Credit system not accessible
13. The system reserves a seat on the plane for the user.
14. The system generates and displays a confirmation code
to the user.
15. The user confirms receipt of the code.
16. The use case ends.
Ticket Booking….
Alternate Flows
A1: No available flights
1. The system displays a message that there are no
available flights for the departure and destination
cities, departure date, and return date entered.
2. The user confirms the message.
3. The flow returns to the primary flow, step 2.
A2: Free ticket through frequent−flyer membership
1. The system prompts for the frequent−flyer number.
………….
Template
Use Case Name Name should be an action (a verb) not a noun. “Register Course” is
a good name, “Registration” is not.
Actors Actor 1, Actor 2, Actor 3…..
Description Just a one/two sentence brief description in case the reader doesn’t want to
go in great detail.
Dependencies Includes Use Case X
Extends Use Case Y
…
Preconditions A situation that needs to be true BEFORE the use case can execute.
Normal Flow 1. User does this
2. System does that
3. Use does this
4. …
Alternative Flow - At BF step X, if user chooses to do this then
1. System does this
2. Use does that
Return to BF at step Y (or it can be that the use case terminates)
Extension Points EP1: Extension point 1 name
EP2: Extension point 2 name
Post-conditions A situation that needs to be true upon completion of the use case but
BEFORE the use case can terminate.
Other Requirements Here you can specify non-functional requirements relating to that use case
