Functional Modeling

Scenarios
♦ Scenario
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 can include text, video, pictures and
story boards. It usually also contains details about
the work place, social situations and resource
constraints.
 More Definitions
♦ Scenario:
“A narrative description of what people
do and experience as they try to make use of
computer systems and applications”
[M. Carroll, Scenario-Based Design, Wiley, 1995]
♦ A concrete, focused, informal description of a
single feature of the system used by a single actor
Scenario become the basis of interaction for a new
design or allow better understanding of the new
design.
 Types of Scenarios
♦ As-is scenario:
Describes a current situation. Commonly used in
re-engineering projects. The user describes the
system
♦ Visionary scenario:
Describes a future system
Often used in greenfield engineering and interface
engineering projects
Visionary scenarios are often not done by the user
or developer alone.
 Types of Scenarios (2)
♦ Evaluation scenario:
Description of a user task against which the
system is to be evaluated.
♦ Training scenario:
A description of the step by step instructions
that guide a beginner user through a system
 Scenario-Based Design
Scenarios can have many different uses during the
software lifecycle:
Requirements Elicitation: As-is scenario, visionary
scenario
Client Acceptance Test: Evaluation scenario
System Deployment: Training scenario
Scenario-Based Design: The use of scenarios in a
software lifecycle activity
Scenario-based design is iterative
Each scenario should be considered as a work document
to be augmented and rearranged (“iterated upon”)
 Scenario-Based Design
♦ Focuses on concrete descriptions and
particular instances, not abstract generic ideas
♦ It is work driven not technology driven
♦ It is open-ended, it does not try to be complete
♦ It is informal
♦ Is about intended outcomes, not about
specified outcomes.
 How do we find scenarios?
♦ Don’t expect the client to be very helpful if the system
does not exist (greenfield engineering)
➢Client understands the application domain (problem
domain), not the solution domain
♦ Engage in a interaction 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.
 Heuristics for finding scenarios
♦ Ask yourself or the client the following questions:
What are the primary tasks that the system needs to perform?
What data will the actor create, store, change, remove or add in the
system?
What external changes does the system need to know about?
What changes or events will the actor of the system need to be
informed about?
♦ However, don’t rely on questions and questionnaires alone
♦ Insist on task observation if the system already exists (interface
engineering or reengineering)
Ask to speak to the end user, not just to the client
Expect resistance and try to overcome it.
 Use Cases Approach
♦ Use cases is a technique for specifying behavior
(functionality)
♦ I.e. focuses on functional specs only
♦ Though primarily for specification, can be used in
analysis and elicitation
♦ Can be used to specify business or organization
behavior also, though we will focus on software
♦ Well suited for interactive systems
 Use Cases Basics
♦ A use case captures a contract between a user and
system about behavior
♦ Basically a textual form; diagrams are mostly to
support
♦ Also useful in requirements elicitation as users like
and understand the story telling form and react to it
easily
 Basics..
♦ Actor: a person or a system that interacts with the
proposed system to achieve a goal (external entity)
Eg. User of an ATM (goal: get money); data entry
operator; (goal: Perform transaction)
♦ Actors can be people or systems
♦ Primary actor: The main actor who initiates a UC
UC is to satisfy his goals
 Basics..
♦ Flow of Events (or Main scenario): a set of actions
performed to achieve a goal under some conditions
Actions specified as a sequence of steps (events)
A step is a logically complete action performed either by
the actor or the system
<<things go normally and the goal is achieved>>

♦Exceptions (or Alternate scenarios):

<<things go wrong and goals cannot be achieved>>
Exceptions (or Alternate scenarios)
1. Failure conditions
List possible failure conditions for UCs
For each step, identify how it may fail
This step uncovers special situations

2. Failure handling
Perhaps the hardest part
Specify system behavior for the failure conditions
New business rules and actors may emerge
 Basics..
♦ Entry condition (or Pre-condition):
➢what should be True before starting the first step in UC

♦ Exit condition (or Post-condition):

➢what should be True after finishing the UC

♦ Quality requirements (or nonfunctional

requirements):
➢ that are related to this UC
 Use Cases and Scenarios
♦ A use case is a collection of many such scenarios
♦ A scenario may employ (include) other use cases
in a step
a sub-goal of a use case goal may be performed by
another use case
use cases can be organized hierarchically
 Summary
♦ Actors are external entities that interact with the system
An actor can be a human or an external system
♦ Use cases represent a sequence of interaction for a type
of functionality
UCs specify functionality by describing interactions
between actors and system
Focuses on external behavior
UCs are primarily textual
UC diagrams show UCs, actors, and relationships
They provide an overview
♦ They do not form the complete SRS, only the
functionality part
 Use Case Templates
♦ Name: Give a short, descriptive name to the use case
♦ Actors: List the actors who can perform this use case
♦ Goals: Explain what the actors are trying to achieve
♦ Preconditions: State of the system before the use case
♦ Description: Give a short informal description
♦ Trigger: Describe the event that initiates the activity
♦ Summary: Summarize what occurs as the actors perform the use case
♦ Related use cases: (in accordance with use case diagram)
♦ Flow of Events: Describe the steps in a normal scenario
♦ Exceptions: Describe alternate scenarios
♦ Postconditions: State of the system following completion
♦ Special Requirements: Non-functional requirements and constraints
♦ Priority Level: The needed priority value for the use case

<and more …>

 How to Identify Actors
♦ Questions for identifying actors:
Which user groups are supported by the system
to perform their work?
Which user groups execute the system’s main
functions?
Who perform secondary functions? Ex:
administrators
What are the external hardware and software
that interact with the system?
 How to find Use Cases
♦ Select
a narrow vertical slice of the system (i.e.
one scenario)
Discuss it in detail with the user to understand
the user’s preferred style of interaction
♦ Selecta horizontal slice (i.e. many scenarios) to
define the scope of the system.
Discuss the scope with the user
♦ Use illustrative prototypes as visual support
 Use Case Development – Example: ATM System (1)

1. Determine candidate system scope and boundaries

• Identify stakeholders
• Identify problem - Create problem statement
• Use interviews and other techniques

-ATM
-Bank -ATM
-ATM
-Customer - Bank

- Customer - Customer
- Bank
2. Identify actors
• Choose actors’ names carefully
• Actors give value, get value from system or both
• Should reflect roles rather than actual people
 Use Case Development – Example: ATM System (2)
3. Identify use cases
Identify and refine actors’ goals
⧫ Why would actor AAA use the
system?
Identify actors’ tasks to meet
goals
⧫ What interactions would meet goal
GGG of actor AAA?
Example actor: Customer
Goal: Access account 24/7 for
regular banking operations
(withdrawal, deposit, statement...)
in a timely and secure way.
To be refined into sub-goals.
From goals we can identify tasks:
Withdraw Cash, Make Deposit,
Print Account Statement....
 Use Case Development – Example: ATM
System (3)
3. Identify use cases (cont’d)
Develop a brief description in narrative form
e.g., description of use case Withdraw Cash

The Customer identifies herself to the system, then selects the cash
withdrawal operation. The system asks for the amount to withdraw.
The Customer specifies the amount. The system provides the
requested amount if it is less than the account’s balance. The
Customer takes the amount and leaves.

4. Identify preconditions Postconditions

e.g., Preconditions
⧫ System is in operation, cash is available
e.g., Postconditions
⧫ Bank Customer has the requested cash OR Bank Customer receives an explanation
from the ATM about why the cash could not be dispensed
Use Case Development – Example: ATM System (4)
5. Definition of Flow of Events (main scenario)
Happy day story where everything goes fine

6. Definition Exceptions (alternatives scenarios)

Alternatives and Exceptions story

Example use case: Withdraw Cash

Incorrect identification Customer forgets card in card reader

Incorrect amount entered Customer forgets cash in dispenser

Not enough cash available

 Use Case Example 1
Use Case 1: Buy stocks
Primary Actor: Purchaser
Goals of Stakeholders:
Purchaser: wants to buy stocks
Company: wants full transaction info
Pre-condition: User already has an account
Post-condition: User receive a new portfolio
 Example 1…
♦ Flow of Events:
1. User selects to buy stocks
2. System gets name of web site from user for trading
3. Establishes connection
4. User browses and buys stocks
5. System intercepts responses from the site and updates
user portfolio
6. System shows user new portfolio
 Example 1…
♦ Exceptions:
2a: System gives error msg, asks for new
suggestion for site, gives option to cancel
3a: Web failure.
1. Sys reports failure to user, backs up to previous
step.
2. User exits or tries again
4a: Computer crashes
4b: web site does not confirm the purchase
5a: web site does not return needed info
 Use Case Example 2
♦ Use Case 2: Buy a product
♦ Primary actor: buyer/customer
♦ Goal: purchase some product
♦ Pre-condition: Customer is already logged in
♦ Post-condition: Customer receive a confirmation
 Example 2…
♦ Flow of Events:
1. Customer browses and selects items
2. Customer goes to checkout
3. Customer fills shipping options
4. System presents full pricing info
5. Customer fills credit card info
6. System authorizes purchase
7. System confirms sale
8. System sends confirming email
 Example 2…
♦ Exceptions:
6a: Credit card authorization fails
1. Allows customer to reenter info
3a: Regular customer
⧫ System displays last 4 digits of credit card no
⧫ Asks customer to OK it or change it
⧫ Moves to step 6
 Example – An auction site
♦ Use Case 1: Put an item for auction
♦ Primary Actor: Seller
♦ Precondition: Seller has logged in
♦ Flow of Events:
1. Seller posts an item (its category, description, picture, etc.)
for auction
2. System shows past prices of similar items to seller
3. System specifies the starting bid price and a date when
auction will close
4. System accepts the item and posts it
♦ Exceptions:
2 a) There are no past items of this category
* System tells the seller this situation
 Example – An auction site
♦ Use Case 2: Make a bid
♦ Primary Actor: Buyer
♦ Precondition: The buyer has logged in
♦ Flow of Events:
1. Buyer searches or browses and selects some item
2. System shows the rating of the seller, the starting bid, the
current bids, and the highest bid; asks buyer to make a bid
3. Buyer specifies bid price, max bid price, and increment
4. Systems accepts the bid; Blocks funds in bidders account
5. System updates the bid price of other bidders where needed,
and updates the records for the item
♦ Exception:
3 a) The bid price is lower than the current highest
* System informs the bidder and asks to rebid

4 a) The bidder does not have enough funds in his account

* System cancels the bid, asks the user to get more funds
 Example – An auction site
♦ Use Case 3: Complete auction of an item
♦ Primary Actor: Auction System
♦ Precondition: The last date for bidding has been reached
♦ Flow of Events:
1. Select highest bidder; send email to selected bidder and seller informing
final bid price; send email to other bidders also
2. Debit bidder’s account and credit seller’s account
3. Transfer from seller’s account commission amount to organization’s
account
4. Remove item from the site; update records
♦ Exception: None
An auction site Example – summary-level Use
Case
♦ Use Case 0 : Auction an item
♦ Primary Actor: Auction system
♦ Scope: Auction conducting organization
♦ Precondition: None
♦ Flow of Events:
1. Seller performs put an item for auction
2. Various bidders make a bid
3. On final date perform Complete the auction of the
item
4. Get feed back from seller; get feedback from buyer;
update records
 Use Case Development – Example: ATM System (5)
Flow of Events: A Request-Response Interaction between
Actor and System
Actor steps System steps
1.The Bank Customer inserts the
card into the ATM
2.The ATM requests the input of
a four-digit PIN
3. The Bank Customer types in PIN
4. If several accounts are recorded
on the card, the ATM offers a choice
of the account numbers for selection
by the Bank Customer
5. The Bank Customer selects an
account 6.If only one account is recorded on
the card or after the selection, the
ATM requests the amount to be
withdrawn
7. The Bank Customer inputs an
amount 8.The ATM outputs the money and a
receipt and stops the interaction.
 Use Case Exceptions
Actor steps
1. 1.The Bank Customer inserts the
card into the ATM.[Invalid card]
3. The Bank Customer types in PIN.
[Invalid PIN]
5. The Bank Customer selects an
account .
7. The Bank Customer inputs an
amount. [Amount over limit]
[Invalid card]
The ATM outputs the card and stops the
interaction.
[Invalid PIN]
The ATM announces the failure and
offers a 2nd try as well as canceling the
whole use case. After 3 failures, it
announces the possible retention of the
card. After the 4th failure it keeps the
card and stops the interaction.
[Amount over limit]
The ATM announces the failure and the
available limit and offers a second try as
well as canceling the whole use case.
 Scenario Example: Warehouse on Fire
♦ Bob, driving down main street in his patrol car notices smoke
coming out of a warehouse. His partner, Alice, reports the
emergency from her car.
♦ 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.
♦ 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..
Observations about the Warehouse on Fire Scenario
♦ It is a concrete scenario
It describes a single instance of reporting a fire
incident
It does not describe all possible situations in which
a fire can be reported

♦ Participating actors
Bob, Alice and John.
After the scenarios are formulated

♦ Findall the use cases in the scenario that

specify all instances of how to report a fire
Example from the Warehouse on Fire
scenario:
⧫ “Bob… notices smoke coming out of a warehouse. His partner,
Alice, reports the emergency from her car”
“Report Emergency is a candidate for a use
case
“
 Use Case Modeling
♦ Graphical notation: An oval with the name of the use case

ReportEmergency

Use Case Model: The set of all use cases specifying

the complete functionality of the system
 Use Case 1: ReportEmergency
♦ Use case name: ReportEmergency
♦ Participating Actors:
- Field Officer (Bob and Alice in the Scenario)
- Dispatcher (John in the Scenario)
♦ Entry Condition:
The FieldOfficer is logged into the System
♦ Exit Condition:
The FieldOfficer has received an acknowledgement and the selected
response OR The FieldOfficer has received an explanation indicating why
the transaction could not be processed
♦ Exceptions:
2(a) The FieldOfficer is notified immediately if the connection between
terminal and central is lost
♦ Quality 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.
 Use Case 1: ReportEmergency (ctd)
Flow of Events:
1. The FieldOfficer activates the “Report Emergency” function of
her terminal. The system 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 by invoking
“AllocateResources” and acknowledges the report.
4. The FieldOfficer receives the acknowledgment and the selected
response.
UML Use Case Model for Incident Management

FieldOfficer Dispatcher
OpenIncident

ReportEmergency

AllocateResources
 UML Use Case Diagram
Watch System
Use Case
Watch

Actor.

ReadTime

SetTime
WatchUser WatchRepairPerson

ChangeBattery System boundary

Use case diagrams represent the functionality of the system

from user’s point of view
 Use Case Associations
♦ A use case model consists of use cases and use case associations
A use case association is a relationship between use cases
♦ Important types of use case associations: Include, Extends,
Generalization
♦ Include
A use case uses another use case (functional decomposition)
♦ Extends
A use case extends another use case (infrequent functionality)
♦ Generalization
An abstract use case has different specializations
<<include>>:
♦Problem:
Functional Decomposition
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>>
<<include>> <<include>>

CreateIncident HandleIncident CloseIncident

<<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”

<<include>>

OpenIncident
ViewMap
Base Use
Case <<include>>
Supplier
AllocateResources
Use Case
<<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

<<extend>>
Help
FieldOfficer

ReportEmergency
 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.
♦ 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
ValidateUser
Case
CheckFingerprint
 Generalization in Use Cases (cont.)
♦ Generalization of actors is supported
The open triangle points toward the more general case
 UML Use Case Diagram Example:
- ATM System -
Withdraw Cash

Identify Customer Bank

<<include>>

<<include>> <<include>>

Customer
Make Deposit
Print Account
Statement
 Extension Points
▪ To describe where or when to execute the “extend use case”
▪ Extension points are either written:
▪directly within the use case
▪As a label and location
▪ Specification of multiple Extension Points is possible.

▪ Example:
Example: University Registration System (1)

Enroll in
University <<includes>> Enroll in
Registrar Course
XPCheck :7

<<extends>>
Applicant
Perform
Security Check

International Applicant
Security System
 Example: University Registration System (2)
♦ Use Case 1: Enroll in University
♦ Goal: Enroll applicant in the university
♦ Preconditions:
The Registrar is logged into the system.
The Applicant has already pass initial checks to verify that they are
eligible to enroll.
♦ Postconditions:
The Applicant will be enrolled in the university as a student if they are
eligible.
 Example: University Registration System (3)
♦ Flow of Events:
1. An applicant wants to enroll in the university.
2. The applicant hands a filled out copy of form UI13 University Application Form to the registrar.
3. The registrar visually inspects the forms.
4. The registrar determines that the forms have been filled out properly.
5. The registrar selects to Create New Student.
6. The system displays the Create Student Screen.
7. The registrar inputs the name, address, and phone number of the applicant.
[Extension Point: XPCheck]
8. The system determines that the applicant does not already exist within the system.
9. The system determines that the applicant is on the eligible applicants list.
10. The system adds the applicant to its records.
11. The registrar enrolls the student in courses via use case Enroll in Course.
12. The system prepares a bill for the applicant enrollment fees.
♦ Alternate Flows of Events:
(4) a The forms have not been adequately filled…
 Example: University Registration System (4)
♦ Use Case 2: Perform Security Check
♦ Flows of Events:

- At Extension Point XPCheck:

1. The registrar asks for security check results about applicant.
2. The system asks Security System for applicant security check
results.
3. The Security System responds that applicant has been cleared.

♦ Exceptions:
3.a The Security System responds that applicant has not been
cleared
 Use Case Development – Rules of Thumb
➢ Be careful not to over specify behavior
Keep it short, keep it simple: main flow should fit on a single page
Focus on what, not how
➢ Be careful not to under specify behavior
Do not forget variations on basic flow
Do not forget exceptions (cover both valid and invalid inputs)

✓ Think of use cases before use case diagram

✓ Do not spend too much time on the use case diagram – the
textual description is the most important part
✓ Avoid too much use of "extends" and "includes" in use case
diagrams
 Recall: Summary
♦ Scenarios:
Great way to establish communication with client
Different types of scenarios: As-is scenario, visionary scenario,
evaluation scenario and training scenario
♦ A use case:
represents an abstraction of a set of similar scenarios
described as a set of main steps (events) with alternative (exceptional)
behavior
Can be generated by:
➢ identifying the stakeholders' goals and sub-goals, or
➢ analyzing domain’s scenarios
♦ Flow of Events can be written using:
➢ single column
➢ double columns (Request-Response Interaction)
♦ Each <<extends>> relationship comes with extension points
 Best Practices
«extend»

UML standard Best practice

 Best Practices
Typical Errors To Avoid

▪ Use case diagrams do not model processes/workflows!

 Best Practices
Typical Errors To Avoid

▪ Actors are not part of the system, hence, they are positioned
outside the system boundaries!
 Best Practices
Typical Errors To Avoid

▪ Many small use cases that have the same objective may be
grouped to form one use case

✓
 Best Practices
Typical Errors To Avoid

▪ The various steps are part of the use cases, not separate use cases
themselves! -> NO functional decomposition

✓
 Notation Elements (1/2)
Name Notation Description

Boundaries between the system

System
and the users of the system

Use case Unit of functionality of the system

Actor Role of the users of the system

 Notation Elements (2/2)
Name Notation Description

Relationship between use cases

Association
and actors

Inheritance relationship between

Generalization
actors or use cases

Extend B extends A: optional use of use

relationship case B by use case A

Include A includes B: required use of use

relationship case B by use case A
 Benefits of Use Case-Based Software
Development
♦ They can help to define the scope of the system
♦ They are often used to plan the development process
♦ They are used to both develop and validate the
requirements
Simple, easy to create
All stakeholders understand them
Often reflect user's essential requirements
Separates normal behavior from exceptional behavior
♦ They can form the basis for the definition of test cases
♦ They can be used to structure user manuals