IFS231

Unit 4 Welcome to IFS231 – 2021

Requirements analysis
(part 2)
Documenting requirements
Orientation for online teaching and learning programme
 Learning objectives

At the end of Unit 4 slides, you should be able to:

1. Document requirements using UML use case modelling

2. Draw UML use case diagrams
3. Write the associated use case descriptions for use case
diagrams
4. Use business analysis tools and documents to communicate
requirements
5. Analyze potential value of and recommend solutions
 Requirements Analysis in the SDLC

The Requirements Analysis process consists of two parts:

1. Requirements Gathering & Elicitation [UNIT 3]:

• Definition of the system in terms understood by the
customer (“Problem Description/Definition”)

2. Requirements Analysis & Documentation [UNIT 4]:

• Technical specification of the system in terms
understood by the developer (“Problem Specification”)
Unified Modelling Language (UML) (1)
• UML enables team members to collaborate by providing a
common language that applies to many different systems.
• It enables you to communicate solutions in a consistent, tool-
supported language.
• UML has become the standard for modelling software systems
• As a BA, you might not write UML diagrams yourself but you
will still need to interpret UML diagrams.
• Modelling is a means to capture ideas, relationships,
decisions, and requirements in a well-defined notation that
can be applied to many different domains.
• Modelling can use different pieces of UML depending on what
you are trying to convey.
Pilone and Pitman, 2005
 Unified Modelling Language (2)
• A UML model is made up of one or more diagrams
• A diagram graphically represents things and the relationships
between these things.
• These things can be representations of real-world objects,
software constructs or a description of the behaviour of some
other object.
• Each diagram represents a particular interest or view of the
thing being modelled.
• UML 2.0 divides diagrams into structural diagrams and
behavioural diagrams .

Pilone and Pitman, 2005

 UML 2.0 – types of diagrams (1)
Structural diagrams
Structural diagrams are
used to capture the
physical organisation of
the things in your system
(how one object relates to
another.
Pilone and Pitman, 2005
Behavioural diagrams
Behavioural diagrams
focus on the behaviour of
elements in a system. For
example, you can use
behavioural diagrams to
capture requirements,
operations, and internal
state changes for
elements.
 UML 2.0 – types of diagrams (2)

Structural diagrams Behavioural diagrams

• Class diagrams
• Component diagrams
• Composite structure
diagrams
• Deployment diagrams
• Package diagrams
• Object diagrams
• Activity diagrams
• Communication diagrams
• Interaction overview
diagrams
• Sequence diagrams
• State machine diagrams
• Timing diagrams
• Use case diagrams

Pilone and Pitman, 2005

 What is a Use Case model?
• A use case captures the requirements of the system by
illustrating the relationship between a system and its users
(called actors).
• A use case can be drawn as a diagram containing:
• Actors (roles) as stick-persons, with the role name below.
• Use cases as ellipses with their names below or inside.
• Associations indicated by a line connecting an actor to a use
case in which that actor participates.
• Use cases can be connected to other use cases that it uses.
• Use cases help us to discover/document functional
requirements
• Use cases are the ways in which a system can be used (the
functions which the system provides to its users)
• A use case is a contract of an interaction between the system
and an actor.
 What is a use case?
• A use case is a scenario that describes the use of a system by
a user (role) to accomplish a specific goal.
• A use case indicates how each user interacts with the system
interface.
• A scenario is a sequence of steps that describe the
interactions between a user (role) and the system.

Use Case script/formal

user Use case diagram use case

A full use-case model comprises of two parts:

Use Case Diagram: describing
Formal Use Case: A document
relationships between use-cases
describing the use case in detail
and actors.
 Illustrating requirements
• Use case modelling is used to illustrate the functional
requirements of a system and how users interface with system.
• Use case models are a type of UML behavioural diagram, used to
capture system requirements, operations, and internal state
changes for elements.
• A use case model consists of the collection of all use case
diagrams and associated use case descriptions
Use cases (diagrams & descriptions)

Parts of Use Actors

Case model
Use case relationships

Use case goals and levels

 Example of simple Use Case Diagram
System name
Banking system
Actor Association

open account

Role of actor
customer

System boundary
Use case
 Example of simple Use Case Description

• Operate an insurance policy (usually takes

Goal
years to get to maturity)
Primary Actor • The customer

Scope • The insurance company ("MyInsCo")

Level • Strategic ("white")

• 1. Customer gets a quote for a policy.

• 2. Customer buys a policy.
Steps:
• 3. Customer makes a claim against the policy.
• 4. Customer closes the policy
 Use cases vs. internal features

• consider software to run a cell phone:

Use Cases Internal Functions

◼ call someone ◼ transmit / receive data
◼ receive a call ◼ energy (battery)
◼ send a message ◼ user I/O (display, keys, ...)
◼ memorize a number ◼ phone-book mgmt.

Point of view: user Point of view: developer /

designer
14
 Do use cases capture these?
• Which of these requirements should be represented directly in
a use case?
– Order cost = order item costs * 1.06 tax.
– Promotions may not run longer than 6 months.
– Customers only become Preferred after 1 year.
– A customer has one and only one sales contact.
– Response time is less than 2 seconds.
– Uptime requirement is 99.8%.
– Number of simultaneous users will be 200 max.
Answer: NONE. Most of these requirements are non-functional, so
the use cases wouldn't explicitly mention them. The user doesn't
see them directly in the success scenario.

a non-functional requirement is a requirement that specifies criteria

that can be used to judge the operation of a system 15
 Actors (1)

• An actor is an external agent that interacts with the system,

exchanges information with the system (e.g. user, sub-system,
etc.)
• An actor is a user playing a role with respect to the system.
Examples are different types of users and other systems.
• Multiple users or groups of users may have the role depicted
by one actor and similarly, a single user may assume the
responsibility of multiple actors

actor
 Actors (2)

• anything with behaviour that acts on the

Actor
system

Primary • initiates interaction to achieve goal

actor (when system is a software product,
primary actor is often the computer user)
Supporting
• performs sub-goals to help use case
actor

• anyone interested in the system

Stakeholder
• examples: supplier, stock agency, vendor

What is the difference between an actor and a stakeholder?

A stakeholder might not "act" in any scenario
 Use Case Relationships
• There are four types of relationships in Use Case modelling.
Each relationship has its own purpose and notation
Relationship Purpose Notation
Association Denotes a relationship between an
actor and a use case

Generalisation Denotes inheritance between use

cases

Include Includes the functionality of one use <<include>>

case in another use case

Extend Extends the functionality of one use <<extend>>

case to another use case, under
certain conditions.
 Association

• Associations between actors and use cases is the most

common type of association in a use case diagram.
• This association is drawn as a solid line without arrow heads
as shown in the example below. No label is attached to this
type of association.
Association
Association Example
 Generalization
• Refers to the relationship which can exist between two use
cases and which shows that one use case (child) inherits
the structure, behaviour, and relationships of another actor
(parent).
• The child use case is also referred to the more specialized use
case while the parent is also referred to as the more
abstract use case of the relationship.
Parent

Child
Include
Include Examples
 Extend

• Extends the functionality of one use case to another under

certain conditions
• Extending use case typically defines optional behaviour that is
not necessarily meaningful by itself.
• The extend relationship is owned by the extending use case.
 Uses vs Extends
• What’s the difference between <<uses>> and
<<extends>>?
• - <<Uses>>, use one’s functionality to complete the
task whereas, <<extends>>, provide extended
functionality or properties to a task to make it run to
completion.
• “A uses B” represent that task “A” has a subtask “B”.
This tells us that A has to go towards completion first
then task B has to be completed.
• “A extends B” indicates that task “A” is a specific case of
“B”. It tells that “A” has added functionality to make the
process “B” runs to completion.
25
Relationships compared
 Example 1 - Class discussion

ATM Example
Request
assistance <<include>> Replenish
cash
<<extend>>
Make
withdrawal <<include>>
Remove
Make Make cash
transaction deposit
Check
Bank
<<extend>>
Cancel balance Secure
User option facility
Make
payment

Via Cash
Via EFT
deposit
 Example 2 - Class discussion
Control System

Scan

Set limits
Liason Physicist

Take profile
Experimental
Physicist

Calibrate

Hardware Specialist 28
 Example 3 - Class discussion
Food delivery system

Order Food

Customer
Service Person
Hire Employee

Applicant

Reorder
supplies
<<uses>> Manager
Supplier
Track sales
and inv. data <<uses>>
Produce
mgt. reports

29
 What is a use case?
• A use case is a scenario that describes the use of a system by
a user (role) to accomplish a specific goal.
• A use case indicates how each user interacts with the system
interface.
• A scenario is a sequence of steps that describe the
interactions between a user (role) and the system.

Use Case script/formal

user Use case diagram use case

A full use-case model comprises of two parts:

Use Case Diagram: describing
Formal Use Case: A document
relationships between use-cases
describing the use case in detail
and actors.
 Example of use cases
• Informal use case: written as a paragraph describing
the scenario
• Example:

Customer Loses a Tape

• The customer reports to the clerk that he has lost a tape.
• The clerk prints out the rental record and asks customer to
speak with the manager, who will arrange for the customer
to pay a fee.
• The system will be updated to reflect lost tape, and
customer's record is updated as well.
• The manager may authorize purchase of a replacement tape.
31

Use cases
Use cases in a business
system
"A sequence of transactions in
a system whose task is to yield
a result of measurable value
to an individual actor of the
business system“ (Jacobson
1995)
define specific
behaviour or
functions.
Use cases in an information
system
"A behaviorally related sequence
of transactions performed by an
actor in a dialogue with the
system to provide some
measurable value to the actor"
(Jacobson 1995)
32
 Benefits of doing use cases

• Shortest summary of what the system will

The list of goal names contribute
provides executives with • Project planning skeleton (priorities & timing)

• All agreement as to the system’s

The main success responsibilities
scenario provides

The extension conditions • List of things programmers have to watch

provide programmers for
with: • List of things analysts have to investigate

The extension handling • A record of (tricky) business policy decisions

steps provide dev team
with:
33
 Pros and cons of use cases

Pro: Con:

• they hold functional • they show only the

requirements in an functional
easy-to-read text requirements
format • design is not done
• they make a good only in use case units
framework for
non-functional
requirements &
project scheduling
34
 3. Formal Use case description (1) - template
Use Case Name MAKE CALL
Description This is a use case where the user uses a device to connect electronically
with someone on the other side of a call…[or something like this]
Goal Level Strategic – “white”: Strategic-level use cases typically take many hours,
days, weeks, months, or years to complete
User goal – “blue”: Is the goal of the primary actor trying to get work
done. This might also be called “user's task”
The tests for a user-goal usually are:
• Is it done by one person, in one place, at one time (2-20 minutes)?
• Can I go to lunch as soon as this goal is completed?
• Can I ask for a raise if I do many of these?
Sub function – “black”: Low level detail
Actor/s Remember the NOUNS in paragraph
what computers, subsystems and people will drive our system? (actors).
Examples: Customer, Clerk, Corporate Mainframe
Precondition/s Simple assertions about the state of the world at the moment the use
case opens e.g. The user is logged on.
Think about your <<includes>>
Assumptions What assumptions have you made about the stakeholders, business or
requirements that have some influence over how the requirements are
35
interpreted?
 3. Formal Use case description (2) - template
Postcondition/s Simple assertions about the state of the world at the completion of
the use case
Main success scenario main success scenario is the preferred "happy" case
example: customer=good credit and item=in stock
1. Give a numbered list of steps
Failure Extensions Usually, almost every step can fail
example: customer has bad credit
example: item is not in stock in desired quantity
Use numbered list above e.g.
1a. failure extension for number 1 above
Error handling How system handles each failure extension
recoverable extensions rejoin main course
example: low credit + valued customer -> accept
example: low stock + reduce quantity -> accept
non-recoverable extensions fail directly
not a valued customer -> decline order
out of stock -> decline order
Use numbered list above e.g.
1a1. Error handling for failure extension of 1a above
36
 Use case goals and levels

• A goal is an action that actor wants to accomplish

• A level refers to the type / scope of a goal
strategic goals ("above sea level"): multi-sitting
user goals ("sea-level"): one sitting
subfunctions ("below sea level"): partial

White strategic goal

Blue
user goal
Indigo
subfunction
37
 Differences between goal levels

• Strategic or "white" (anything above "blue") use

cases use a cloud,
• User-goal or "blue" use cases use a person at a
screen,
• Subfunction or "indigo" use cases use a pitchfork.
 Strategic goals (white)
• Cockburn uses colours to explain different goal levels.
• See page 47 of Writing effective use cases
• The colour “White” is used for describing strategic use cases
• "That use case is really white, 'way-up-in-the-clouds' white."
• Strategic-level goals involve multiple user-task level goals.
• They serve three purposes:
– showing the context in which the system services must
function,
– showing life-cycle sequencing of related goals,
– providing a table of contents for the lower-level use cases
(both lower-level white use cases and blue use cases).
• Strategic-level use cases typically take many hours, days,
weeks, months, or years to complete.
 User goals (blue)
• Is the goal of the primary actor trying to get work done
• This might also be called the “user's task”
• It corresponds to “elementary business process” in the
business process engineering literature
• A user goal addresses the question: “Does your job
performance depend on how many of these you do
today?”
• The tests for a user-goal usually are:
– Is it done by one person, in one place, at one time (2-20
minutes)?
– Can I go to lunch as soon as this goal is completed?
– Can I ask for a raise if I do many of these?
 User Goal Level explanation (cont.)

• Is ‘Log on” an example of a user goal?

– does not generally count as a user goal as it fails
this test - logging on 43 customers
– times in a row does not (usually) satisfy the user’s
job responsibilities.
• On the other hand, “Register a new customer” is
likely to be a meaningful user goal.
• Registering 43 new customers has some significance.
 Example of “blue” goal of the Use Case

• Blue is used for goal of the User Cases

• "You are a clerk sitting at your station. The phone
rings, you pick it up. The person on the other end
says, " ... ". So you turn to your computer, and what
is on your mind is that you need to accomplish <X>.
You work with the computer for a while, and the
customer, and finally accomplish <X>. You turn away
from the computer, and hang up the phone."
 Subfunction goals ("indigo"/"black")

• Subfunction-level goals are those needed to carry out

user-task goals
• They are only included as needed.
• Examples of indigo use cases are "Find a product",
"Find a Customer", "Save as a file.“
• We use the color "black" to mean, "this is so low
level, please don't even expand it into a use case"
 Styles of use cases

1. actor / goal list (shows all use cases in system)

2. UML use case diagram

3. Formal use case description (written)

Let's examine each of these in detail...

44
 1. Actor / goal list
• it can be useful to create a list or table of actors and their
"goals" (use cases they start):
ACTORS USE CASE
Club Member Initiates Submit Promotion Order
Submit Regular Order
Potential Member Initiates Submit New Subscription
Past Member Initiates Submit Subscription Renewal
Membership Services Dept. Initiates Request Membership
Marketing Department Initiates Create New Monthly Promotion
Create New Seasonal Promotion
Create New Subscription Program
Request Promotion Reports
Request Sales Reports
Membership Services Initiates Send New Subscription Offer
System Send Club Promotion
Send Subscription Renewal 45
 3. Formal Use case description (template)
USE CASE NAME Submit Promotion Order
ACTOR Club Member
DESCRIPTION Describes the process when a club member submits a club promotion order to
either indicate the products they are interested in ordering or declining to order
during this promotion
MAIN SUCCESS 1. This use is initiated when the club member submits the promotion order to
SCENARIO be proceeded
2. The club member's personal information such as address is validated against
what is currently recorded in member services
3. The promotion order is verified to see if product is being ordered
4. The club member's credit status is checked with Accounts Receivable to make
sure no payments are outstanding
5. For each product being ordered, validate the product number
6. For each product being ordered, check the availability in inventory and record
the ordered information which includes "quantity being ordered" and give each
ordered product a status of "open"
7. Create a Picking Ticket for the promotion order containing all ordered
products which have a status "open"
8. Route the picking ticket to the warehouse
PRECONDITION Use case “send club promotion” has been processed
POST CONDITION Promotion order has been recorded and the picking ticket has been routed to
the warehouse
46
ASSUMPTIONS
 3. Formal Use case description (1) - template
Use Case Name MAKE CALL
Description This is a use case where the user uses a device to connect electronically
with someone on the other side of a call…[or something like this]
Goal Level Strategic – “white”: Strategic-level use cases typically take many hours,
days, weeks, months, or years to complete
User goal – “blue”: Is the goal of the primary actor trying to get work
done. This might also be called “user's task”
The tests for a user-goal usually are:
• Is it done by one person, in one place, at one time (2-20 minutes)?
• Can I go to lunch as soon as this goal is completed?
• Can I ask for a raise if I do many of these?
Sub function – “black”: Low level detail
Actor/s Remember the NOUNS in paragraph
what computers, subsystems and people will drive our system? (actors).
Examples: Customer, Clerk, Corporate Mainframe
Precondition/s Simple assertions about the state of the world at the moment the use
case opens e.g. The user is logged on.
Think about your <<includes>>
Assumptions What assumptions have you made about the stakeholders, business or
requirements that have some influence over how the requirements are
47
interpreted?
 3. Formal Use case description (2) - template
Postcondition/s Simple assertions about the state of the world at the completion of
the use case
Main success scenario main success scenario is the preferred "happy" case
example: customer=good credit and item=in stock
1. Give a numbered list of steps
Failure Extensions Usually, almost every step can fail
example: customer has bad credit
example: item is not in stock in desired quantity
Use numbered list above e.g.
1a. failure extension for number 1 above
Error handling How system handles each failure extension
recoverable extensions rejoin main course
example: low credit + valued customer -> accept
example: low stock + reduce quantity -> accept
non-recoverable extensions fail directly
not a valued customer -> decline order
out of stock -> decline order
Use numbered list above e.g.
1a1. Error handling for failure extension of 1a above
48
 Qualities of a good use case

• Starts with a request from an actor to the system

• Ends with the production of all the answers to the
request
• Defines the interactions (between system and actors)
related to the function
• Takes into account the actor's point of view, not the
system's
• Focuses on interaction, not internal system activities
• Doesn't describe the GUI in detail
• Has 3-9 steps in the main success scenario
• Is easy to read
49
 Formal use case elements
(goal of primary actor) (level of goal [strategic, user, subfunction])

(primary actor)
"Place an order" (User goal / Clerk)
Main scenario: (action steps:
full sentences showing
1. Clerk identifies customer, item and quantity. who takes the action!
2. System accepts and queues the order. 3 - 9 steps long.)

Extensions: (condition causing different actions)

1a. Low credit & Customer is 'Preferred':
1a1. System gives them credit anyway. (action step(s)
handling those conditions)
1b. Low credit & not 'Preferred' customer:
1b1. Clerk performs Sign Up Preferred Customer scenario and
accepts only prepayment.
2a. Low on stock: Customer accepts rain-check: (calling another use case)
2a1. Clerk reduces order to available stock level.

50
Other formal use case examples

51
 Other formal use case examples
Use Case 12. Buy stocks over the web
Primary Actor: Purchaser (user) Scope: PAF
Level: user goal Precondition: User already has PAF open.
Guarantees: sufficient log information exists that PAF can detect what went wrong.
Success Guarantees: remote web site acknowledged purchase, user's portfolio updated.

Main success scenario:

1. User selects to buy stocks over the web.
2. PAF gets name of web site to use (E*Trade, Schwabb, etc.)
3. PAF opens web connection to the site, retaining control.
4. User browses and buys stock from the web site.
5. PAF intercepts responses from the web site, and updates the user's portfolio.
6. PAF shows the user the new portfolio standing.

Extensions:
2a. User wants a web site PAF does not support:
2a1. System gets new suggestion from user, with option to cancel use case.
3a. ... 52
 Precondition
• See page 54 in Cockburn document.
• Sometimes the use case will only be triggered if the user is
already logged on and validated, or some other condition is
known to be true.
• Writing style: The Precondition is written as simple assertions
about the state of the world at the moment the use case
opens.
Suitable examples are:

• Precondition: The user is logged on.

• Precondition: The customer has been validated.
• Precondition: The system already has located the customer's policy
information.
 Main success scenario (MSC)
• See page 56 in Cockburn
• A scenario is written as a sequence of goal-achieving actions
by the primary actor, secondary actors and the system under
design
• Overall Writing Style:
• "At time z, actor y does x to actor w with data v"
• Using the “verb” to indicate some active, goal-forwarding
verb, an interaction sentence typically looks like:
• "Actor1 verbs actor2 with some data."
• For the other kinds of actions, the validation and the state
change, the core sentence forms are:
• "The system verifies that the something meets some
criteria."
• "The system changes the something to reflect something."
Example 1 - Class discussion
 Basic template
• Use Case: <number> <the name should be the goal as a short
active verb phrase>
• Characteristic Information
• <a longer statement of the goal, if needed, its normal
Context of use
occurrence conditions>
• <design scope, what system is being considered black-
Scope
box under design>
Level • <one of: Strategic, User-goal, Subfunction>

Primary Actor • <a role name for the primary actor, or description>

Stakeholders & Interests • <list of stakeholders and key interests in the use case>

Precondition • <what we expect is already the state of the world>

Success End Condition • <the state of the world upon successful completion>

Failed End Protection • <the state of the world if goal abandoned>

Trigger • <what starts the use case, may be time event>

 A method to do use cases modelling

• Now that we know the syntax for doing use cases, what 4
steps does Cockburn recommend when actually
brainstorming and writing our use cases?
1. identify actors and their goals
2. write the main success scenario (MSC)
3. identify and list possible failure extensions
4. describe how the system handles each failure

Let's look at each step in detail...

57
 1. Identify actors and goals

Ask oneself the following questions:

• what computers, subsystems and people will
drive our system? (actors)
– examples: Customer, Clerk, Corporate Mainframe
• what does each actor need our system to do?
– each need may show up as a trigger to a use case
• result: a list of use cases, a sketch of the system
– short, fairly complete list of usable system function
– can now draw UML use case diagram for reference

58
 Exercise: Identify actors/goals

• Together, let's identify some major actors and their goals for
software for a video store kiosk system:
• The software can be used for looking up movies and actors by
keywords, as well as usable to check out movies from the kiosk
to known customers, without a cashier present.
• A customer can check out up to 3 movies at a time, for up to 5
days each.
• If a movie is returned late, late fees can be paid at the time of
return or time of next checkout.
• The data is stored internally in a database system, which
communicates with the kiosk.
• The manager of the store can log in to update employee data.
59
 2. Write the MSC

• Main success scenario is the preferred "happy" case

– Example: customer= good credit and item=in stock
– Easiest to read and understand
– Everything else is a complication on this
• Capture each actor's intent and responsibility, from trigger to
goal delivery
– Say what information passes between them
– Number each line *crucially important

Class exercise: let's do this for the customer returns a movie

scenario.

60
 3. List the failure extensions

• Usually, almost every step can fail

– Example: customer has bad credit
– Example: item is not in stock in desired quantity
• Note the failure condition separately, after the main success
scenario
• Remember the numbering that follows the MSC
Class exercise: let's do this for the customer returns a movie scenario.

61
 4. Describe failure/error-handling
• Recoverable extensions rejoin main course
– Example: low credit + valued customer -> accept
– Example: low stock + reduce quantity -> accept
• Non-recoverable extensions fail directly
– Not a valued customer -> decline order
– Out of stock -> decline order
• Each scenario goes from trigger to completion
– "Extensions" are merely a writing shorthand
– Can write "if" statements
– Can write each scenario from beginning to end
• Remember the numbering to follow the Failure extensions

Class exercise: let's do this for the customer returns a movie

scenario. 62
 Example 2 - Class discussion
• A digital alarm clock shows the time of day
• Using buttons, the user can set the hours and minutes fields
individually
• The user can choose between 12-hours and 24-hour display
• It is possible to set one or more alarms
• When the alarm goes off, it will make a noise/sound.
• The user can turn the alarm off or press the ‘snooze’ button
• ‘Snoozing means to turn off the sound but the alarm will go
off again after a few minutes delay.
• The snoozing time is adjustable and the user may or may not
want to set the snoozing time.
• If the user does not respond at all, the alarm will turn off after
2 minutes 63
 Example 2 - Solution
Alarm Clock System
24 hour
Set display display
mode 12 hour
display Display
hours
<<include>>
Set clock Display
<<include>>
time minutes
Set alarm Set day
<<extend>>
time Set Snooze
duration
Set
month
Set <<include>>
User date
Set year
Disable
alarm

<<include>> Make
Enable sound
alarm <<extend>> Activate
Snooze
64
 Example 2 - Class discussion

• Now write out the formal

use case description for
“SET ALARM” using the
template

65
 Example 2 - Solution
Use Case Name Set Alarm
The user sets the alarm to the preferred time, in order for it to
Description
be activated at the required time
Goal Level User goal
Actor/s User
The alarm clock must be switched on
Precondition/s
The date and time must be set in real time
1. User selects alarm option
Main success 2. User selects the hours of the desired alarm time
scenario 3. User selects the minutes of the desired alarm time
3. User verifies selection by pressing ‘set’ button
1a. The setting time button is pressed instead of the alarm
Failure extension button
3a. The selection is incorrect
1a1. The user goes back and presses the set alarm button
Error handling
3a1. The user restarts the process of setting the alarm
 Think – pair – share class exercise
• Consider the case of a video store that wants a kiosk with
intelligent software that can replace human checkout workers.
• A customer with an account can simply use their membership
and credit card with a reader at the kiosk to check out a video.
• Come up with 5 use case names for such software, and draw a
UML use case diagram of these cases and their actors.
• Write a formal (complete) use case for the Customer Checks Out
a Movie scenario.

67