SWEB652 Requirements Engineering

System Modeling
Use Cases
UML diagram

1
Use Case Modeling

SWEB652 Requirements Engineering

• A use case defines a goal-oriented set of interactions between
external actors and the system under consideration.
• A use represents system functionality as
• transactions (“use cases”) that are meaningful to
• entities (“actors”) that interact with the system

2
Use Case Modeling:
Main Elements

SWEB652 Requirements Engineering

3
Use Case Modeling:
Main Relationships

SWEB652 Requirements Engineering

4
Use Case Modeling

SWEB652 Requirements Engineering

• The main elements
• actor
• relationships
• use case
• use case diagram
• use case description Use case name
Actors
• use case internals can be specified by Precondition
• text and/or Postcondition
• interaction diagrams Normal Flow
-
-

5
 Use Case Diagram

SWEB652 Requirements Engineering

 Use Case Diagram

SWEB652 Requirements Engineering

Actors

SWEB652 Requirements Engineering

• Role that a human/hardware/software system plays during its
interaction with the system
• Actors do not need to be humans!

• Actors carry out use cases

• look for actors, then their use cases

• Actors can get value (receive output)

• from the use case or participate in it

8
Actor Association
• Actors can be connected to use cases

SWEB652 Requirements Engineering

• only by association

• Association will represent

• communication means
• (both can send messages to, or receive
messages from the other one)
**Direction of the arrow does not mean direction of data flow

9
 Use Case Examples

10

SWEB652 Requirements Engineering

SWEB652 Requirements Engineering
Active vs. Passive actor

SWEB652 Requirements Engineering

• Active actor: initiate the use case (as the clerk below)
• Passive actor: participate but does not initiate the user case
(as the accounts system in the enter order use case)

.The arrowhead is a de-facto standard but not part of UML Specs

12
Actor
specialization/inheritance

SWEB652 Requirements Engineering

,The specialized actor, such as Club Customer in the example
inherits the use cases of the generalized actor, such as Customer.
The arrowhead should point at the more general actor, such as
.Customer
inherits behavior and meaning of the parent use case
may add or override the parent’s behavior 13
may be substituted any place the parent appears
<<include>> Relationship

SWEB652 Requirements Engineering

• Can be used to
• avoid describing the same flow of events several times,
• by putting the common behavior in a use case of its own
• Avoids copy & paste of parts of use case descriptions
• The original use case is not complete without the included one
(i.e., depends on it)
• Included use cases can be base use cases in their own right

14
<<include>> Example

SWEB652 Requirements Engineering

• Use Case: Track order
• Precondition:
• Financial Officer is logged in
• Main flow:
1. Obtain and verify order number
2. Include (Validate client)
3. For each part in the order,…

15
<<extend>> Relationship

SWEB652 Requirements Engineering

• Allows to model an optional part of a use case
• Allows to model conditional subflows (alternatives)
• Extending use case is dependent on the base use case

Pay By Debt
>extend<<

Pay By Cash

>extend<<
Pay By Visa
Customer
16
 Order Meal Use Case Example

17

SWEB652 Requirements Engineering