Lecture 5

Data flow diagrams and

process specifications
11486 Systems Analysis and Modelling
6677 Systems Analysis and Modelling G
Dr Luke Nguyen-Hoan
This session will be recorded
Contents
Administration
1. Data flow diagrams
2. Syntax and semantics
3. Constructing DFDs and levels of DFDs
4. Guidelines
5. Process specifications
Textbook chapters:
Systems Analysis and Design
Chapter 7 Using Data Flow Diagrams
Chapter 9 Process Specifications and Structured Decisions

All images under the Creative Commons Attribution licence or in the public domain unless otherwise stated
 Administration

Computer problems
Image by Randall Munroe
https://xkcd.com/722/
Tutorials
Don’t forget that tutorials are assessed (1% each, best 10 or 11)
Assessment – Assignment 1 - Individual
This is due at the end of this week!

See the instructions on Canvas for full information

Assessment – Assignment 2 - Group
This is due at the end of week 9
If you haven’t already, start looking for people to work with

See the instructions on Canvas for full information, including the group formation
information
Groups should be set by the start of week 7 using self-signup on Canvas
Groups for the group assignments
Choosing a group for the assignment (before Monday Week 7 – next week)
To sign up for a group on Canvas, follow the instructions here:
https://community.canvaslms.com/docs/DOC-10516
Self sign up for groups will be closed on the day listed above. If you have any issues
with sign up or your group composition, please contact the unit convener as soon as
possible. The longer you delay, the less that can be done to resolve any issues!
Groups for the group assignments
Groups for this assignment are limited to a maximum of 4 students per group, with no
exceptions. Please note that this assignment is intended for groups of 3-4 students, so
students in groups smaller than 4 students should expect that more effort and time is
required to accomplish equivalent grades. No consideration will be given for groups
comprising less than 3 students.
Undergraduate students (11486) should form a group with other undergraduate
students only, in the “11486 Undergraduate Groups” set.
Graduate students (6677) should form a group with other graduate students only, in
the “6677 Graduate Groups” set.
Make sure your group is in the correct group set, or your marks won’t be allocated
properly (and you might be penalised marks when I have to fix it as per the late group
change penalty).
Groups for the group assignments
Note that there is no requirement for all group members to be in the same tutorial–
you may form a group with friends from other tutorials if you wish. However, it may
be easier for you to coordinate and work together if you form a group with other
people in your tutorial.
It is each student’s responsibility to organise their group – the tutors and unit
conveners will not assist you in finding or joining a group. You may wish to use the
Canvas Discussion forums to help find a group.
If there are no empty groups remaining for the case study that your group has
chosen, email the unit convener and additional groups will be added.
Groups for the group assignments
Groups finalised for the assignment – Monday Week 8
This is just under two weeks prior to the assignment due date, and thus by this point
everyone should now be in groups and have organised to complete the assignment
with their peers.
Any students not in a group by this date will be assumed to be completing the
assignment individually, and will thus be placed into a group of 1 student only.
Groups for the group assignments
Groups finalised for the assignment – Monday Week 8
Any changes requested after this date will result in a mark penalty of 10% of the
available marks for the students involved
This deadline is imposed as changes to group allocations after assignments have
started to be submitted can cause issues with Canvas submissions and grading, so
groups need to be finalised in advance of any assignments being submitted.
This mark penalty will apply for only the students whose group allocations are
changed – for example, if one student changes from one group to another, only that
student will receive the mark penalty. Other students in both groups whose group
allocates are not changed will not be penalised.
The mark penalty may also apply if your group is in the wrong group set (11486
Undergraduate Groups or 6677 Graduate Groups) and I have to fix it later!
Questions?
Any questions about the unit before we get into this week’s topic?
Assessment
Tutorials
Anything else?
I know this is tiny
– there’s a bigger
version on the
Canvas site
I know this is tiny
– there’s a bigger
version on the
Canvas site
1. Data flow
diagram (DFDs)
overview
a) Big picture
b) Purpose
c) Compared to context diagrams
Big Picture

Diagram from Systems

Analysis and Design in a
Changing World, J. Satzinger,
R. Jackson, S. Burd.
Used with permission.
Purpose
Data flow diagrams provide a
graphical representation of how
data moves through a system, and
what processes transform/act on
that data within the system
Good when information transfer
and data transformation are key
parts of the system
Compared to context diagrams
 Remember this? Transaction
request
Existing
customer New customer
Transaction New customer
Bank teller
New customer result information
Account 1. Customer
information New customer
Process information
information transaction
3.
Available Create new
Customer information account
New customer information account types
Updated account information
Transaction Customer
information Account
Bank account information
management
Transaction history Account information
system
Updated account information
Withdrawal amount Recent transactions
Account
Deposit amount
Interest rate information

Interest rate Existing 2.

Account information customer Generate
Existing statement
Money customer
Bank manager Transaction message
Account message Statement
Account statement
Compared to context diagrams
A data flow diagram breaks up the system into multiple processes, and describes the
data flows between them
Example DFD
2. Syntax and
semantics
a) Syntax (notation)
b) Processes
c) External entities
d) Data flows
e) Data stores
Syntax (notation)
Transaction
result
Data flow (surprise!) Yourdon and Coad Symbols

These go between the other elements

1.
Process
transaction Process

Data store Customer information

Existing
customer External entity
Syntax (notation)
Transaction
result
Data flow (surprise!) Yourdon and Coad Symbols

These go between the other elements

1 1.
Process
transaction Process
Process
transaction

Data store Customer information

Alternative notation
(Gane and Sarson Symbols)
Customer information Existing
customer External entity
Existing
customer
 Syntax (notation)
Transaction
result
Data flow (surprise!) Yourdon and Coad Symbols

These go between the other elements

1 1.
Process
transaction Process
Process
transaction

Data store Customer information

Alternative notation
(Gane and Sarson Symbols)
Customer information Existing
customer External entity
I recommend using the Yourdon and Coad symbols Existing
customer
1. They’re easier to draw
2. The Gane and Sarson process symbol is easily confused
with symbols in UML state machine diagrams later on
Processes
1.
Process
transaction Process

Processes are activities that the

system does – they transform input
data to output data
Wait, we’ve heard this before…
Processes
1.
Process
transaction Process

Processes are activities that the

system does – they transform input
data to output data
Wait, we’ve heard this before…
Event name Event type Source Condition Trigger Activity/Action Response Destination

Withdraw External Customer Account balance Withdraw Reduce Account Balance by Money equivalent Customer
>= $amount $amount $amount to $amount
Withdraw External Customer Account balance Withdraw No change in account balance Withdrawal Customer
< $amount $amount refused message

Overdrawn State n/a n/a Account Lock account for all withdrawals Account Customer
balance < 0 overdrawn
message
Monthly Temporal n/a n/a End of the Get list of all transactions in the Statement for last Customer
Statement month past month month
Format statement
External entities
Just like in context diagrams,
external entities in a data flow
diagram are anything outside of the
system that the system interacts
with
Examples: customers, users,
managers, other systems

Existing
customer External entity

Waiting in line at a food store

Image by David Shankbone
Data flows
Transaction
result
Data flow (surprise!)

Just like in a context diagram, data

flow diagrams (as the name
implies) also show data flows
For a data flow diagram, the
internal flows are also described
between processes within the
system
Data stores
Data flow diagrams introduce the
Data store Customer information
concept of data stores, where data
can be kept for later use
These might later be implemented
as databases, but not necessarily –
remember, at analysis level, we
don’t worry about the specific
design or implementation details
Hence why we call them data stores

Interior of REMA 1000 supermarket/grocery store in Tønsberg, Norway. Cashier at checkout.

Image by user:Wolfmann
3. Constructing
DFDs and levels
of DFDs
a) Bottom-up approach
b) Top-down approach
c) DFD levels and numbering
Bottom-up approach
Start with a process for every single
event

Nanjing Treasure Boat – bottom

Image by user:Vmenov
Bottom-up approach
Event name Event type Source Condition Trigger Activity/Action Response Destination

Withdraw External Customer Account balance Withdraw Reduce Account Balance by Money equivalent Customer
>= $amount $amount $amount to $amount
Withdraw External Customer Account balance Withdraw No change in account balance Withdrawal Customer
< $amount $amount refused message

Overdrawn State n/a n/a Account Lock account for all withdrawals Account Customer
balance < 0 overdrawn
message
Monthly Temporal n/a n/a End of the Get list of all transactions in the Statement for last Customer
Statement month past month month
Format statement

We can translate an event-action-response set into a process:

Transactions
Transaction data
1. 2.
Withdraw Withdrawal request Generate
money monthly
statement
Existing Statement
Money customer
Bottom-up approach
Event name Event type Source Condition Trigger Activity/Action Response Destination

Withdraw External Customer Account balance Withdraw Reduce Account Balance by Money equivalent Customer
>= $amount $amount $amount to $amount
Withdraw External Customer Account balance Withdraw No change in account balance Withdrawal Customer
< $amount $amount refused message

Overdrawn State n/a n/a Account Lock account for all withdrawals Account Customer
balance < 0 overdrawn
message
Monthly Temporal n/a n/a End of the Get list of all transactions in the Statement for last Customer
Statement month past month month
Format statement

We can translate an event-action-response set into a process:

Transactions
Transaction data
1. 2.
Withdraw Withdrawal request Generate
money monthly
statement
Existing Statement
Money customer
Bottom-up approach
Event name Event type Source Condition Trigger Activity/Action Response Destination

Withdraw External Customer Account balance Withdraw Reduce Account Balance by Money equivalent Customer
>= $amount $amount $amount to $amount
Withdraw External Customer Account balance Withdraw No change in account balance Withdrawal Customer
< $amount $amount refused message

Overdrawn State n/a n/a Account Lock account for all withdrawals Account Customer
balance < 0 overdrawn
message
Monthly Temporal n/a n/a End of the Get list of all transactions in the Statement for last Customer
Statement month past month month
Format statement

We can translate an event-action-response set into a process:

Transactions
Transaction data
1. 2.
Withdraw Withdrawal request Generate
money monthly
statement
Existing Statement
Money customer
Bottom-up approach
Start with a process for every single
event
Do this for every event, and you
end up with a (huge) data flow
diagram

Transactions
Transaction data
1. 2.
Withdraw Withdrawal request Generate
money monthly
statement
Existing Statement
Money customer
Top-down approach Bank teller
New customer

The alternative approach, the top- Account

down approach, starts with the information New customer
information
context diagram
Available
New customer information account types
Updated account information

Bank account
management
system Updated account information
Withdrawal amount
Deposit amount
Interest rate
Interest rate
Account information Existing
Money customer
Bank manager Transaction message
Account message
Account statement
 New customer

Top-down approach New customer

information

The alternative approach, the top- 3.

Create new
down approach, starts with the account

context diagram 1.
Update
account
Break down the system into all the
different ‘things’ it should do Updated account 4.
Perform
information transaction

(Bank teller has disappeared for a

Transaction
reason, and we’ll get to this later) 2.
response Transaction
Manage
interest rates request
Interest rate 5.
Generate Existing
statement customer
Interest rate
Account statement
Bank manager
 Customer information New customer

Top-down approach
New customer
information New customer
Transactions information

Customer Recent
Transaction
The alternative approach, the top- information transactions
record
3.
Create new
down approach, starts with the account

context diagram Account

1.
Update
account
Break down the system into all the information

different ‘things’ it should do Account information

Updated account 4.
Perform
information
Then add additional data flows and Interest rate
transaction

data stores as needed

Transaction
2.
Manage
response Transaction
interest rates request
Interest rate 5.
Generate Existing
statement customer
Interest rate
Account statement
Bank manager
DFD levels and numbering
The bottom-up approach tends to The top-down approach Transactions
result in lots of ‘small’, detailed tends to result in a few
processes Transaction
‘bigger’, more record
encompassing processes
(although this depends 4.
1.
Withdraw
on how you decompose) Perform
Withdrawal request transaction
money

Existing
customer Transaction
Money
response Transaction
request
These are related through levels of DFDs
Existing
Processes can be decomposed into smaller sub-processes, or customer

combined into larger super processes

DFD levels and numbering
Transactions
Processes in the top level or
Transactions
Withdrawal Deposit Level 1 DFD are numbered
record
record with integers (1, 2, 3…) Transaction
record
Sub-processes of each top
4.2 level process in the Level 2 4.
4.1
Withdraw Withdrawal
Deposit
money DFD are numbered using Perform
money request subsequent decimal points transaction

Deposit
(1.1, 1.2, 1.3…)
Transaction
request
The actual numbers don’t response Transaction
matter (they’re not in any request
Money Deposit
Existing
customer confirmation particular order), they just Existing
uniquely identify processes customer
DFD levels and numbering Transactions

Transactions Withdrawal
The numbering Account information
record
Withdrawal
record
scheme continues
Account balance
for lower level DFDs 4.1.3
Record
withdrawal
Withdrawal
4.1 4.1.1 result 4.1.2
Withdraw Withdrawal Check
Process
money account Withdrawal approval
request withdrawal
balance

Money
Money Existing
customer Withdrawal
request
Existing
customer
DFD levels and numbering Transactions

Transactions Note that a lower Withdrawal

level DFD should be record
Account information
Withdrawal equivalent to the
record higher level process Account balance
4.1.3
Record
withdrawal
Withdrawal
4.1 4.1.1 result 4.1.2
Withdraw Withdrawal Check
Process
money account Withdrawal approval
request withdrawal
balance

Money
Money Existing
customer Withdrawal
request
Existing
customer
DFD levels and numbering Uh oh!
Transactions

Transactions Note that a lower Withdrawal

level DFD should be record
Account information
Withdrawal equivalent to the
record higher level process Account balance
4.1.3
Record
withdrawal
Withdrawal
4.1 4.1.1 result 4.1.2
Withdraw Withdrawal Check
Process
money account Withdrawal approval
request withdrawal
balance

Money
Money Existing
customer Withdrawal
request
Existing
customer
DFD levels and numbering Transactions

Transactions Note that a lower Withdrawal

level DFD should be record
Account information
Withdrawal equivalent to the
record Account information
higher level process Account balance
4.1.3
Account balance Record
withdrawal
Withdrawal
4.1 4.1.1 result 4.1.2
Withdraw Withdrawal Check
Process
money account Withdrawal approval
request withdrawal
balance

Money
Money Existing
customer Withdrawal
request
Existing
This is referred to as ‘balancing’ customer
DFD levels and numbering
Transactions

Deposit Transactions
Withdrawal
record record
Transaction
record

To make sure data flows

4.1
4.2
Deposit
balance between levels, the 4.
Withdraw Withdrawal money data dictionary can define Perform
transaction
money request composite data flows
Deposit
request Transaction
response Transaction
request
Money Existing
Deposit
customer confirmation Existing
customer
DFD levels and numbering
Transactions Transaction record = [Withdrawal record|Deposit record]

Deposit Transactions
Withdrawal
record record
Transaction
record

To make sure data flows

4.1
4.2
Deposit
balance between levels, the 4.
Withdraw Withdrawal money data dictionary can define Perform
transaction
money request composite data flows
Deposit
request
Transaction
Transaction request = response Transaction
[Withdrawal request|Deposit request] request
Money Existing
Deposit
customer confirmation Existing
Transaction response = customer
[Money|Deposit confirmation]
4. Guidelines
a) Sizing
b) Naming
c) DFD rules
d) Consolidating entities
Sizing
Don’t draw too many processes in a
DFD
Too many processes may indicate that
you are analysing from too low a level of
abstraction, or that your system as a
whole is just really big and complex
(which may or may not be a different
problem…)
How many is too many? 7+ is
probably too many, but it depends
on the system!
Sizing
Don’t draw too many data flows
into a process
This indicates the data may not be well
defined
Alternatively, the process may be doing
too much and should be decomposed
into smaller processes
A guideline is to try not to have
more than one or two dataflows
between a particular source and
destination pair
Naming
Processes should be named as an
action, using the language of the
problem or business domain
“Generate monthly statement”
“Check account balance”
Can be more general for higher-
level processes, more specific for
lower-level processes
Often verb + noun
Naming
As with context diagram data flows,
data flows should be named
descriptively to the data being
transferred
Further defined in the data
dictionary
Naming
Data stores should similarly be
descriptively named to represent
the data that they contain
Data stores should also be defined
in the data dictionary
 DFD rules
Withdrawal
Transactions
record
All processes must have at least

?
one input data flow and one output
Existing
customer
4.1
Withdraw
data flow
money
A process can’t create data out of
Withdrawal nothing
result Where does the data for the withdrawal
record and withdrawal result come from?
A process must produce an output

?
Customer
information
2.
Customer information Generate
statement What is the output of the Generate
statement process?
 DFD rules
Withdrawal
Transactions
record
Similar to events, all input data
Withdrawal must be used by the process
Existing request 4.1
customer Withdraw
money
All output data must be generated,
based on the inputs to the process
Withdrawal 4.2
New Create
result customer customer
What does “Withdraw information
money” use “New customer New New customer
information” for? customer
information

Customer
information

?
2. Existing
Customer information Generate customer
statement Statement

Where does the transaction data

for the statement come from?
DFD rules
Transactions
Don’t show possible outcomes as
Withdrawal split data flows
record
Data flows can’t split – use the data
dictionary instead to define options
4.1
Withdraw Withdrawal
money request

Money
Existing
customer
Not approved message
DFD rules
Transactions
Don’t show possible outcomes as
Withdrawal split data flows
record
Data flows can’t split – use the data
dictionary instead to define options
4.1
Withdraw Withdrawal
money request

Withdrawal result = [Money|Not approved message]

Withdrawal Existing
customer
result
DFD rules
Data flow diagrams are not used to
show processing options or
alternatives
This is handled in process
4.1.1
Withdrawal
allowed
specifications
4.1.2
Check
Process
account
withdrawal
balance

Withdrawal denied

4.1.3
Notify
customer
DFD rules
Data flow diagrams are not used to
show processing options or
alternatives
This is handled in the data
dictionary and process
Withdrawal specifications
4.1.1 result 4.1.2 Withdrawal result = [“Rejected”|“Approved” + Withdrawal request + Account Balance]
Check
Process
account
withdrawal
balance 4.1.2 Process withdrawal

If Withdrawal approval is approved, then…

(We’ll get to process specifications in the next part of this lecture!)
DFD rules
Data flows are between: Data flows are not between:
Withdrawal New account
4.1.1 result Existing information
4.1.2 Bank Teller
Check customer
Process
account
withdrawal
balance
Updated account
information
Account information Customer information
Withdrawal
request 4.1
Existing
Withdraw
customer Updated account
money
Existing information
customer
Account information

Withdrawal
4.1 record The other way around (data store
Withdraw Transactions to external entity) is equally wrong
money
The other way around (process to external entity,
or data store to process) is acceptable as well
 Why did bank tellers disappear? Customer information
New customer
New
customer
information New customer
Bank teller New Transactions information
New customer
Customer Recent
Account customer transactions Transaction 3.
information information record Create new
information
account
New customer
1.
information Available Account Update
Updated account account information account
information types
Bank
Account information 4.
account Updated account Perform
manage- information
Updated account information Interest rate transaction
ment
system Withdrawal amount
Deposit amount 2.
Interest Transaction
Manage response
rate Interest interest
rate Account information Existing rates
Interest rate 5.
Bank Money customer Existing
Generate
manager Transaction message statement customer
Interest rate
Account message
Account statement Bank Account statement
manager
 Why did bank tellers disappear?
Bank teller New Bank tellers don’t seem to do
New customer
anything other than pass on
Account
information
customer
information
information
New customer
information Available If bank tellers are included in the
Updated account
information
account data flow diagram, many processes
types
Bank would be duplicated (although the
account
manage-
behaviour would vary between the
ment Updated account information bank teller and the customer
system Withdrawal amount
Deposit amount versions)
Interest
rate Interest Is this important to analyse and
Bank
rate Account information
Money
Existing
customer
model?
manager Transaction message
Account message
Account statement
 Why did bank tellers disappear?
Bank teller New Bank tellers don’t seem to do
New customer
anything other than pass on
Account
information
customer
information
information
New customer
information Available If bank tellers are included in the
Updated account
information
account data flow diagram, many processes
types
Bank would be duplicated (although the
account
manage-
behaviour would vary between the
ment Updated account information bank teller and the customer
system Withdrawal amount
Deposit amount versions)
Interest
rate Interest Is this important to analyse and
Bank
rate Account information
Money
Existing
customer
model?
Transaction message
manager
Account message … maybe!
Account statement
 Why did bank tellers disappear?
Bank teller New For the purposes of these models
New customer
as examples to be used in a lecture,
Account
information
customer
information
having the bank teller as well as the
New customer customer processes would not add
information
Updated account
Available
account
much
information types
Bank If we were analysis and modelling
account
manage-
an actual ICT system though, the
ment Updated account information differences might be important
system Withdrawal amount
Deposit amount (and probably are, in the real world,
Interest
rate
but I’m not a banking expert!)
Interest
rate Account information Existing
Bank Money customer
manager Transaction message
Account message
Account statement
Example DFD
 5. Process
specifications
(pSpecs)
a) Purpose
b) Types of process specification
c) Structured language
d) Decision tree
e) Decision table
f) Process specifications vs code
g) Example
Perspective drawing
Purpose
Process specifications further
describe a process
Usually used once you get down to
the point that decomposing the
process into smaller processes no
longer makes sense
Types of process specification
Structured language
Restricted set of English verbs, kind of
like pseudocode
Decision tables/trees
To describe complex decision making
Algorithms
Describe standard knowledge, such as
encryption
Mathematical model
For formulas, equations, and other
Photo of dated instruction manual maths
Image by user: Ocarina188
Graphs and Charts
Types of process specification We’ll concentrate
on these two in
this unit

Structured language
Restricted set of English verbs, kind of
like pseudocode `
Decision tables/trees
To describe complex decision making
Algorithms
Describe standard knowledge, such as
encryption
Mathematical model
For formulas, equations, and other
Photo of dated instruction manual maths
Image by user: Ocarina188
Graphs and Charts
Structured language
Used for sequential processes and
simple control logic
Loops (do something until a condition is
met)
If-Then-Else (if a condition is met, do
something, otherwise do something
different)
Simple sentences that describe
what should occur
Should be readable by a business-
person who is not technically
inclined
Structured language Account information

Account balance
4.1.1 Check account balance
Withdrawal result =
Withdrawal [“Rejected”|“Approved” + Withdrawal
4.1.1 result request + Account Balance]
Get Account balance matching the Check
account
Account Information balance
Withdrawal request = Account
Information + Amount
IF Account balance < Amount
THEN Withdrawal result =
“Rejected” Withdrawal
ELSE Withdrawal result = request
Existing
“Approved” + Withdrawal request + customer

Account Balance
Structured language
2.1 Generate monthly statements
Transaction history Account information

LOOP for each Account Recent transactions

Account
information
Get Account information 2.1
Existing
Get Recent transactions customer
Generate
monthly
statements
Format Account information and
Recent transactions into Statement
Statement
Send Statement to the
corresponding Existing customer
END LOOP when all Accounts have
been processed
 Decision tree Account information

Account balance
4.1.1 Check account balance
Withdrawal result =
Withdrawal result
Account overdraw = “Overdrawn” Withdrawal [“Rejected” | [“Approved”|“Overdrawn”]
permitted + Withdrawal request 4.1.1 result + Withdrawal request + Account
Check
+ Account Balance
account
Balance]
balance
Account balance
< Amount
Withdrawal result Withdrawal request =
Account overdraw = “Rejected”
not permitted Account Information + Amount

Withdrawal
request
Withdrawal result Existing
Account balance customer
>= Amount = “Approved”
+ Withdrawal request
+ Account Balance
Decision table
Account balance < Amount >= Amount
Account overdraw Permitted Not Permitted Permitted Not Permitted
Withdrawal result “Overdrawn” + “Rejected” “Approved” + “Approved” +
Withdrawal request Withdrawal request Withdrawal request
+ Account balance + Account balance + Account balance
Decision table
Account balance < Amount >= Amount
Account overdraw Permitted Not Permitted Permitted Not Permitted
“Rejected”
Withdrawal result

“Approved”
“Overdrawn”
Withdrawal request
Account balance
Decision tree vs table
Process specifications vs code
Process specifications are intended Code is intended to execute
to be simple enough for non-
programmers to still be able to Will probably involve extra
understand them variables, control flow, UI, etc that
is not important at the analysis
Still specific enough to clearly phase, and is not as important from
describe what a process should do the perspective of the business
Example process specification
To verify an ABN:
1. Subtract 1 from the first (left-most) digit of the ABN to give a new 11 digit number
2. Multiply each of the digits in this new number by a "weighting factor" based on its
position as shown in the table below
3. Sum the resulting 11 products
4. Divide the sum total by 89, noting the remainder
5. If the remainder is zero the number is a valid ABN
https://abr.business.gov.au/Help/AbnFormat
(Note: I wouldn’t bother writing this out as a process specification for a “Verify ABN”
process – instead, just point people to the government website!)
1. Data flow diagrams
Show how data moves and is
transformed within a system
2. Syntax and semantics
Recap
Textbook chapters:
Dataflows go between* processes,
datastores, and external entities Systems Analysis and Design
Chapter 7 Using Data Flow
3. Constructing DFDs and levels of Diagrams
DFDs Chapter 9 Process Specifications
and Structured Decisions
Just like a context diagram can be
decomposed into a DFD, a DFD
process can be decomposed into a
‘lower level’ DFD
4. Guidelines
Several, but two key ones:
 Don’t show options using different
flows (instead, define options within a Recap
single flow using data dictionaries) Textbook chapters:
 All data flows should involve a process Systems Analysis and Design

5. Process specifications Chapter 7 Using Data Flow

Diagrams
Used to define processes when further Chapter 9 Process Specifications
decomposition into lower-level DFDs and Structured Decisions
no longer makes sense
In this unit, structured language,
decision tables, and decision trees
I know this is tiny
– there’s a bigger
version on the
Canvas site
 Backpack decisions
Image by Randall Munroe
https://xkcd.com/1952/

Data flow diagrams and process specifications

11486 Systems Analysis and Modelling / 6677 Systems Analysis and Modelling G
Dr Luke Nguyen-Hoan
Now for the interactive
lecture example…
(If you’re just reading these slides, I highly recommend
going and watching from this part on in the lecture
recording, as this is where we go through and actually
analyse the lecture case study and draw something!)