19/03/2015

Tut 4 Q 8(a): Develop a level-0

The Traditional Approach
DFD fragment
to Requirements

A bank customer who uses the ATM enters
Online Chapter B his/her card and PIN. The ATM system then
verifies the PIN and gives the customer a PIN
Introduction to Systems status response.
Analysis and Design:
HINT: we are modelling data flows not physical flows, so
An Agile, Iteractive Approach card info (e.g. card ID) will flow into the system, not the
6th Ed card.

NOTE: Since we specify that we are using a card and a
Satzinger, Jackson & Burd PIN, this implies that this is a physical model (i.e. one
developed during design). A logical model would talk
(Chapter 6, pp. 202-221; 230-235 of about a the ATM verifying the customer’s identity –
previous edition of textbook) which could be done in several ways (leaving the
46
decision to the designer).

One DFD fragment implies

one use case/process Steps for drawing level-0 DFDs
Suggested solution If Entered PIN =
Stored PIN then PIN
Identify the processes (use cases)
status = OK else
PIN status = not OK
For each process:

Which external entity gives each process data?
Which external entity receives data from the
process? Draw the external entity/entities

Draw the inputs and outputs of the process
to/from the external entity/entities
Can’t read “Verified PIN”
What data is read & used by the process? What
The process is where Comment: the from datastore, since the data is stored as a result of the process having
the programming process is the process of verifying
eventually occurs occurs in process, and is worked? Draw the data store(s) and the data
ONLY place where
processing or not an input to the process flow(s)
comparisons or 47
Check each process for errors (miracles, black 48
calculations occur
holes and grey holes) F (more F)

Error 1: Black hole Error 2: Miracle

Black holes can also Miracles can
apply to data stores: also apply to
data is stored but data stores:
never data is read but
read/accessed never stored

Incorrect Incorrect
Correct Correct

Each process should have an output
Each process should have an input
49 50

1
 19/03/2015

Error 3: Grey hole (or Error 4: Data flows from a data store to
“Incomplete inputs”) an External entity (& vice versa)
Have to think
a little for this
one ...

Incorrect
Correct

Incorrect Correct

Each process should have enough inputs to be able
to achieve the desired outputs
Each data store should be linked to an

NB: Processes don’t “magically know” information – External entity via a process (& vice versa)
51
the data has to be given to the process 52

Error 5: Data flows from one data Error 6: Data flows from one
store to another data store external entity to another
Correct Incorrect

Correct

Incorrect

Each data store should be linked to another
External entities communicate via a process
53
data store through a process 54

Error 7: Data flows have two-way Error 8: Data flow arrows are labelled
arrows with a verb
Sounds like you’re
telling someone
Correct what to do/sounds
like a use case
name

Be specific Sounds like a

about process name
what’s
flowing
Sounds like an Correct
action/activity
Incorrect Incorrect

Each data flow arrow should move in one
Data flow arrows should be labelled with a
55
direction only 56 noun or noun phrase

2
 19/03/2015

Tut 4 Q 8(b): Develop a level-0 DFD

A bank customer who uses the ATM can either withdraw money or buy airtime


for a mobile phone. (Comment: this ATM has very limited functionality!) Suggested solution
Assume that the customer’s PIN has been verified, and that this is not part of the
1.0
diagram. A customer could access more than one account via the ATM (e.g. Account info & amount Old balance
savings, debit). Updated balance
Withdraw New balance
money

When withdrawing money, the customer inputs the account information and the
Msg: Insufficient funds
amount to withdraw. The system responds by giving a receipt with the updated Customer
account balance (and the money). If there are insufficient funds for the
Service
transaction, the customer receives a slip which gives the message that there are D2 provider D1
Account
details
insufficient funds. cellphone list

Service provider New balance

When buying airtime, the customer inputs the account information, the amount
Account info, amount &
of airtime and the cellphone number to be credited. The system works out which cellphone number
2.0
cell phone provider the cell phone number uses by reading this information from Old balance
Updated balance
the service provider cellphone list. The system then responds by sending the Cellphone
Credit note with amount
cellphone service provider a credit note for the airtime purchased, together with Msg: Insufficient funds Buy airtime
& cellphone number
service
the cellphone number to be credited. The payment is stored by the system. The provider
customer receives a slip with the new account balance. If there are insufficient
funds for the transaction, the customer receives a slip which gives the message 57
Amount paid D3 Payment
58

that there are insufficient funds.