Use Case Metho

LEARNING GOALS

After reading this chapter a student should be able to:

1. Identify actors participating in a system.
2. Specify requirements of systems with use cases.
3. Document use cases systematically.
4. Draw use case diagram.
5. Develop test cases to test a system.

have seen in the previous chapters how system requirements specifications ate
Weexpanded from a fuzzily stated user requirements to a set of document low
diagrams, data flow diagrams, process specifications and decision tables. This set of
methods together is known as structured systems analysis and design. Another method
called object oriented systems analysis and design has also become popular during the last
few years. There are some advantages in using object oriented methods. However, the
tools used in structured methods, namely,data flow diagrams, documents flow diagrams,
decision tables are all useful in designing information systems. Use case method was
proposed by Jacobson [33] in the 90s as one of the tools useful in object oriented systems
analysis and design primarily to specify users' requirements. He developed a
diagramming method to develop use cases. The method was adopted by several designers
and modified based on their experience of using it in many large software design projects.
Atextual method of writing use cases describing the behaviour of asystem was proposed
by Cockburn [17] in early 2000. It will be described in this chapter along with use case
diagrams.

10.1 WHAT IS A USE CASE?

Simply stated a use case specifies in detail the behaviour of a system being developed to
meet a set of goals. We will first explain some terms used in writing use cases. This is
136
 Use Cose Method 137
Used in literature. terminology
met by the system. the
accepted

to be
lt should with
Every use case has atitle. The
BiIthe goal
customer. The System we are concerned use isan called
actiontheverbsconesuchof as:
a use case.
rties whointerac with the system and are interested in its success are called the Receive
All the persons or
system.

inthe goal of, a use case are entities who actually

ulin the called act0rs. In a use caseperform some tasks in
as well as secondary actors. rTimary actors initiate first action.
scenarioPreconditions
there may
n t e r
to
what holdstrue hefore ause case. Ihese are often assumptions made by a systems
what holds true after a specify
use case is completed.
enariois. a case when all goes according to plan. Exceptions
Guarantees

are what couldMaingo success

wrong
nalyst
what actions are needed in case and
such cases. We will now
example of a use case description corresponding to the example
u r i n ga u s e

give an
requirement statement
5.1 which we reproduce below for
S e c t i o
ready reference.
n

requirements. "Our
in,

giien narrative of company receives a number of items from

at the receiving office. As we receive over 1000 items amany
received

they are
1
' s e r ' s a n d

for the receiving office to checkimpossible day

vendors Virtually
an order, or sent a wrong
whether the vendor has
nOY
item and inform the purchase office. We
against

tabletofind out if there are excesses or

i t e m s

it
is
suppled deficiencies in delivery and whether
to the delivery schedule as per the order. The
items received at the
a r e
a l s o
n o t

adhered

vendor
for physical inspection. The physical inspection consists
are sent
of
the quantities stated in the delivery note agree with the physical count,
e c e i v i n go f f i c e

the
wvhether

the correct one ordered, and acheck on the quality of

checking
itemis item. We would
[Link] rejections due to bad quality, incorrect items, excess or deficient
record of
a
to
k e e p

determinedduring inspection. This will enable us to assess vendors' reliability

ike
etc, orderssin the future, besides keeping track ofsupplies. Items
sUpply,

in placing cleared
togude
us
inspection
office are taken into the
inventory by the stores office which keeps a
and quantity available of each item. Customers send requisitions
stocked

bytheofitems
stores fulfill the requests based on availability and updates the ledger.
ledger
The
not able to meet some of our customers requests. We would like to
stores.

the
to we are
C u r r e n t l y ,

eautomatic reordering by our purchase office if the inventory level of an item

inCorporate

would also like to keep track of unfulfilled requests and meet them when items
We
islow. store.
Currently, we. are not able to pay our vendors promptly due to delays in
reach
the
order reachingour accounts office. We would like to rectify this. We wouldalso
payment

customers promptly
andI keep track of customers' payments.
our
like to
bilIl
10.1 in which there is a block labeled receiving office. We will
We refer to Figure
a use caSe corresponding to the receiving office.
develop first the behaviour of the receiving office software. The
of this use case is
The scope
of the system are the receiving
office clerk, purchase office, vendor and
the receiving office clerk. We will not be concerned
stakeholders

inspection
office.. The primary actor is
actors in this case.
with secondary
delivered by vendors
Use Case 1: Receive items
Receiving office clerk (ROC).
Primary actor:
items received.
Scope: Software which records
Purchase office, Inspection office.
Stake holders: Vendor, Receiving office,
 Intomuhor Systerrs
138 Anossond Design of

Payment to Deiivers iters

vendor

Vendor
Deilvery ncte

Rejected
Rejected items Disrscarcy tes
Qoods rote
advice ote
Purchase
order

Goods rejected note

Purchase office
Insoecton cfs
Rejected item

Items
Payment to vendor aCceptsd
Vendor
advice ote
invoice

Accounts office
Items taken in stock
Stores oftics
note-Pay vendor

Figure 10.1 Document flow diagram for goods received.

Goal: To store in a database relevant data on items received from vendos

Preconditions: Items ordered database available. Items delivered to ROC by
agents with delivery note. vend
Main Success Scenario
1. ROCreceives an item with delivery note from vendor. Delivery note has onier
vendor id, item id, quantity delivered, date.
2. ROC retrieves using order id as index a record from items ordered data bay
3. If order id, vendor id, item id match, ROCcompares quantity ordered with quanth
in delivery note and finds they are equal.
4. and
ROCfinds
compares delivery date specified in order with date in items delivensi NH
it is OK.
5. ROCenters delivery note details in items received database.
6. ROC sends items to inspection office with delivery note.
7. ROC signs delivery note copy and returns it to delivering agent.
 Use Cose Method 139
asantees: Items
received
database is updated if items
ordered by purchase office. received by receiving office
e m s

psath

eptions
delivered by vendor not found in items
ordered database., Action?
in delivery note greater than that ordered.
Items
Action?
2 in delivery note less than that ordered. Action?
ltems

3
in delivery note received on a date outside specified
4
Items

fails when vendor's agent arrives. Action? tolerance. Action?

C o m p u t e r

5
should be noted from the above
mUmber
of
points
example. They are:
A The requirements specification is structured in aform which is readable by any
user.
much more detal than users fuzzily stated requirements.
tclearly statesthe assumptions made, i.e., items are
witha delivery
note to the Receiving office and that delivered physically along
the clerk is to acknowledge
with areceipt in case of success.
4 Whenthere are exceptions there are question marks. In other words what the clerk
is supposed to do in such cases is not clearly specified in the requirements
statement.

ho actions to be taken on exceptions have to be clearly

in the use case.
stated and documented
LThe system will be developed based on the use case. Separate
documentation is
not usually required once actions to be takern inthe exception cases are specified.
1 Use case gives in detail primarily what behaviour is expected of the primary actor.

10.2 USE CASE EXAMPLES

We develop below a use case corresponding ordering items from vendor (Figure 10.2).

Vendor Stores office

Order to New purchase

vendor Reorder advice
requisition

Accounts office Purchase office

Purchase order copy

Figure 10.2 Document flow diagram for ordering goods from vendor.
 Informotion Systems
140 Analysis and Design of
from vendor
Use Case 2: Order items clerk(s)].
Purchase officer [Actual data entry by
Primary actor:
Scope: Order processing software.
Accounts officer, Vendor.
Goal: holders: Stores
Generate officer,
purchase order and sendto vendor. Store it in outstanding ieems ordereA
Stake

database.
Preconditions
which has item id, name
request received from stores office and
I. An
to
order
be ordered
tolerance (if any) by which
datedelivery
and in item is needed. The order request
shouldor
date. The order maybe a reorder advice
quanty
2. purchase
Purchase requisition.
office already has negotiated prices for common items. 1t is stored in

database along with vendor details.

Guarantees)
Main Success Scenario (or Success
Purchase order with delivery
address sent to vendor(s).
1.
2. Vendor(s) instructed on mode of deliveryto receiving office (by truck. or courier
3. Vendor acknowledges order and agrees to supply items ordered and sends invoi.
4. When items are shipped an invoice is sent to purchase office with copy of deliven
note.
Success Scenario details
received from stores (with authorization by purchase officer)
1. Request specilyingdate
item name, itemid, quantity, date needed withtolerance (if any) in delivery
2. Purchase officer finds rom vendor-item database vendor capability. nr
reliability index.
3. Purchase officer decides quantities to be purchased from each vendor and
negotiates price.
4. Purchase officer generates purchase order and enters it in item ordered database
5. Purchase officer sends purchase order copies to accounts office, stores office and
receiving office.
6. Purchase officer updates database of outstanding orders with details of order(The
order copies mentioned in 5 may be omitted if accounts office, stores office and
receiving office can access outstanding orders database).

Exceptions
1. Request from stores incomplete (no item id). Action?
2. No vendor found for item ordered in the vendor item database. Action?
3. Vendor(s) return order as they have no stock or unable to supply item on tte
price has to be revised. Action?
4. Does purchase office request quotes from other vendors for exception?
 Use Cose Method 141
gives in reasonable detail the behaviour expected
t h eu s e c a s e

hrrethat
from the
There are four exceptions which need clarification before
process,

the
developed. Use case often specify so called
office
Hnhase be minimum guarantees. These
whether allthe ctake holders interests are protected. In the above use case we can
C a n

N e 0

minimal guarantee as "If purchase office order process is unsuccessful for some
database will remain unchanged. Attempt at ordering
orders

along with reason why it tailed. No other database in the system accessiblewill
outstanding

to
be disturbed".
will|
willnowgive four more use cases corresponding to the document flow
h o l d e r s

diagrams
H i g u r e1 0 . 1 .

Inspection
of items sent by Receiving Office
Case.
3:
lse Inspection office staff (10S).
actor

Inspection Software.
P a i n a r v

hliters:
Receiving office, Stores office, Purchase office.
Sale Inspect actual item received with item received note. Find discrepancies (if any)
purchase office. Send accepted items to store.
report to
Pr-onditions:
nd Items received note has all requisite fields filled (order no., item id, item
q u a n t i t y ,
vendor id, vendor name and address, date delivered), Delivered items
ame,
from
ROC with relevant note.
Main Success S c e n a r i o

receives items with items received note from receiving office staff,(Physical
nG arrive with accompanying physical slip and also electronic record of the
physical slip).
2 10Sinspects items with note for quantity and quality. Quality OK and quantity
also OK.
lf checks successful sends items to store along with items received and accepted
note.
! lf checks not successful sends rejected note with rejected items to Purchase office.
5, The partial accepted note sent to stores office along with accepted itemns.
Exceptions
1lems delivered by vendor without corresponding delivery note. Action?
2 limost items pass quality and few rejected. Action? (Is serial no. 5 given in success
Scenario OK?)
. Iexcess items come and pass quality inspection what to do with excess?
4 If items found lesser than that written in delivery note. Action?
We see that there are anumber of exceptions in which action taken is not specified. They
ae to be specified for the use case to be completed.
Ne will now develop the use case of stores otfice (Pigure 10.1)
142 Analysis and Design of Information Systems

Use Case 4: Update inventory (by stores office)

Scope: Inventory update software
Primary actor: Stores officer (SO)
Stake lolders: Inspection officer, Accounts officer, Purchase officer.
Goal: Updateinventory when inspection office sends accepted items with
note.
Pre-conditions: Items inspected and accepted note received from inspection cor esponi
items delivered and taken in stock and the corresponding note correct office. P'hys
Main Success Scenario

1. Stores inventory database properly updated.

2. Items taken into stock note sent to accounts for its action.
Success Scenario Details
1. Items accepted note received from Inspection office containing
id, vendor name and address, item id, item name, quantity(order no.,
vendN
per item).
2. Pay vendor note sent to accounts office after updating inventory
accepted,pikg
3. Copies of item taken into stock note sent to purchase office
and accounts
Exceptions ofhkce
1. Stores inventory database corrupted while updating.
Action?
2. Accounts office computer not responding when items
to it. Action? (does it acknowledge receipt?) taken into stock
note sent
3. Accounts office expected to pay vendor for items
taken
database linked to corresponding vendor database? into stock. How is inventor
4. Should inspection office send
pay to vendor note to accounts office
accepted or should stores office send it? when item
In the above case we have taken only
of Figure 10.1. We have assumed the case corresponding to document
that stores flow diagram
also has to issue goods when primarily receive goods and
Inone case a store is a part ofrequisitioned by a customer. Three situationsstore it. Astore
can arise here
an organization such as a
are various departments arnd there University in which "customers
this case there is an internal debit is no explicit billing and collection of real money. n
by the value of the goods which debits the budget of the
issued. If the organization is, say, arequisitioning departmmt
bills to customers and collect
would be one in which a distributorcash or accept credit/debit card supermarket it will ge
payments. A thrd as
buys in bulk from a manufacturer.
customer will be sent an invoice along In this case t
period allowed for payment (may vary with goods and payments collected baseu u
the case corresponding to a store from one week to three months). We
internal willcosu
manufacturer who requisitions items to an organization such as a University 0
manufacturing operations (Figure 10.3).from an internal store to proceed with its o
 Use Case Method 143

Payment advice
Bill or debit note

Requisition Issue note

Stores office
Customer
Accounts office

Issue note

Items issued

Figure 10.3 Document flow diagram for items issued to customer.

Stores issues items requisitioned

Use Case 5:
Stores officer (SO).
actor:

issue items by stores and debit accounts of

Primary
Software to
customers.
Scope:

holders:
Customers, Accounts office, Purchase office.
Stake
Goal: Issue items requisitioned to customers. In case items not available notify customer
purchase
department. If issued notify accounts to debit customer's account.
and
Pre-conditions: Items requisitioned note has full details on item (customer id, item code,
item n a m e , quantity). Customer has budget allocation for requisition.
Main Success S c e n a r i o

1 Stores office receives requisition and finds it complete. Requested itemn available
in store. Issue item.
2. Intimate accounts office to debit customer's account by (item quantity x cost per
item).
Exceptions
1. Quantity requisitioned not available in store. Action ? (Partial issue or no issue)
2. Insufficient credit in customer's account. Action?
3. Item requisitioned not normally stored by the [Link] it add it to its normal
holding?
In Use Case 5 we have limited the scope to only issuing items to customers. We have not
nciuded automatic recorder if the quantity remaining after issue is found below a reorder
eve. Normally stores would intimate purchase to initiate a purchase order in such a
Situation. We will now develop ause case for that situation (Figure 10.3).
Use Case 6:
Stores requests Purchase office to replenish stock in store
Primary actor: Stores Officer (SO).
Scope: Software to
initiate automatic reorder process to purchase items.
Stake holders:
Stores officer, Purchase officer.
 lnformation Systems
144 Analysis and Design of
reaches alevel below aspecified recorder
Goals: When an item in store
amount to be
office is requested to replenish stock. The ordered (1.e., \evel urha
quantity) is intimated by stores
officer or found in the stores
Main Success Scenario
database. optimal
When quantity of itemin stores database Sspecified reorder level,
office with following data (item id, item name, quantity to be request sent to
is stored in log file of requests sent. The actual purchase is
reordered). This
(ordering items from vendors). according to nfor nath,
Use.
Exceptions
1. Arequisition generated is already in the log file of
particularly if the order is for alarge quantity or there is items
along orodered.
date of first requisition? delay ironAcinnthe
The use case given above has only two stake holders and this is
be linked to Use Case 2. The next Use Case we will consider is very simple
goods purchased and taken into stock. In other words, paymentspayment by and is h
which passed inspection. This Use Case corresponds to documentmade onlaccount s ton
are
y for
Figure 10.1 and data flow diagram of Figure 10.4. We will first considerflow diagamitems
the accounts office pays vendor for items which passed inspection and the case
by the stores office. taken into whetstocke
Use Case 7: Accounts department pays vendors
Primary actor: Accounts Officer (AO).
Scope: Software to pay vendors for goods taken into stock.
Stake holders: Stores office, Purchase office, Vendor.
Goals: When items supplied by a vendor taken into
should send pay order (or cheque) to vendor alongstock by stores office, accounts o
reconcile payment. with vendor invoice referencs
Pre-conditions: Item takern into stock note
id, item name, cost per item, quantity takenreceived
in
from stores containing (order no. tem
with data (order no., vendor id, vendor stock, vendor id). Vendor invoice database
name, vendor address, item id, item name
quantity supplied, cost per item, amount payable) accessible
to accounts office.
Main Success Scenario
1. Accounts office receives item
taken into stock intimation from
2. Accounts office calculates stores office.
amount payable and creates pay order with
vendor id, vendor name, vendor address, (order t.
vendor invoice id, quantity accepted, item id, item name, quantity involk
cheque favouring vendor. It mails amount payable). Accounts ofhce prut
address. Alternately, accounts officecheque along with pay order to specihedvendor
bank account along with pay electronically transfers the amount to ve s
3. AO intimates order.
purchase
invoice reference. office on payment by sending order with
copy of Pay
4. Payment data stored in
paid database.
 Use Cose Method 145

Eceptions
Stores,office
intimation
corrupted /not received by A0.
oftice
intimation has quantity accepted not equal to quantity specified as
1 vendor invoice. Action?
supplied in
S t o r e s

a d d r e s s
or bank account details has changed since supply., How does AO
kV
neon
w da
obr o u tt h i s 2

earlier
that there are two possible situations when items are issued to customer.
stated
in Case 5in which the "customer" is a part of an organization and there
We
isas
money ransaction. We will consider another case in which the organization
given

distributorwhobuys items
ini bulk from vendors and distributes it to customers who
r e c e i v e d

usually by cheque. Avariation would be aretail store in which

may pay cash or by credit/debit card. We will not be concerned with this
jýa goods
for
thecustomer
willbe primarily describing the use case corresponding to document flow
CaSe W e

Figure
10.3 and data flow diagram of Figure 10.4.
of
dliagram

Payments

Issue note Accounts Bill

process Customer
Items taken in
stock note

Item price Payment note

Orders
Vendor accounts

Customer accounts Vendor

Figure 10.4 Data flow diagram for accounts process.

lse Case 8: Accounts department sends bill to customer and follows up payment
Primary actor: Accounts Officer (AO).
Scone: Software to generate bill and dispatch to customer with a deadline for payment
and follows up payment.
Stake holders: Stores Office (SO), Accounts Office (AO), Customer.
Gal: When stores office intimates accounts office on item sold to a customer, the accounts
offce generates abill to be sent along with items to be supplied. This bill is sent to stores
ofce to be enclosed with the items. If payment corresponding to the billis not received
rom the customer,after a specified time, areminder is sent. If payment is not received
naspecified time after the reminder is sent the customer's credit rating is downgraded
so that future
supplies are not made without special approval.
Acounts office receives document with the following data (customer id, customer name
and addresS, quantity supplied, cost/item, date) from stores office. Accounts office has
adatabase
with (customer id, amount outstanding on date, credit limit).
 Information Systems
Design of
146 Anolysis and
Main Success Secenario

SO data
(customer id, Customer name and
AOreceives from
1. supplied, cost/item, date).
2. AO creates bill (customer id, name, amount billed date due) using addres , quan
3. AOchecks in its database amount due from customer If (amount
bill to SO for onward
billed) < allowed
credit limit) it sends

rheanst uS iun
database.
amount due
updates its customer
from all customers
Each day AO checks amount received with
4. subtracts amount
received from amount
dues database and outstani
issues receipt to customer forthe amount received. It also lists amnounts

with due dates and sends it

to the customer. outstandTng i

5. Each day AO checks amount due database and issues reminders to

that date. A second al
with dues which becomes outstanding on isreminder custorMe
due date + 20
due date+ 10 days. If dues not received on days, AO
to stop accepting orders from customer. Customer is sent appropriate
determined by the procedures manual of company.
intimates
will be
6. If computer fails due to some reason there no change in
Failure will be logged and any interrupted transaction will be any
state before failure occurred. returned datto [Link]
7. AO finds customer order amount +outstanding due >credit limit. SOi
is
approval if items are to bes
to stop supply. SO has to get supplied in spite ofnoihik,
notification. If approved AO is intimated. AOS
Exceptions
1. Customer address has changed and not updated. Action?
2. Customer's cheque dishonoured by bank. Action?
3. Customer pays amount < amount billed. Action?
4. Customer pays amount> amount billed. Action?
Minimum Guarantees
Customer has paid for items received and if not appropriate
Customer'scredit rating updated based on payment [Link] has been followei
No database other than tha
related to payment has been disturbed.

10.3 USE CASE DIAGRAMS

We have so far used astyle of writing use

has been proposed as a part of Universal cases which is textual. Another graphical sy
In his style so called stick diagram Modeling Language (UML) by Jacobson |2
within an ellipse. For Use Cases is used to represent actors and each use
Observe that the stake holders aredescribed so far, such a diagram is shown case 1s t
in Figure :
In my personal view the shown as actors whose behaviour
stick diagram gives an affects the usetextudl
description of the use case is essential. overview of use cases. Afull
 Use Case Method 147
Use Case 1
Receive

Vendor
items delivered
OKReceiver

Use Case 2

Place order Purchase

officer

Use Case 6

Replenish
store

Use Case 3

Inspect items
OK
Inspection
officer

Use Case 4

Stores Update
To accounts
officer inventory officer

Use Case 5
Issue items
requisitioned

Use Case 7

Customer
OK
Accounts
Pay vendor
To vendor

officer Use Case 8

Bill customer

Figure 10.5 Use case diagram for examples of Sec. 10.1, 10.2.

10.4 USE CASE EXAMPLE-AUTOMATED TELLER MACHINE (ATM)

Ne will now consider an example of Automated Teller Machine (ATM) for which a use
ase model of requirement is given in detail. It is afavourite example of several authors
SAIMis widely used by most of us without appreciating the great amount of attention
nust
the ATM pay
is to specify the requirements to be met by [Link] example is different as
Specialized to meet requirements of rural areas of India.
148 Anolysis and Design of Intormation Systems
In what follows we will first give a summary of requirements of ATM
by bank management and then expand it to include several unstatedas normally
The requirements statement: Our bank wants an ATM machine
which details.
tollowing. It is primarily intended for our rural branches which are far should d.
rugged and easy to operate. It does not require too many sophisticated flung. It
ATMs in metropolitan areas have. The primary features required are: features
1. It must have facility for users to select one of three languages; which
Hindi or English. Acustomer should be able to operate ATM local
languages. using any1angr
2 The ATM card issued by our bank will be the only one accepted
3. Acustomer should be able to withdrawcash up to ?15,000 per [Link] the
The mahine
withdrawal is 100. Acustomer should be p:ovided 7 choices: 100, Tminit
2000, 5000, 10,000 and 15,000.
4. The amount will be dispensed using only 500 and ? 100 notes. If 500,155
the
greater than or equal to 500 at least five 100 rupee notes should be arnount
The rest will be 500 notes.
5. The machine need not accept deposits of customers. dispense,
6. There is only one type of account namely savings account.
7. Customer should be able to get his/her balance printed outin the
her choice. language of
8. It should have security features to dissuade burglers using stolen cards
9. Biometric identification, namely, thumb impression should be used for
a customer. Thus the machine should have an attached thumb
Customers do not have a Personal Identification Number.
identifreader
impression yin
Based on the above requirements specification we should design an ATM. We will &
show the buttons and display of ATM to simpify our discussion. The display is sho
in Figure 10.6. The ATM hardware has the following features to satisfy users
requirements
Security camera
Cash Language
buttons ATM display selection
15,000 Hindi
10,000 Local Lang. Bank's
5000 English computer
2000
1000 Card slot
500
100 Statement
Withdrawcash Balance equiry O printer
Place thumb
-Cash dispenser

Figure 10.6 ATM with buttons and other features.

 Use Case Method 149

show a welcomne message in three language: Hindi, local

will
and ask the customer to press button 1for
display language
the Hindi, 2 for Local language,
Initially
and English a r
press in the respective languages in windows oppositeand
displaying
English by
the
the user with appropriate instructions on the display. The
guides

j for 0t
then in detail as Use Case 9,
specified
reguirement is
putton.

Customer withdraws cash from ATM

Ilse Case 9:
Bank Customer.
C
built in the ATM.
actor:

P r i m a r y
software

The
Bank's Computer System, ATM Security officer, ATM maintenance officer.
holders:

Stake To dispense cash requested in predetermined denominations and print balance

Goal:
statement.

Pre-conditions

The
machine can dispense ? 15,000, 10,000, 5000, 2000, 1000, 500 and 100. Five
1. dispensed will be 100. Rest?500 notes.
notes
Maximum withdrawal per day per customer is 15,000.
2. has a ATM card of the bank.
valid
Customer
4.3 Bank has for each card issued a corresponding thumb print of customer in its
customer database.

5. There is sufficient cash stored in the ATM to cater to at least a day's estimated
withdrawal with sufficient 100 denomination currency notes.
Power OK. Communications line active from ATM to Bank's Computer System.
Main Success Scenario

1 ACUustomer inserts card in slot at the door of ATM cubicle and removes it. The
door opens allowing customer inside provided the card is valid.
2. ATM displays welcome banner and tells customer to select language of choice.
Three languages displayed one opposite each button on the right panel of ATM
(Figure 10.6).
3. Customer presses abutton of his choice.
4. ATM displays a message in the language selected by the customer to insert card
in slot and place thumb in the biometric thumb reader.
5. Customer inserts card in the slot and places thumb on the reader.
6. Bank sends card information and thumb print to the bank's computer system via
communication lines.
1. Computer system checks validity of card and thumb print. If OK, it displays
message to customer (Figure 10.6) to select cash withdrawal or balance enquiry.
o. Customer selects cash withdrawal, by pressing the button on the left of the
display.
stomer presses appropriate button on the left of the display based on the
amount needed (Figure 10.6).
10. ATM ejects
customer's card, flashes message requesting customer to take the card
ShePs. The customer is expected to take the card within one minute. If he/
Sne does not take the card it is an exception
condition.
 Systems
Design of lnformotion
150 Analysis ond
in the customep''s
requested < minimum balance account
customer is less than
I1. If amount
dispenses the day
forspecified
money in
cash withdrawal
by the 15,000 and the
denominations. It beeps and instructsththe
en
totake money by flashing message on ATM display. Customer is expected the
condition
a minute. If not it is an exception
12. the
After thewithin
cash customer takes the cash ATM sends message to the cOmputer to
the customer
and flashes message to to
his/her account, beeps
IS
transaction with printed
updated slip by ATM
dispensed
machine. The customer's
withdrawal colect
amount and his current balance is [Link] A
the t
ready to take another
13. The ATM reverts to
30 seconds.
initial state and is
transacton at
Exceptions cubicle.
Power failure, customer cannot enter ATM
1. available"
ATM displays "ATM not Bank's
2. Communication failure, s
system should check
communication lines, by sending message once a compu
minute
case of failure the Bank's Computer
see if it is received back. In
inform ATM maintenance officer.
System shoaant
do not match. Instruct customer to
3. Card information andthumb print
again. If second time also there is failure one possible action is not toplaceeject hutcat
Another action may be to eject card
and ask customer to report to Bank. the customer to insert card and
one more attempt by aflashing message to
thumb and reader, and place thumb on reader. lf it fails again do not returm again, wigivge
and ask customer to report to bank (Exception action to be clarified by ATM
Security officer. ATM may have a video camera to take a picture of customer)
4. Communication line fails during success scenario 6. Eject card. Display ATM
failed. Ask customer to try again after 10 minutes. Inform ATM maintenance esta.
5. Power fails during success scenario 6. Ask customer to report to bank (Bank ha
to decide exception action).
6. Power or communication fails during success scenarios 7, 8or 9. Do not dispense
Maintenance.
cash. No change in balance. Inform ATM
7. Ifcustomer's balance is less than the amount requested flash message "insuffitie
balance". Eject card. Print balance statement.
8. If customer's withdrawal during the day including current request greater than
15,000 flash message "Exceed maximum, withdrawal for the day". Eiect cand
9. ATM does not have sufficient balance to dispense money requested. Flash messap:
ATM has no cash. Abort transaction. Banking system should inform ATM
maintenance staff. Print balance statement slip.
10. ATM does not have enough paper to print balance or printer is defective ([Link]
ribbon or printer jammed). Flash message printer defective. Bank's computer systerm
should inform ATM maintenance staff.
11. Customer, after taking cash, reinserts card within 30 seconds. ATM does not
accept card and displays "wait for 30 seconds" and beeps.
12. Customer does not take card within one minute after it is ejected in spitechange
ofui
not
message to take card and warning beeps. Do not dispense cash. Dotakecard I
balance in account. Flash message and beep requesting customer to
he still does not, abort transaction and report to ATM security officer.
 Use Case Method 151

not take cash within one minute. Flash message and

does

Customer to take cash within one minute. If he/she does not, infor
Customer beepsecurity
ATM asking
13.
o f f i c e r .

M i n i m u m G u a r a n t e e

credit card and his or her thumb print matches the one in the
valid
customer has
greater than the cash requested and if he
data
credit is or she has not drawn more
that date money would have been dispensed. If an
Ifa his
and

on attempt at fraud had

A T M seecurity would have been informed. In case of any malfunction of
base 15,000

power lines, the ATM maintenance staff would have been

t h a n
detected
communication/

to all other clients of ATM Would not be affected. Customer's

b e e n

or belongingData
ATM

h a v e been debited by the amount dispensed

intimated.
account w o u l d
and a correct balance
have been printed.
would

Observe the large number of exception situations which may arise. All these are not
statement

original statement of requirements. Use case methodology has forced the

in the to think deeper and raised queries to
systems analyst
s p e c i f i e d

be answered by the management

designingthe
system.
before
used in this section we wrote one use case with a large number of
In
exceptions. the style Use cases may be written for actions to be taken by the appropriate stake
for selected exceptions. One such exception is when an ATM needs attention by
holder
maintenance
staff. Use case 10 describes this.
10: ATM maintenance staff attends to fault
Use Case
Primary actor:
ATM' maintenance staff.
faults.
Procedure to fix
Scope:
Stake holders: Customer, ATM maintenance staff, ATM security staff, Banking Computer
System.
Cogl: To attend to fault in ATM operation and fix it.
Pre-conditions

1. Power monitor beeps indicating failure.

2. Signal from Banking Computer to ATM not acknowledged.
3. ATM printer sends failed signal.
4. ATM cash dispenser sends failed signal.
5. ATM card reader sends failed signal.
6. ATM thumb print reader sends failed signal.
Main Success Scenario

l. Whenever failure occurs appropriate information received by maintenance staff.

2. Based on the information ATM machine is repaired.
Exceptions
l. Sufficient cash not available to replenish. Action?
2.
3
Spare parts not available to fix printer. Action?
Spare parts for card reader, thumb print reader not available. Action?
 Systems
nformation
Design of
Analysis and
152
If sufficient cash and spare parts available ATM is repaired within sipulated time
M i n i m u mG u a r a n t e e s

security staff
for ATM
and ATM
Similar

enquiry.
These
use
Use case 9 was
left as
are Most
cases may
exefor
rciscash
be written
the
student.
e s to withdrawal. Aseparate use case may be witten tor
of it will be found in use case 9 and we mav think of this USe case
bankingSyte
bala.
as bei

included in it.

DIAGRAMS
FOR ATM
STICK
10.5
In addition tothe detailed written use cases, stick diagrams are useful tO get an overien
of the use cases. We givein Figure 10.7the overview of use case withdraw cash as asic
diagram. In Figure 10.8, 10.9 and 10.10 we give use cases for the other stake holders

Bank's Computer system

Withdraw Bank's maintenance engineer

cash from ATM

Customer Bank's security officer

diagram of ATM use case.

Figure 10.7 Context

Restore power

Refillcash

Repair printer

OK Check
ATM
maintainance Communication
engineer <<includes>> Replace ribbon
Repair
card reader
s<includes> Replace paper
Repair thumb
print reader

Figure 10.8 Use case diagram for ATM maintenance engineer.

 Use Case Method 153

Authenticate
Customer

Check balance
and total withdrawn

Bank's Dispense cash

Computer

system
Print balance
statement

Reconcile accounts
periodically

Figure 10.9 Use case diagram of Bank's Computer System.

Log unusual
incidents

ATM security Prevent break-in

officer atempt

Figure 10.10 Use case diagram for ATM Security Officer.

In 1se case diagram two more conventions are used. One of them is called includes
and the otheris called extends. In the ATM example, balance statement printing was part
a se case withdraw cash. If aseparate balance enquiry is to be shown in the use
e diagram, it can be modified as in Figure 10.11, where balance enquiry is shown as
included in withdraw cash. In the ATM example we assumed that only the card of the
bank owning the ATM is permitted to be used. If we want to allow cards of other
(ooperating banks, then we can use an extension as shown in Figure 10.11. Use case
description for this case has to be separately written.

Withdraw cash Bank's computer

from ATM system
<<includes>>

<<Extends>>/ Balance enquiry

ATM card of
another bank
Computer system
of other bank

Figure 10.11 Includes and Extends of use case.

 Systems
Information

Design of
Analysis and
154
CASES
WITH USE is the
TESTING requirements
generation of
10.6
use case
analysis of
of
generating test cases is to test cas
aspect of thedeveloped. The
{he take
andmethod each one of
important
scenario
da
system is
An
whenthe
final
invoke each
will
ofthe
cases in the
success

excepün
which
conditions. 1
illustrate this
for use case
We
Test Cases with order
id, as the primary index.
data base
record
following data
where Ris the
1. Retrieve from delivery notes with exhaustive
data. If
rignt value
test needed
of6test specific
Create a set of the
2. wrong value
and W the
cases may
be created. item id qty.
2 = 32 test Vendor id date
Order id R R
R
W R R
tc1: R
W R
tc2 :
R W R
R W
tc3: R
R R
R R W
tc4 : R
R R R R
tc5 : R
tc6 : R 6is used. In all
case
updated when test
is other
received database printed.
3. Check if item error message
should be
cases, an
appropriate
delivery note
dispatched to inspection office.
success scenario whether
4. Check in

10.7 CONCLUSIONS

information systems is a well sttd

most difficult problems in designing du:
One of the
be met by the proposed system. This is primarily
specifications of the requirements to clients who state their requirements and svstem
between
to the communication gap design the system. During the
past 50 years several
analysts who interpret them and have been proposed
specifying requiremnents to bridge the communication gap
methods of many organizations
Use case method is one of those which is currently being adopted by
case methodology are:
The primnary advantages of use set of
up a verbose, fuzzy description of system requirements into a
1. It breaks
smaller clearly specified cases.
identifies primary actors, and stake holders who together cooperate and cary
2. It
out tasks to meet the goals of each of the cases.
the assumptions made w
3. The method requires the analyst to clearly state a case. In many projectsthe
developing the software to meet the requirements of Clear statement
clients do not know what assumptions are made by a developer.
of assumptions will reduce (if not eliminate) misunderstanding later.
4. The most importantaspect of the use case methodology is the detaileathere is no
where
of exceptions. These exception conditions focus on situations
 Use Case Method 155
clarityin the client's statement of requirements. If actions to be carried out for each
exceptions are clarified by clients before
these
beginning the design, changes
of systerm design later can be avoided.
the
Specitication of behavior in success scenario as well
as the listing of exceptions
aidin designing test cases which are to be used to test the software developed for
5
The creation of test data is systematized when use case analysis is
s y s t e m .

the
employed

disadvantages of use case

methodology are:
The
primary
description coould become very long, particularly for
Use
case

One mustthus modularize and break up a system appropriately. complex systems.

1.
provide a behavioural description. The stick diagrams used in UML is too
Usecases
Concise
and does not provide much information.
How
documents and data flow in a system are not part of the specifications.
3
advantages are numerOus as we have seen and this has led to the use case
beingadopted widely by industry.
thoae several styles available to describe use cases. This style we have adopted
n e t h o d o l o g y

ofthe following parts:

consists

J s c9se title-specifies action performed by use case to meet a specified goal.

Drinarv actor -initiates the acthon performed by ause case.
the boundaries of the subsystem being described by the use case.
Scopespecifies
3.4 Stakeholders arethe other actors who cooperate with the primary actor to meet the
case.
goals of the use
: Coslspecifies the primary objective or guarantee of delivery promised by the use
case,

6 Pre-conditions are the assumptions made by the primary actor while designing the
system to meet the specified goal(s).
7Main success scenario lists the behaviour of the use case when everything goes
according to plan.
8. Minimum guarantees specifies what holds true after the use case is completed. It
Specifies whether allstake holders interests have been protected.
9. Exceptions list what could go wrong during a use case and what actions are
needed in such cases. Usually these contain situations which have not been
foreseen by the client and a system designer requires clarifications.
naddition to this a stick diagram would be useful to get abird's eye view of a system.

SUMMARY

h use case specifies a goal to be met by a system being developed.

2 A
System requirement specification consists of a set of use cases.
* tach use case has aprimary actor whose responsibility is to meet the specified
80al by appropriate actions.
156 Anolysis ond Design of Inormation Systems
4. Ause case is a behavioural description of the primary
who cooperate to meet the specified goal. actor and
ihe
5, There are several formats suggested in the literature to
we have used in our description has the following describe stake d
" Use case title which specifies the action to be
main parts:Use cases.
" A primary actor who initiates actions to meet theperformed. The
Scope specifies the software system being developed. specified
Stake holders are other actors who cooperate with goal(s).
the
out the specified actions.
Astatement of goal to be met.
primary
actor
Aset of pre-conditions which are assumed to be true by
In other words, these are assumptions made by the software
thedeveloper. deveoger
" A set of guarantees specifying what holds after a use case
Exceptions list situations when thingS can go wrong and is completed.
need to be clarified by the requirements specified. appropriate eacions
6. Stick diagrams showing the actors and use cases they are
only a bird's eye view of use cases. A detailed involved in.
essential. documentation of use They gve
7. Use cases are effective to develop test cases.
cases is

EXERCISES

10.1 What is use case? What are its advantages and

requirement specifications. disadvantages in evolving
10.2 Does use case analysisconcern itself with data and document flow? In
is it different from data and document flow methods what
used in a systemsway
requirement specifications.
10.3 Give a template to specify use case description given in
this chapter.
10.4 Consider Exercise 5.3. Give use case description for that exercise.
10.5 Consider the hostel information system case example of
actors in this case.
Section 4.7. Identify the
10.6 Develop use case corresponding to mess billing described in Section 4.7.
10.7 Develop use case corresponding to store issue of reorder example described in
Section 4.7.
10.8 Develop use case corresponding to the purchase of items for the hostel mes
described in Section 4.7.
10.9 In the ATM example considered in this chapter we assumed that a custoe
identity is established using his or her thumb print. Most ATMs require a cus
to use a 4-digit PIN code. Modify use case 9 given in this chapter when PIN code
is used. If a wrong PIN is used more than thrice the ATM should not returnthe
ATM card and inform security.
 U nn Method 157
Modify Use case 9to allow a customer to use ATMs of a group of c0operating

banks.
Develop a use case where ATM security officer is the primary actor
10.10)
Figure

(See a use case

where the Banking System is the prinary
1012Develop
(SeeFigure 10.9),
actor

D e v e l o p
a
stick diagram Corresponding to Exercise 10.6.
Develop
a
stick
diagram corresponding to Exercise 10.7.
1 0 1 4

a
stick diagram corresponding to Exercise 10.8.
Develop

1015 test cases for the mess billing system of Section 4.7 using the use case
Develop

D Exercise 10.6.
of
1 0 1 6

test
cases for Exercise 10.7.
Develop

1017 test cases for Exercise 10.8.

Develop

0.18