USE CASES

A Simple Use Case

The essentials of the use case description consist of
the following:
■ The name of the use case
■ The name of the actor.
■ A one-sentence use case summary, which provides a brief description.
■ The description of the main sequence of events. For this use case, the first step
is the operator request and the second step is the system response.
■ The description of any alternative to the main sequence. For this use case, there
could be an alternative at step 2, which would be executed if there is a monitoring
emergency.
USE CASES – SIMPLE USECASES
 USE CASES
A Simple Use Case – Example:
• Use case name: View Alarms
• Summary: The monitoring operator views outstanding alarms.
• Actor: Monitoring Operator
• Main sequence:
1. The monitoring operator requests to view the outstanding alarms.
2. The system displays the outstanding alarms. For each alarm, the system
displays the name of the alarm, alarm description, location of alarm, and
severity of alarm (high, medium, low).
• Alternative sequences:
• Step 2: Emergency situation. System displays emergency warning message
to operator.
 DOCUMENTING USE CASES
1.
2.
01
Use case name
Summary
04
3. Dependency
4. Actors
5. 02Preconditions
6. Description of main sequence
05
7. Description of alternative sequences

03
8. Nonfunctional requirements
9. Postcondition
10. Outstanding questions
 DOCUMENTING USE CASES
Use case name: Each use case is given a name.
01 04
Summary: A brief description of the use case, typically one or two sentences.
Dependency: This optional section describes whether the use case depends
on other use cases – that is, whether it includes or extends another use case.
Actors: This section names the actors in the use case. There is always a primary
02 05
actor that initiates the use case. In addition, there may be secondary
actors that also participate in the use case. For example in the Withdraw
Funds use case, the ATM Customer is the only actor
Preconditions: One or more conditions that must be true at the start of use
03
case, from the perspective of this use case; for example, the ATM machine
is idle, displaying a “Welcome” message.
 DOCUMENTING USE CASES
Description of main sequence: The bulk of the use case is a narrative
01 04
description of the main sequence of the use case, which is the most usual
sequence of interactions between the actor and the system. The description
is in the form of the input from the actor, followed by the response of the
system.
02 05
Description of alternative sequences: Narrative description of alternative
branches off the main sequence. There may be several alternative branches
from the main sequence. For example, if the customer’s account has insufficient
funds, display apology and eject card. The step in the use case at which
03
the alternative sequence branches off from the main sequence is identified
as well as a description of the alternative
 DOCUMENTING USE CASES
01 04
Nonfunctional requirements: Narrative description of nonfunctional
requirements, such as performance and security requirements.

02 05
Postcondition: Condition that is always true at the end of the use case (from
the perspective of this use case) if the main sequence has been followed; for
example, customer’s funds have been withdrawn.
Outstanding questions: During development, questions about the use case
are documented for discussions with users.
03
DOCUMENTING USE CASES
 DOCUMENTING USE CASES
01● In the main sequence of the Make Order04
Request use case,
the customer makes an order request to purchase items
from an online catalog and has sufficient credit to pay for
02 the items
05
● The alternative sequences deal with other situations, which
occur less frequently: the customer has no account and has
to create one, or the customer has an invalid credit card
03
 DOCUMENTING USE CASES EG
01● In the main sequence of the Make Order04
Request use case,
the customer makes an order request to purchase items
from an online catalog and has sufficient credit to pay for
02 the items
05
● The alternative sequences deal with other situations, which
occur less frequently: the customer has no account and has
to create one, or the customer has an invalid credit card
03
 DOCUMENTING USE CASES - EG
Use case name: Make Order Request

01 04
Summary: Customer enters an order request to purchase items from the online shopping system. The customer’s credit
card is checked for sufficient credit to pay for the requested catalog items.
Actor: Customer
Precondition: The customer has selected one or more catalog items.
Main sequence:
1. Customer provides order request and customer account Id to pay for purchase.

02 05
2. System retrieves customer account information, including the customer’s credit card details.
3. System checks the customer’s credit card for the purchase amount and, if approved, creates a credit card purchase
authorization number.
4. System creates a delivery order containing order details, customer Id, and credit card authorization number.
5. System confirms approval of purchase and displays order information to customer.

03
Alternative sequences:
Step 2: If customer does not have account, the system creates an account.
Step 3: If the customer’s credit card request is denied, the system prompts the customer to enter a different credit card
number. The customer can either enter a different credit card number or cancel the order.
Postcondition: System has created a delivery order for the customer.
 THE INCLUDE
08
RELATIONSHIP
The Inlude Relationship
 The Inlude Relationship
01 04
● A common sequence of interactions can be extracted from several of the
original use cases and made into a new use case, which is called an inclusion
use case.

02 05
● In programming terms, an inclusion use case is analogous to a library routine,
and a base use case is analogous to a program that calls the library routine.

03 06
07
 The Inlude Relationship
01 04
● It is then possible to define a more concise version of the old use case, with
the common interaction sequence removed. This concise version of the old
use case is referred to as a base use case (or concrete use case), which
includes the inclusion use case.
02 05
● Inclusion use cases always reflect functionality that is common to more than
one use case.

03 06
07
 The Inlude Relationship - Doc
01
Use case name: Withdraw Funds 04
Summary: Customer withdraws a specific amount of funds from a valid
bank account.
02
Actor: ATM Customer
Dependency: Include Validate PIN use case. 05
Precondition: ATM is idle, displaying a “Welcome” message.
Main sequence:
03
1. Include Validate PIN use case.
2. Customer selects Withdrawal.
06
3. …..
07
 The Inlude Relationship - Doc
01 04
Use case name: Validate PIN
Summary: System validates customer PIN.
Actor: ATM Customer
Precondition: ATM is idle, displaying a “Welcome” message.
Main sequence:

02 05
1. Customer inserts the ATM card into the card reader.
2. If system recognizes the card, it reads the card number.
3. System prompts customer for PIN.
4. Customer enters PIN.
5. System checks the card’s expiration date and whether the card has been reported as lost or stolen.

03 06
6. If card is valid, system then checks whether the user-entered PIN matches the card PIN maintained
by the system.
7. If PIN numbers match, system checks what accounts are accessible with the ATM card.

07
8. System displays customer accounts and prompts customer for transaction type: withdrawal, query, or
transfer.
Alternative sequences: ….
 THE EXTEND
09
RELATIONSHIP
The Extend Relationship
 The Extend Relationship
0 Base Use Case: Checkout Customer
01
Use case name: Checkout Customer
Summary: System checks out customer.
Actor: Customer

02 05
Precondition: Checkout station is idle, displaying a “Welcome” message.
Main sequence:
1. Customer scans selected item.
2. System displays the item name, price, and cumulative total.
06
3. Customer repeats steps 1 and 2 for each item being purchased.
4. Customer selects payment.

07
5. System prompts for payment by cash, credit card, or debit card.
6. «payment»
7. System displays thank-you screen.
 The Extend Relationship
0 Extension Use Case: Pay by Cash
01
Use case name: Pay by Cash
Summary: Customer pays by cash for items purchased.
Actor: Customer
02
Dependency: Extends Checkout Customer.
05
Precondition: Customer has scanned items but not yet paid for them.
Description of insertion segment:
1. Customer selects payment by cash.
06
2. System prompts customer to deposit cash in bills and/or coins.
3. Customer enters cash amount.

07
 The Extend Relationship
01 04
● The extend relationship is used to model alternative paths that a use case
might take.
● The use case that is extended is referred to as the base use case, and the use
case that does the extending is referred to as the extension use case.
02
● The extend relationship can be used as follows: 05
❏ To show a conditional part of the base use case that is executed only
under certain circumstances
❏ To model complex or alternative paths.
03 06
07
 Specifying NonFunctional Requirement

Validate PIN use case – NonFunctional Reqs

Security requirement: System shall encrypt ATM card number and PIN.
Performance requirement: System shall respond to actor inputs within 5
seconds.
Requirement Definition
Business requirement A high level business objective of the organization that builds a product
One or more logically related system capabilities that provide value to a user
Feature and are described by set of functional requirements
Functional
requirement A descrition of behaviour that a system will exhibit under specific conditions
Non Functional A descrition of property or characteristic that a system must exhibit or a
requirement constraint that it must be respect
A kind of non functional requirement that describes a service or performance
Quality attribute characteristic of a product
User requirement …
System requirement …
…… …
Throwaway prototyping