Lecture 3:

Requirements and Use Cases

• Requirements capture
• Requirements modelling
• Use-cases
• UML Use-Case Diagrams
– Basic notation
– Use-Case Descriptions
– Other notation: generalizes, includes, extends

BK - Spring 2006
 Requirements Capture
• Aim to develop system to meet user needs
• Capture user requirements capture through:
– Background reading/research
– Interviews with users/clients
– Observation of current practices
– Sampling of documents
– Questionnaires
• This is hard!

BK - Spring 2006
 Functional and Non-Functional
Requirements
• Functional requirements:
– What processing system must perform
– Details of inputs and outputs
– Details of data held by system
• Non-functional requirements:
– Performance criteria (time/space)
– Security
– Usability requirements
– HCI issues

BK - Spring 2006
 ATM Case Study:
Statement of Purpose
The design task is to implement an Automated
Teller Machine (ATM):
“An ATM is an electronic device designed for
automated dispensing of money. A user can withdraw
money quickly and easily after authorization. The
user interacts with the system through a card reader
and a numerical keypad. A small display screen
allows messages and information to be displayed to
the user. Bank members can access special
functions such as ordering a statement”

BK - Spring 2006
 ATM Case Study:
Requirements Summary
1. To allow card holders to make transactions
1. To view and/or print account balances
2. To make cash withdrawals
2. To allow bank members to access special services
1. To order a statement
2. To change security details
3. To allow access to authorized bank staff
1. To re-stock the machine
4. To keep track of how much money it contains

BK - Spring 2006
 Use Cases
• Use cases used to model functionality:
– What system does, not how
– Focus on functionality from users’ perspective
– not appropriate for non-functional requirements
• UML use case diagrams:
– Document system functionality
– Useful for communicating with clients/users
– Supported by more detailed descriptions of system
behaviour (e.g. text documents, other UML diagrams)

BK - Spring 2006
 UML Use Case Diagrams
Communication
association
Withdraw (Sub)system
Cash boundary

Check
CardHolder
Balance

Actor Use case

BK - Spring 2006
 Basic Notation
• Use case diagrams show:
– Actors: people or other systems
interacting with system being
modelled
– Use cases: represent sequences
of actions carried out by the
Withdraw
system Cash
– Communication: between actors
and use cases

BK - Spring 2006
 Behaviour Specifications
• Document sequence of actions carried out by system to
realize a use case
– Other UML diagrams: e.g.
• sequence diagrams
• activity diagrams
– Textual description:
• use-case descriptions
• use-case scenarios

BK - Spring 2006
 Simple Use Case Description
• Outline of typical course of events:
– The primary “flow” or “path”
• ATM system example:
Withdraw Cash:
The card holder selects the withdraw cash menu, which
is displayed by the system. The card holder selects an
amount of cash. The system debits the user’s account,
returns the user’s card and issues the requested
money.

BK - Spring 2006
 Elaborated Use-Case Description
Withdraw Cash: basic course of events
1. The user selects the cash withdrawal option
2. The system displays the cash withdrawal menu
3. The use selects the required amount of cash
4. The system returns the user’s card
5. The user takes the card
6. The system dispenses the cash
7. The user takes the cash

BK - Spring 2006
 Alternative Courses of Events
• Use case represents a typical case of interaction
• For example, there may be many Withdraw Cash
scenarios where no cash is withdrawn!
– Card holder has insufficient funds on account
– ATM cannot connect to bank’s system
– ATM does not contain enough cash
– Customer cancels the transaction for some reason

BK - Spring 2006
Withdraw Cash - Alternative Course of Events

Withdraw Cash -- insufficient funds available

1. The user selects the cash withdrawal option
2. The system displays the cash withdrawal menu
3. The user selects the required amount of cash
4. The system reports that there are insufficient funds available and
the use case terminates

BK - Spring 2006
 Other Types of Relationship
• Generalizes:
– Permits actors/use cases to inherit properties of more
general actors/use cases
• Include:
– Permits use case to include functionality of another use
case
• Extend:
– Allows for optional extensions of use case functionality

BK - Spring 2006
 Generalizes Relationship
BankMember
specializes Withdraw
CardHolder Cash

CardHolder
Check
Balance

Generalizes
Relation Order
Statement
BankMember

BK - Spring 2006
 Include Relationship
Select Account is
included in each of Withdraw
the use cases Cash «include»

«include»
Check Select
Balance Account

BankMember
Order «include»
Note: include was Statemen
formerly called uses t

BK - Spring 2006
 Include Relationship
Check Balance: basic course of events

1. The user performs the ‘Select Account’ use case

2. The system displays the main menu
3. The user selects the check balance option
4. The system displays the user’s balance

BK - Spring 2006
 Extend Relationship
CardHolder has the option of
printing out a balance when the
Check Balance use case is Print
Balance
invoked. «extend»

Check
Balance
Extend
CardHolder relationship

BK - Spring 2006
 Extend Relationship
Check Balance: basic course of events (revised)

1. The user performs the ‘Select Account’ use case

2. The system displays the main menu
3. The user selects the display balance option
4. The system displays the user’s balance
5. The user optionally performs the ‘Print Balance’ use case.

BK - Spring 2006
 Summary
• Use case analysis often a first step in system development:
– provide high-level view of system functionality (what rather than
how) and its users
– A use case represents a typical course of events
• UML use case diagrams
– Contain actors, use cases and associations
– supported by behaviour specifications (e.g. use-case descriptions)

BK - Spring 2006