Data Flow Diagrams
Notation & Rules
The notation used in this tutorial is the SSADM (Structured Systems Analysis
and Design Methodology) version
Data Flow Diagrams (DFDs) are used to show the flow of data through a
system in terms of the inputs, processes, and outputs.
External Entities
Data either comes from or goes to External Entities. They are either the
source or destination (sometimes called a source or sink) of data, which is
considered to be external to the system. It could be people or groups that
provide or input data to the system or who receive data from the system –
Defined by an oval –see below. Identified by a noun. External Entities are
not part of the system but are needed to provide sources of data used by the
system. Fig 1 below shows an example of an External Entity
Customer
Fig 1 – External Entity
Processes and Data Flows
Data passed to, or from an External Entity must be processed in some way.
The passing of data (flow of data) is shown on the DFD as an arrow. The
direction of the arrow defines the direction of the flow of data. All data flows to
and from External Entities to Processes and vice versa need to be named.
Fig 2 below shows an example of a data flow:
Customer details
Fig 2 – Data Flow
Process – processing data that emanates from external entities or data
stores. The process could be manual, mechanised, or automated/computed.
A data process will use or alter the data in some way. Identified from a
© Peter Bilbie - 2004/5
HND Projects
Page 1 of 6
scenario by a verb or action. Each process is given a unique number and is
also given a name. An example of a Process is shown in Fig 3 below:
1
Add New
Customer
Fig 3 - Process
Data Stores
A Data Store is a point where data is held and receives or provides data
through data flows. Examples of data stores are transaction records, data
files, reports, and documents. Could be a filing cabinet or magnetic media.
Data stores are named in the singular and numbered. A manual store such
as a filing cabinet is numbered with an M prefix. A D is used as a prefix for an
electronic store such as a relational table. An example of an electronic data
store is shown in Fig 4 below
D1
Customer
Fig 4 – Data Store
Rules
There are certain rules that must be applied when drawing DFDs. These are
explained below:








An external entity cannot be connected to another external entity by
a data flow
An external entity cannot be connected directly to a data store
An external entity must pass data to, or receive data from a process
using a data flow
A data store cannot be directly connected to another data store
A data store cannot be directly connected to an external entity
A data store can pass data to, or receive data from a process
A process can pass data to and receive data from another process
Data must flow from external entity to a process and then be
passed onto anther process or a data store
A matrix for the above rules is show in Fig 5 below
© Peter Bilbie - 2004/5
HND Projects
Page 2 of 6
Entity Process Store
Yes
No
No
Entity
Process Yes
Store
No
Yes
Yes
Yes
No
Fig 5 – ERD Rules
There are different levels of DFDs depending on the level of detail shown
Level 0 or context diagram
The context diagram shows the top-level process, the whole system, as a
single process rectangle. It shows all external entities and all data flows to
and from the system. Analysts draw the context diagram first to show the
high-level processing in a system. An example of a Context Diagram is
shown in Fig 6 below:
customer
details
Customer
new car details
Customer Order
Details
Management
invoice details
Bilbos
Car
Sales
monthly report
details
staff details
updated customer details
Management
Customer
Fig 6 – Context Diagram for a Car Sales System
© Peter Bilbie - 2004/5
HND Projects
Page 3 of 6
Level 1 DFD
This level of DFD shows all external entities that are on the context diagram,
all the high-level processes and all data stores used in the system. Each
high-level process may contain sub-processes. These are shown on lower
level DFDs.
A Level 1 DFD for the Car Sales scenario is shown in Fig 7 below:
1
2
Create
Monthly
Sales
Report
Add
New
Customer
customer
details
monthly report
details
Customer
D3
customer
details customer
details
customer
details
Management
*
Sales
sales details
Customer
updated customer details
car details
customer
details
D1
D1
Customer
Customer
D3
Sales
sales details
5
updated customer details
Update
Customer
customer
details
*
invoice details
customer
details
D2
sales details
Car
car details
car details
6
Create
Customer
Invoice
car details
3
Add
New
Sale
Customer Order
Details
*
4
staff details
D4
Add New
Car
Details
Staff
new car details
Management
*
Customer
staff details
7
staff details
Add Staff
Details
Management
*
Fig 7 Level 1 DFD for a Car Sales System
© Peter Bilbie - 2004/5
HND Projects
Page 4 of 6
Level 2 DFDs
Each Level 1 DFD process may contain further internal processes. These are
shown on the Level 2 DFD. The numbering system used in the Level 1 DFD
is continued and each process in the Level 2 DFD is prefixed by the Level 1
DFD number followed by a unique number for each process i.e. for process 1,
sub processes 1.1, 1.2, 1.3 etc – see fig 8 below
3
Customer
Add New Sale
Customer Order
Details
3.3
3.1
Add staff
to
order
Validate
Order
*
*
validated
staff dets
validated order
details
3.2
customer
details
Generate
New
Sale
car details
D1
staff details
Customer
car details
D2
D4
Staff
*
sales details
Car
D3
Sales
Fig 8 – Level 2 DFD for Level 1 Process – Add New Sale
Each of the Level 2 DFDs could also have sub-processes and could be
decomposed further into lower level DFDs i.e. 1.1.1, 1.1.2, 1.1.3 etc
More than 3 levels for a DFD would become unmanageable.
Lowest Level DFD’s and Process Specification
Once the DFD has been decomposed into its lowest level, each of the lower
level DFD’s can be described using pseudo-code (structured English), flow
chart or similar process specification method that can be used by a
programmer to code each process or function.
For example, the Level 2 DFD for the Add New Sale process could be
described as being a process that contains 3 sub-processes, Validate Order,
Add Staff to Order and Generate New Sale. The structured English could be
written thus:
Open Customer File
If existing customer
Check Customer Details
Else
Add customer details
End If
© Peter Bilbie - 2004/5
HND Projects
Page 5 of 6
Open Car File
If car available then
Open Sale File
Add customer to sale
Set car to unavailable
Add car to sale
Add staff details
Calculate price
Generate Invoice
Close Sale File
Close Customer File
Close Car File
Inform User of successful sale – exit process
Else
Inform User of problem – exit process
Close Customer File
Close Car File
End If
The above example is not carved in stone as the analyst may decide to write
separate functions to validate customer and car details and that the Generate
New Sale process could include other sub-processes.
All that matters is that the underlying processing logic solves the problem.
For example, if you look at Figure 8 there is a process named Validate Order,
which has a duel purpose of checking both the customer details (is customer
a current customer, if not add to customer file) and the car details (is car
available, if not stop the sale process). A separate process called ‘Validate
Order’ could be created, but I have written the structured English to show a
logical sequence that shows that, only if the car is available do we begin the
transaction of creating the sale.
I have also assumed that the staff dealing with the sale will know their own
details so there would not be a need for the process named ‘Add Staff to
Order’.
Like all analysis and design processes, the process of producing DFDs and
writing structured English is an iterative process
© Peter Bilbie - 2004/5
HND Projects
Page 6 of 6