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 Example actor: Customer
 Identify and refine actors’ Goal: Access account 24/7 for
goals regular banking operations
 Why would actor AAA use the (withdrawal, deposit, statement...)
system? in a timely and secure way.

 Identify actors’ tasks to meet To be refined into sub-goals.

goals From goals we can identify tasks:
 What interactions would meet Withdraw Cash, Make Deposit,
goal GGG of actor AAA? 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
[Invalid card]
The ATM outputs the card and stops the
Actor steps interaction.
1. 1.The Bank Customer inserts the
card into the ATM.[Invalid
card] [Invalid PIN]
The ATM announces the failure and
offers a 2nd try as well as canceling the
3. The Bank Customer types in PIN. whole use case. After 3 failures, it
[Invalid PIN] announces the possible retention of the
card. After the 4th failure it keeps the
card and stops the interaction.
5. The Bank Customer selects an
account .
[Amount over limit]
The ATM announces the failure and the
7. The Bank Customer inputs an available limit and offers a second try
amount. [Amount over limit] 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>>: Functional
 Problem:
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

Thevarious 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