REQUIREMENT ENGINEERING

USE CASE

LECTURE 2

1
REQUIREMENT ENGINEERING

(SCENARIOS AND USE CASES)

2
 DESCRIBING SCENARIO
• A scenario is a scene that illustrates some interaction with a proposed
system.
• A scenario is a tool used during requirements analysis to describe a
specific use of a proposed system.
• Scenarios capture the system, as viewed from the outside, e.g., by a
user, using specific examples.
• Some organizations have complex documentation standards for
describing a scenario. At least, the description should include:
❑A statement of the purpose of the scenario
❑The individual user or transaction that is being followed through the
scenario
❑Assumptions about equipment or software
❑The steps of the scenario

3
EXAMPLE OF HOW TO DEVELOP A SCENARIO WITH
A CLIENT

• The requirements are being developed for a

system that will enable university students to take
exams online from their own rooms using a web
browser.
• Example:
• Create a scenario for how a typical student
interacts with the system.
• In the next few slides, the questions in blue are
typical of the questions to ask the client while
developing the scenario.
4
5
6
7
 HOW TO BENEFIT FROM THE SCENARIO
• From this scenario with a client, we can see that many functional
requirements must be agreed on before a system can be built, e.g.,
policies, procedures, etc. (as the questions in blue indicate)
• The scenario will often clarify the requirements for the user interface, but
the design of the user interface should not be part of the scenario.
• Scenarios are very useful for analyzing special requirements. Examples:
• Reversals. In a financial system, a transaction is credited to the wrong
account. What sequence of steps are used to reverse the transaction?
• Errors. A mail order company has several copies of its inventory
database. What happens if they become inconsistent?
• Scenarios for error recovery
• Murphy's Law: "If anything can go wrong, it will". Create a scenario for
everything that can go wrong and how the system is expected to handle
 USE CASES AND SCENARIOS

• Scenarios and use cases are both intuitive -- easy to

discuss with clients
• Scenarios are a tool for requirements analysis.
• • They are useful to validate use cases and in checking the
design of a system.
• • They can be used as test cases for acceptance testing.
• Use cases are a tool for modeling requirements.
• • A set of use cases can provide a framework for the
requirements specification.
• • Use cases are the basis for system and program design
9
 USE CASE AND USE CASE DIAGRAM
Use case diagram is a graphical representation that describes the
main system functions from the standpoint of an external observer.
Use case is used to describe how the user interacts with the
system in one of these functions.
It is used during requirements collection to represent external
behavior.
It emphasize on what the system does rather than how it does it
It is created during the early stages of a project - during the
analysis phase rather than during the design phase
It provides a high-level view of what the system does and who
uses it. USE CASE DIAGRAMS CONTAINS:
– Actors – Use cases 10

– Associations/ relationships: among actors and use cases

Two use case
examples

11
 USE CASE DIAGRAM

1- An actor:
Is someone (e.g. human beings) or something (e.g.
other objects or systems) that interact with the
system.
Is entity external to the system who participates in
the story of the use case (receive or input), such as a
person, computer system, or organization.
An actor has a unique name.
❖ In naming actors, choose names that describe the role,
not generic names, such as "user" or "client".
◼e.g. a library clerk, cashier, customer, Passenger,
GPS satellite, bank, customer department . 12
USE CASES FOR EXAM SYSTEM

13
Example – ATM banking system

14
 USE CASE DIAGRAM

• Use cases are drawn as ellipses with the name of the use case
written inside the ellipse
• Use case name typically consists of an active verb and one or
more nouns that concisely describe the system function modelled

System name

Use case 1
Actor 1 Actor 2

Use case 2
15

Actor 3
 USE CASE DIAGRAM
Actors are connected to the use case/s with which they
interact by a line, which represents the relationship
between the actor/s and the use case/s
One actor may be associated with one or more use cases
One use case may be associated with one or more actors

16
17
 USE CASE BEHAVIOUR DESCRIPTION

Each use case in a use case diagram can have an

associated behavior specification
A behavior specification describes the sequence of
actions making up a use case scenario

18
 TYPES OF USE CASE BEHAVIOUR
DESCRIPTION FORMAT

High level Expanded

use case use case

HL use case Expanded use case

describes a process describes a process in
very briefly, usually details. It has an
in 2 or 3 sentences. additional section not
19
present in HL, Flow of
events
 OUTLINE OF TAKE EXAM USE CASE: EXPANDED
DESCRIPTION

• Name of Use Case: Take Exam

• Actor(s): ExamTaker
• Flow of events:
1. ExamTaker connects to the Exam server.
2. Exam server checks whether ExamTaker is already
authenticated and runs authentication process if
necessary.
3. ExamTaker selects a exam from a list of options.
4. ExamTaker repeatedly selects a question and either
types in a solution, attaches a file with a solution, edits
a solution or attaches a replacement file.
20
 EXAMPLE (CONTINUED)

Flow of events (continued):

5. ExamTaker either submits completed exam or saves
current state.
6. When a completed exam is submitted, Exam server
checks that all questions have been attempted and
either sends acknowledgement to ExamTaker, or
saves current state and notifies ExamTaker of
incomplete submission.
7. ExamTaker logs out.
Entry conditions:
1. ExamTaker must have authentication credentials.
2. Computing requirements: supported browser.
21
 EXAMPLE: EXPANDED USE CASE
BUY ITEMS WITH CASH

• Use case: buy items with cash

• Actor: customer (initiator), cashier
• Purpose: capture a sale & its cash payment
• Overview (success scenario):
• A customer arrives at a checkout with items to purchase. The
cashier records the purchase items and collects a cash
payment. On completion, the customer leaves with the items
• Type: primary
• Cross references: functions R1.2,… 22
 TYPICAL COURSE OF EVENTS

ACTOR ACTION
System Response
1. THIS USE CASE BEGINS WHEN A
CUSTOMER ARRIVES AT THE POST
CHECKOUT WITH ITEMS TO PURCHASE

2. THE CASHIER RECORDS THE IDENTIFIER

FROM EACH ITEM
3. Determines the item price
and adds the item
IF THERE IS MORE THAN ONE OF THE information to the running
SAME ITEM, THE CASHIER CAN ENTER
THE QUANTITY AS WELL sales transaction

4. ON COMPLETION OF ITEM ENTRY, THE The description and price of

CASHIER INDICATES TO THE POST THAT the current item are
ITEM ENTRY IS COMPLETE presented

6. THE CASHIER TELLS THE CUSTOMER

THE TOTAL
5. Calculate and presents the
sale total 23
 TYPICAL COURSE OF EVENTS
ACTOR ACTION

7. THE CUSTOMER GIVES A CASH PAYMENT

System Response
POSSIBLY GREATER THAN THE SALE TOTAL

8. THE CASHIER RECORDS THE CASH RECEIVED

AMOUNT
9. Shows the balance due back
to the Customer.
10. THE CASHIER DEPOSITS THE CASH RECEIVED
& EXTRACTS THE BALANCE OWING 11. Logs the completed sale
THE CASHIER GIVES THE BALANCE OWING, &
THE PRINTED RECEIPT TO THE CUSTOMER

12. THE CUSTOMER LEAVES WITH THE ITEMS

PURCHASED
Alternatives:
Line 2. Invalid identifier entered.
Indicate errors
Line 7. Customer didn’t have 24
enough cash. Cancel sales
transaction
 2

3 4
5 6

7 8

25
RELATIONSHIPS BETWEEN USE CASES:
<<INCLUDES>>

26
 The <<includes>> Relationship
<<includes>> relationship represents behavior that is
factored out of the use case. A use case uses another
use case (“functional decomposition”)
Used to indicate that one use case includes the
functionality of another use case.
A function in the original problem statement is too
complex to be solvable immediately
 Describe the function as the aggregation of a set of
simpler functions. The associated use case is
decomposed into smaller use cases
 A reusable use case (component) that is unconditionally
called into the execution of another use case (always
included in the process – like running BIOS in a system
boot).
27

Included Including
use case use case
 THE <<INCLUDES>> RELATIONSHIP
• <<includes>> behavior is factored out for reuse, not because it is an
exception.

ManageIncident

<<include>>

CreateIncident HandleIncident CloseIncident

28
RELATIONSHIPS BETWEEN USE CASES:
<<EXTENDS>>

29
 The <<extends>> Relationship

<<extends>> relationships represent exceptional or seldom

invoked cases.
A reusable use case (component) that conditionally interrupts (is
invoked optionally -- like a menu selection in an application)
the execution of another use case to augment its functionality.
 The functionality in the original problem statement needs to be
extended.
The exceptional event flows are factored out of the main event
flow for clarity.
The base use case can be executed without the use case extension
in extend associations.
The responsibility for deciding when the extending use case
should be used lies with the extending use case.
Arrow points to use case being extended. 30

Extended Extending
use case use case
 Passenger

PurchaseTicket

<<extends>>

<<extends>>
<<extends>>

OutOfOrder <<extends>> TimeOut

Cancel NoChange
31
 THE <<EXTENDS>> RELATIONSHIP
• Use cases representing exceptional flows can extend more than one
use case.
• The direction of a <<extends>> relationship is to the extended use
case
• For example: the use case “ReportEmergency” is complete by itself
, but can be extended by the use case “Help” for a specific scenario
in which the user requires help

Help
FieldOfficer
f
<<extend>>

ReportEmergency
32
 Class
registration
<<Extends>> <<Extends>> Registration
Student Clerk

Registration for
special class
Prereq courses
not completed

Student Billing
Bursar’s
office

Instructor
Use-Case Diagram
33

Extends: extension to or variation of a use-case that exists in its own right

34
35