CIE 460

Fundamentals of Software
Engineering
Requirement Elicitation
Manar Elkady, Ph.D.
Object-Oriented Software Engineering
Using UML, Patterns, and Java
Elicitation
Chapter 4, Requirements
 Software Lifecycle Activities

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Implemented
Expressed in By
Structured By Realized By
Terms Of Verified
By

class...
class...
class... ?
class.... ?
Use Case Application Solution
Domain Subsystems Source Test
Model Domain
Objects Code Cases
Objects

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3 3
 First step in identifying the Requirements:
System identification
• Two questions need to be answered:
1. How can we identify the purpose of a system?
2. What is inside, what is outside the system?
• These two questions are answered during
requirements elicitation and analysis
• Requirements elicitation:
• Definition of the system in terms understood by the
customer (“Requirements specification”)
• Analysis:
• Definition of the system in terms understood by the
developer (Technical specification, “Analysis
model”)
• Requirements Process: Contains the activities
Requirements Elicitation and Analysis.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5 5
 Techniques to elicit Requirements

• Bridging the gap between end user and

developer:
• Questionnaires: Asking the end user a list of pre-
selected questions
• Task Analysis: Observing end users in their
operational environment
• Scenarios: Describe the use of the system as a series
of interactions between a concrete end user and the
system
• Use cases: Abstractions that describe a class of
scenarios.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6 6
 Requirements Elicitation activities
• Identifying actors
• Identifying scenarios
• Identifying use cases
• Identifying relationship among actors and
use cases
• Identifying initial analysis objects
• Identifying non-functional requirements

10/26/2024
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7 7 7
 Identifying actors

• Questions to ask
• Which user group are supported by the
system to perform their work?
• Which user groups execute the system’s main
functions?
• Which user groups perform secondary
functions (e.g. maintenance and
administration)?
• With what external hardware or software
systems the system will interact?

10/26/2024
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8 8 8
 Scenarios
• Scenario (Italian: that which is pinned to the
scenery)
• A synthetic description of an event or series of actions
and events.
• A textual description of the usage of a system. The
description is written from an end user’s point of view.
• A scenario is a concrete, focused, informal description
of a single feature of the system from the viewpoint of
a single actor.
• A scenario can include text, video, pictures and story
boards. It usually also contains details about the work
place, social situations and resource constraints.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9 9
 How do we find scenarios?

• Don’t expect the client to be verbal if the

system does not exist
• Client understands problem domain, not the solution
domain.
• Don’t wait for information even if the system
exists
• “What is obvious does not need to be said”
• Engage in a dialectic approach
• You help the client to formulate the requirements
• The client helps you to understand the requirements
• The requirements evolve while the scenarios are being
developed

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1010
 Outline

• Requirements Elicitation Example

• Doug’s Dog Door (continued from the previous lecture)
• Introducing use cases
• Use cases versus scenarios
• Requirements Elicitation Activities (continued)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1111
 Outline

• Requirements Elicitation Example

• Doug’s Dog Door (continued from the previous lecture)
• Introducing use cases
• Use cases versus scenarios
• Requirements Elicitation Activities (revisited)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1212
 Example (From Head First Analysis &
Design Textbook)
• You have been hired as a
programmer, in a new
start-up software
development firm “Doug’s
Dog Doors”.
• Doug’s got a pretty high-
tech door under
development, and needs
you to finish developing
its needed software.
• Hence, you need to do
some requirements
gathering.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1313
 Meet Your First Customer: Todd and Tina

• Todd and Tina are not

satisfied with the plastic flap
in their door.
• They want a dog door that
responds to the press of a
button
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1414
 Your First Attempt to Please Your Customer

• The DogDoor.java code

will control the hardware
within the physical dog
Bernd Bruegge & Allen H. Dutoit door 15
Object-Oriented Software Engineering: Using UML, Patterns, and Java 15
 Your First Attempt to Please Your Customer

• What do you think

should be filled-in here?

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1616
 Your First Attempt to Please Your Customer

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1717
 Your First Attempt to Please Your Customer

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1818
 So… What is a requirement?

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1919
 Hence….You need to create a
requirements list (Based on what?)

• Does this list show all

what you need to know?
• You still need
Bernd Bruegge & Allen H. Dutoit scenarios! 20
Object-Oriented Software Engineering: Using UML, Patterns, and Java 20
 Hence….You need to create a
requirements list (Based on what?)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2121
 Next…Plan for things going wrong

• Any suggestions?
• Does Fido always bark when he needs to go
outside? What if he just scratches at the door?
• What if Todd and Tina aren’t home when he
needs to go outside?
• What if Todd and Tine don’t hear Fido barking?
• What if Fido barks for some other reasons?
• What if Fido is stuck outside? Can Todd and
Tina hear him bark to press open?

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2222
 Hence…Consider alternate paths to
handle the system problems
• How would that update our scenarios?

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2323
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2424
 • No…You are talking about
Fido, Todd and Gina.
• Remember…A use case is
not a scenario.
• A scenario is one way to
achieve the goal from a
specific starting point.
• A use case describes all ways
to achieve the goal from a
Bernd Bruegge & Allen H. Dutoit
specific starting point 25
Object-Oriented Software Engineering: Using UML, Patterns, and Java 25
 Outline

• Requirements Elicitation Example

• Doug’s Dog Door (continued from the previous lecture)
• Introducing use cases
• Use cases versus scenarios
• Requirements Elicitation Activities (revisited)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2626
 But… What is a use case?

• Uses cases are

about the “what”
not the “how”
• What does the
dog door need to
do?

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2727
 But… What is a use case?

• We focus on
what the system
needs to do to
achieve the use
case’s goal.
• What should
happen in order
to get the dog
outside?

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2828
 But… What is a use case? • A use case
focuses in a
single goal.
• The single goal is
getting the dog
outside without
getting the
owner out of his
bed.
• What if the dog
owner wants to
track how many
times did the dog
use the door?
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2929
 But… What is a use case? • The
user/customer is
outside the
system.
• Is Fido part of
the system?
• Is Gina part of
the system?
• Is the dog door
inside the
system?
• Is the remote
inside the
system?
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3030
 • The use case
ends when the
customer’s goal
is complete.
• Remember the
alternative paths.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3131
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3232
 Checking your requirements against your
use cases
• You need to go back to your requirements,
and make sure that they’ll cover everything
your system has to do.
• Is anything missing?
• Now, you need to look over the use case
and see if everything the system needs to
do is covered by the requirements

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3333
 Checking your requirements against your
use cases
• You need to go back to your requirements,
and make sure that they’ll cover everything
your system has to do.
• Is anything missing?
• Now, you need to look over the use case
and see if everything the system needs to
do is covered by the requirements

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3434
Did Your Requirements Handle Everything?
Flow of events:
1. The dog barks to be let out (_)
2. The dog owner hears the dog barking. (_)
3. The dog owner presses the button on the
remote control. (_)
4. The dog door opens. (_)
5. The dog goes outside. (_)
Requirements v 2.0
1. The dog door opening must be 12 inches tall at
least.
2. A button on the remote control opens the dog
door if closed, and closes it if open.
3. Once the door is opened, it should close
automatically if it is not already closed. 35
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35
Check your requirements against your use cases
Flow of events:
6. The dog does his business (_)
1. The door shuts automatically (_)
2. The dog barks to be let back in (_)
3. The owner hears the dog barking
(again) (_)
4. The owner presses the button on the
remote control (_)
5. The dog door opens (again) (_)
7. The dog goes back inside (_)
8. The door shuts automatically. (_)
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3636
Did Your Requirements Handle Everything?
Flow of events:
1. The dog barks to be let out (N/A)
2. The dog owner hears the dog barking.(N/A)
3. The dog owner presses the button on the
remote control. (2)
4. The dog door opens. (3)
5. The dog goes outside. (1)
Requirements v 2.0
1. The dog door opening must be 12 inches tall at
least.
2. A button on the remote control opens the dog
door if closed, and closes it if open.
3. Once the door is opened, it should close
automatically if it is not already closed. 37
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37
Check your requirements against your use cases
Flow of events:
6. The dog does his business (N/A)
1. The door shuts automatically (3)
2. The dog barks to be let back in
(N/A)
3. The owner hears the dog barking
(again) (N/A)
4. The owner presses the button on the
remote control (2)
5. The dog door opens (again) (2)
7. The dog goes back inside (1)
8. The door shuts automatically. (3)
Bernd Bruegge & Allen H. Dutoit 38
Object-Oriented Software Engineering: Using UML, Patterns, and Java 38
 Checking your requirements against your
use cases
• You need to go back to your requirements,
and make sure that they’ll cover everything
your system has to do.
• Is anything missing?
If you found any steps in the use case that
do not have a requirement, you need to
update your requirements list.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3939
 Outline

• Requirements Elicitation Example

• Doug’s Dog Door (continued from the previous lecture)
• Introducing use cases
• Use cases versus scenarios
• Requirements Elicitation Activities
(revisited)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4040
 Requirements Elicitation activities
• Identifying actors
• Identifying scenarios
• Identifying use cases
• Identifying relationship among actors and
use cases
• Identifying initial analysis objects
• Identifying non-functional requirements

10/26/2024
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4141
4
 Identifying actors

• Actors represent external entities that

interact with the system.
• Could be human or an external system.
• Actors are role abstractions and do not
necessarily directly map to persons.
• Actors vs. objects?

GPS

WatchOwner SatWatch

WebifyWatch

10/26/2024
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4242
4
 Identifying actors

• Questions to ask
• Which user group are supported by the
system to perform their work?
• Which user groups execute the system’s main
functions?
• Which user groups perform secondary
functions (e.g. maintenance and
administration)?
• With what external hardware or software
systems the system will interact?

10/26/2024
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4343
4
 Identifying actors

10/26/2024
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4444
4
 Requirements Elicitation activities
• Identifying actors
• Identifying scenarios
• Identifying use cases
• Identifying relationship among actors and
use cases
• Identifying initial analysis objects
• Identifying non-functional requirements

10/26/2024
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4545
4
 Scenario example: Warehouse on Fire

• Bob, driving down main street in his

patrol car notices smoke coming out
of a warehouse. His partner, Alice,
activates the “Report emergency”
function from her FRIEND laptop.
• Alice enters the address of the
building into her wearable computer
, a brief description of its location
(i.e., north west corner), and an
emergency level.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4646
 Scenario example: Warehouse on Fire
(Cont’d)
• She confirms her input and waits for
an acknowledgment.
• John, the dispatcher, is alerted to the
emergency by a beep of his
workstation. He reviews the
information submitted by Alice and
acknowledges the report. He allocates
a fire unit and sends the estimated
arrival time (ETA) to Alice.
• Alice received the acknowledgment
and the ETA.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4747
 Observations about Warehouse on Fire
Scenario
• Concrete scenario
• Describes a single instance of reporting a fire
incident.
• Does not describe all possible situations in
which a fire can be reported.

• Participating actors
• Bob, Alice and John

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4848
 After the scenarios are formulated

• Find all the use cases in the scenario that

specify all instances of how to report a fire
• Example: “Report Emergency“ in the first paragraph of
the scenario is a candidate for a use case
• Describe each of these use cases in more detail
• Participating actors
• Describe the entry condition
• Describe the flow of events
• Describe the exit condition
• Describe exceptions
• Describe nonfunctional requirements

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4949
 Requirements Elicitation activities
• Identifying actors
• Identifying scenarios
• Identifying use cases
• Identifying relationship among actors and
use cases
• Identifying initial analysis objects
• Identifying non-functional requirements

10/26/2024
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5050
5
 Use Case Model for Incident Management

<<initiates>>
<<initiates>>

FieldOfficer Dispatcher
<<participate>> OpenIncident

<<initiates>>

ReportEmergency

AllocateResources

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5151
 Use Case Example: ReportEmergency

• Use case name: ReportEmergency

• Participating Actors:
• Field Officer (Bob and Alice in the Scenario)
• Dispatcher (John in the Scenario)
• Exceptions:
• The FieldOfficer is notified immediately if the
connection between terminal and central is lost.
• The Dispatcher is notified immediately if the connection
between a FieldOfficer and central is lost.
• Flow of Events: on next slide.
• Special Requirements:
• The FieldOfficer’s report is acknowledged within 30
seconds. The selected response arrives no later than
30 seconds after it is sent by the Dispatcher.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5252
 Use Case Example: ReportEmergency
Flow of Events
1. The FieldOfficer activates the “Report Emergency”
function of her terminal. FRIEND responds by
presenting a form to the officer.
2. The FieldOfficer fills the form, by selecting the
emergency level, type, location, and brief
description of the situation. The FieldOfficer also
describes a response to the emergency situation.
Once the form is completed, the FieldOfficer
submits the form, and the Dispatcher is notified.
3. The Dispatcher creates an Incident in the database
by invoking the OpenIncident use case. He selects
a response and acknowledges the report.
4. The FieldOfficer receives the acknowledgment and
the selected response.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5353
 Another Example: Allocate a Resource

• Actors:
• Resource Allocator: The Resource Allocator is
responsible for the commitment and
decommitment of the Resources managed by
the FRIEND system.
• Dispatcher: A Dispatcher enters, updates, and
removes Emergency Incidents, Actions, and
Requests in the system. The Dispatcher also
closes Emergency Incidents.
• Field Officer: Reports accidents from the Field

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5454
 Allocate a Resource (cont’d)
• Use case name: AllocateResources
• Participating Actors:
Field Officer (Bob and Alice in the Scenario)
Dispatcher (John in the Scenario)
Resource Allocator
• Entry Condition:
The Resource Allocator has selected an available
resource

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5555
 Allocate a Resource (cont’d)
• Use case name: AllocateResources
• Flow of Events:
1.The Resource Allocator selects an Emergency
Incident
2. The Resource is committed to the Emergency
Incident
• Exit Condition:
The use case terminates when the resource is
committed
The selected Resource is unavailable to other
Requests.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5656
 Order of steps when formulating use cases
• First step: Name the use case
• Use case name: ReportEmergency

• Second step: Find the actors

• Generalize the concrete names (“Bob”) to
participating actors (“Field officer”)
• Participating Actors:
• Field Officer (Bob and Alice in the
Scenario)
• Dispatcher (John in the Scenario)
• Third step: Concentrate on the flow of
events
• Use informal natural language
Bernd Bruegge & Allen H. Dutoit 57
Object-Oriented Software Engineering: Using UML, Patterns, and Java 57
 Requirements Elicitation activities
• Identifying actors
• Identifying scenarios
• Identifying use cases
• Identifying relationship among actors
and use cases
• Identifying initial analysis objects
• Identifying non-functional requirements

10/26/2024
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5858
5
 Use Case Associations
• Dependencies between use cases are
represented with use case associations
• Associations are used to reduce complexity
• Decompose a long use case into shorter
ones
• Separate alternate flows of events
• Refine abstract use cases
• Types of use case associations
• Includes
• Extends
• Generalization
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5959
 <<include>>: Functional Decomposition
• Problem:
• A function in the original problem statement
is too complex
• Solution:
• Describe the function as the aggregation of
a set of simpler functions. The associated
use case is decomposed into shorter use
cases ManageIncident

<<include>>

CreateIncident HandleIncident CloseIncident

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6060
 <<include>>: Reuse of Existing Functionality
• Problem: There are overlaps among use cases.
How can we reuse flows of events instead of
duplicating them?
• Solution: The includes association from use case
A to use case B indicates that an instance of use
case A performs all the behavior described in use
case B (“A delegates to B”)
• Example: Use case “ViewMap” describes behavior
that can be used by use case “OpenIncident”
(“ViewMap” is factored out)

<<include>>

OpenIncident
ViewMap
Base Use
Case <<include>>
Supplier
AllocateResources Use Case
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6161
 <<extend>> Association for Use Cases
• Problem: The functionality in the original
problem statement needs to be extended.
• Solution: An extend association from use case A
to use case B
• Example: “ReportEmergency” is complete by
itself, but can be extended by use case “Help” for
a scenario in which the user requires help

Help
FieldOfficer
<<extend>>

Bernd Bruegge & Allen H. Dutoit ReportEmergency

Object-Oriented Software Engineering: Using UML, Patterns, and Java 6262
 Generalization in Use Cases
• Problem: We want to factor out common (but
not identical) behavior.
• Solution: The child use cases inherit the
behavior and meaning of the parent use case
and add or override some behavior.
• One use case can specialize another more
general one by adding more detail
Example:
• Field officers are required to authenticate before
they can use FRIEND.
• During early requirements elicitation, such
requirement was “Authenticate use case”
• Later on, field officers could authenticate with
password or with a card based on the platform
used
Bernd Bruegge & Allen H. Dutoit 63
Object-Oriented Software Engineering: Using UML, Patterns, and Java 63
 Generalization in Use Cases
• In the textual representation, specialized use
cases inherit the initiating actor and
the entry and exit conditions from the
general use case
• Example: “ValidateUser” is responsible for
verifying the identity of the user. The customer
might require two realizations:
“CheckPassword” and “CheckFingerprint”

Child
Use Case
CheckPassword
Parent
AuthhenticateUser
Case
CheckFingerprint
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6464
 Another Use Case Example
Actor Bank Customer
• Person who owns one or more Accounts in
the Bank.
Withdraw Money
• The Bank Customer specifies a Account and
provides credentials to the Bank proving that
s/he is authorized to access the Bank
Account.
• The Bank Customer specifies the amount of
money s/he wishes to withdraw.
• The Bank checks if the amount is consistent
with the rules of the Bank and the state of
the Bank Customer’s account. If that is the
case, the Bank Customer receives the
money in cash.
Bernd Bruegge & Allen H. Dutoit 65
Object-Oriented Software Engineering: Using UML, Patterns, and Java 65
 Use Case Attributes
Use Case Withdraw Money Using ATM

Initiatiating actor:
• Bank Customer

Preconditions:
• Bank Customer has opened a Bank Account
with the Bank and
• Bank Customer has received an ATM Card and
PIN
Postconditions:
• Bank Customer has the requested cash or
• Bank Customer receives an explanation from
the ATM about why the cash could not be
dispensed
Bernd Bruegge & Allen H. Dutoit 66
Object-Oriented Software Engineering: Using UML, Patterns, and Java 66
 Use Case Flow of Events
Actor steps System steps
1.The Bank Customer
inputs the card into the 2.The ATM requests the
ATM. input of a four-digit PIN.
3. The Bank
Customer types in 4. If several accounts are
PIN. recorded on the card, the ATM
offers a choice of the account
5. The Bank Customer numbers for selection by the
selects an account. Bank Customer
6.If only one account is
recorded on the card or after
the selection, the ATM
7. The Bank Customer requests the amount to be
inputs an amount. withdrawn.
8.The ATM outputs the money and a
receipt and stops the interaction.
Bernd Bruegge & Allen H. Dutoit 67
Object-Oriented Software Engineering: Using UML, Patterns, and Java 67
 Use Case Exceptions
[Invalid card]
The ATM outputs the card and
Actor steps stops the interaction.
1. The Bank Customer inputs
her card into the [Invalid PIN]
ATM.[Invalid card] The ATM announces the failure
and offers a 2nd try as well as
3. The Bank Customer types canceling the whole use case.
in PIN. [Invalid PIN] After 3 failures, it announces
the possible retention of the
card. After the 4th failure it
5. The Bank Customer keeps the card and stops the
selects an account . interaction.

7. The Bank Customer inputs [Amount over limit]

an amount. [Amount The ATM announces the failure
over limit] and the available limit and
offers a second try as well as
canceling the whole use case.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6868
 Guidelines for Formulation of Use Cases (1)

• Name
• Use a verb phrase to name the use case.
• The name should indicate what the user is
trying to accomplish.
• Examples:
• “Request Meeting”, “Schedule Meeting”,
“Propose Alternate Date”
• Length
• A use case description should not exceed 1-2
pages. If longer, use include relationships.
• A use case should describe a complete set of
interactions.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6969
 Guidelines for Formulation of Use Cases (2)

Flow of events:
• Use the active voice. Steps should start either
with “The Actor” or “The System …”.
• The causal relationship between the steps
should be clear.
• All flow of events should be described (not only
the main flow of event).
• The boundaries of the system should be clear.
Components external to the system should be
described as such.
• Define important terms in the glossary.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7070
 Example of a badly written Use Case

“The driver arrives at the parking gate, the driver

receives a ticket from the distributor, the gate is
opened, the driver drives through.”

• What is wrong with this use case?

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7171
 Example of a badly written Use Case

“The driver arrives at the parking gate, the driver

receives a ticket from the distributor, the gate is
opened, the driver drives through.”

It contains no actors
It is not clear which action triggers the ticket being
issued
Because of the passive form, it is not clear who
opens the gate (The driver? The computer? A gate
keeper?)

It is not a complete transaction. A complete

transaction would also describe the driver paying for
the parking and driving out of the parking lot.
Bernd Bruegge & Allen H. Dutoit 72
Object-Oriented Software Engineering: Using UML, Patterns, and Java 72
 Use Case Refinement (1)
• Use case name: Report Emergency
• Participating Actors:
Field Officer, Dispatcher
• Flow of Events:
1. The FieldOfficer activates the “Report
Emergency” function of her terminal.
2. FRIEND responds by presenting a form
to the FieldOfficer.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7373
 Use Case Refinement (1)
• Use case name: Report Emergency
• Participating Actors:
Field Officer, Dispatcher
• Flow of Events:
3.The FieldOfficer completes the form by
selecting the emergency level, type, location,
and brief description of the situation. Once the
form is complete, the FieldOfficer submits the
form.
4. FRIEND receives the form and notifies
the Dispatcher

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7474
 Use Case Refinement (2)
• Use case name: Report Emergency
• Participating Actors:
Field Officer, Dispatcher
• Flow of Events:
1. The FieldOfficer activates the “Report
Emergency” function of her terminal.
2. FRIEND responds by presenting a form
to the officer. The form includes an
emergency type menu (general
emergency, fire, , transportation),
location, incident description, and
resource request.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7575
 Use Case Refinement (2)
• Use case name: Report Emergency
• Participating Actors:
Field Officer, Dispatcher
• Flow of Events:
3.The FieldOfficer completes the form by
selecting the emergency level, type, location,
and brief description of the situation. Once the
form is complete, the FieldOfficer submits the
form.
4. FRIEND receives the form and notifies
the Dispatcher by a pop-up dialog.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7676
 How to write a use case (Summary)
• Name of Use Case
• Actors
• Description of Actors involved in use case
• Entry condition
• “This use case starts when…”
• Flow of Events
• Free form, informal natural language
• Exit condition
• “This use cases terminates when…”
• Exceptions
• Describe what happens if things go wrong
• Special Requirements
• Nonfunctional Requirements, Constraints

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7777
 Summary

• Scenarios:
• Great way to establish communication
with client
• Different types of scenarios: As-Is,
visionary, evaluation and training
• Use cases
• Abstractions of scenarios
• Use cases bridge the transition between
functional requirements and objects.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7878
 References

• Required Reading: Chapter 4. Bruegge, Bernd,

and Allen H. Dutoit. "Object-‐Oriented Software
Engineering. Using UML, Patterns, and
Java." Learning 5.6 (2009): 7.
• Chapter 2. McLaughlin, Brett, Gary Pollice, and
David West. Head First Object-Oriented Analysis
and Design: A Brain Friendly Guide to OOA&D. "
O'Reilly Media, Inc.", 2007.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7979