Online
Data Flow Diagrams
Symbols used in DFDs
All DFDs are made up of just four key symbols1, a notation which allows the system to
be represented in enough detail to convey its meaning, but without adding unnecessary
information about hardware etc. The four symbols are given below. If a series of DFDs are
properly constructed, they will provide solid documentation of a system.
External Entity – any data source or data destination. An external entity is not part of the
system being described, but interacts with it.
Symbol
Example
Customer
Process – signifies that some transformation of data takes place. The number in the space at
the top is used in multi-level DFDs (see below).
Symbol
Example
3.1
Create
customer
record
Data Store – shows that data is stored in some way. However the physical media used (eg
hard disk or magnetic tape) is not specified.
Symbol
Example
Customer master file
Data Flow – this shows the flow of data between an entity and/or a process and/or a data
store. A Data Flow arrow should be labelled with a description of the data.
Symbol
Example
New customer information
1
They were originally proposed by Gane & Sarson, in Structured Sytems Analysis and
Design Tools and Techniques, (Prentice Hall, 1979). Since then, their use has become
widespread.
This document is ©2005-2009 Colourpoint Books. It may be used only for non-profit use in unmodified form within
educational establishments. For contact details see www.colourpoint.co.uk
1
Data Flow Diagrams
Developing DFDs
DFDs are developed in stages, with the analyst adding more detail in each diagram than
in the one before. The first diagram produced is called the context diagram (or ‘top level
diagram’). It has four main features:
• The whole system is shown as a single process;
• No data stores are shown;
• Inputs to the overall system are shown, together with data sources (as external entities);
• Outputs from the overall system are shown, together with their destinations (as external
entities).
Figure 1 shows an example of a context diagram, using generic names for the entities and
the processes involved. A real world example is discussed later (see figure 4).
Figure 1: A generic DFD
context diagram.
External
Entity 1
Input A
0
External
Entity 2
Input B
Input C
System
Name
Output A
External
Entity 4
Output B
External
Entity 5
External
Entity 3
Next, a Level 0 diagram is developed. This focuses on the single process that was drawn
in the context diagram by ‘zooming in’ on its contents and illustrates what it does in more
detail. Because we have simply expanded the single process, the same external entities
remain. Each new process is given a number, the importance of which will become clear
later, when we ‘zoom in’ on these processes too. Figure 2 shows an example of a Level 0
diagram.
2
Data Flow Diagrams
1
External
Entity 1
Input A
2
General Output A
process
B
General
process
A
Record A
Data store 1
External
Entity 2
Input B
Record E
Data flow B
Input C
Data store 2
Record A
Record E
3
External
Entity 3
General
process
C
External
Entity 4
4
Data flow C
General
process
D
Output B
External
Entity 5
Figure 2: A generic DFD Level 0 diagram.
The next step in developing the DFD is to show more details for any process above that
requires further explanation. The numbers previously assigned to processes are used to tie
them to their corresponding, more detailed, diagrams. These are called Level 1 diagrams,
with the ‘1’ referring to how far into the system we have ‘zoomed’. This process of refinement
is repeated until all details of the system are properly described.
For example, Process C from figure 2 can be shown as in figure 3. Note that the inputs from
the parent and the outputs from the parent match those found in the Level 1 diagram
shown here. The dotted line is used in this example to show the boundaries of the original
Level 0 process. Although this is not a necessary requirement of a DFD it can be useful to
aid readability.
3
Data Flow Diagrams
Inputs match parent (Level 0)
Data store 1
Record A
3.1
External
Entity 2
Input B
Detailed
process
W
Transation
record 1
Transaction
file 1
Transation
record 1
3.2
Detailed
process
X
Detailed
data flow Z
External
Entity 3
Input C
3.4
3.3
Detailed
process
Y
Detailed
process
Z
Data flow B
Data flow C
Outputs match parent (Level 0)
Figure 3: A generic DFD Level 1 diagram.
An example of an actual system
Consider a simple parish administration system, used to produce the following information:
• For the minister / parish priest:
• A summary of households who are due a pastoral visit;
• A list of households who are due a visit outside their regular time, such as those
with a recent bereavement or birth;
• For the treasurer:
• A weekly summary of parish offerings;
• An annual summary of offerings for the purpose of gift aid1.
1
Gift Aid is a scheme that allows charities to reclaim the tax paid by working people. For
example, a £10 gift is worth the original donation plus the tax originally paid on it.
4
Data Flow Diagrams
To produce a DFD for this system we first produce a context diagram. At this stage we
must think about the inputs to the system. These are the parishioners’ name and address
details, details of visitations and details of gifts to the church.
A context-level diagram of this is shown in figure 4.
Parishoner
Weekly summary
Name/address details
Annual tax report
Treasurer
Minister
or Priest
Weekly offering details
Visitation
records
Updates to parish records
Treasurer
Parish
administration
system
Visits due
Minister
or Priest
Non-regular visits
Figure 4: A context diagram for the parish administration system.
This system is then refined (shown in more detail) as a Level 0 diagram as shown in figure
5. Note that the external entities and the data flows to/from them remain the same, but
more detail is given to the original process.
5
Data Flow Diagrams
Parishoner
Name/
address
details
1
Add/
amend
parish
records
Name/address
details
4
Annual tax
Calculate report
annual
tax
summary
Weekly summary
D1 Parish
records
Treasurer
Weekly
offering details
Updates
to parish
records
Treasurer
2
Enter
weekly
giving
Offering
details
Minister
or Priest
Offering
details
D1 Financial
records
Address details
D1 Visitation
records
Minister
or Priest
Visit details
Visitation
records
3
Update
visitation
records
Visit details
Visits
5
due
List
parishoners due a Non-regular visits
visit
Figure 5: A Level 0 diagram for the parish administration system.
The systems analyst then repeats this process of refinement. For example, Process 5 (‘list
parishioners due a visit’) is developed in the Level 1 diagram in figure 6 as a series of subprocesses. If necessary, the sub-processes themselves can be further developed. By carefully
following this procedure, a complete set of data flow diagrams can be produced to accurately
model a system.
6
Data Flow Diagrams
D1 Parish
records
Name/address details
5.1
List people due 6
-monthly
visit
Regular visit details
D1 Visitation
records
Visit details
Visits due
Minister
or Priest
5.1
List
people
who need
a visit
Non-regular visits
Figure 6: A Level 1 diagram for the parish administration system which expands
Process 5 from figure 5.
Task
Discuss the relative strengths and weaknesses of data flow diagrams. What are they useful
for? What are they not useful for?
7