Understanding DFDs DATA FLOW DIAGRAMS Dr.

Baldwin
Data Flow Diagrams (DFDs) are a graphical representation of the logical processes in a
system.1 Remember, a picture speaks a thousand words! DFDs allow a systems developer to
describe the logical design of the system without committing prematurely to a technical
implementation or to describe the system currently being used. DFDs also help explain the
interrelatedness of the system and its subsystems. Finally, DFDs are useful for communicating
knowledge about the system to users (i.e. you don't have to be a techie to understand DFDs!).

The physical implementation of the system is purposefully left out of DFDs. This lets the analyst
and the users conceptualize the data movement and processes without being tied to a particular
implementation. Also, DFDs do not indicate whether a process is automated or manual because
this is not relevant to understanding the conceptual logic of the system.

DFDs use only four symbols.

Process (bubbles)
[also known as Transforms] or

Data flow

Data store

External Entity

Processes are activities that transform data. Data flows lead into and out of process "bubbles"
but data flowing out of a particular process bubble are always different from data flowing in.

Data flows represent the logical movement of data. The head of the arrow points to the data's
destination. Keep in mind that these are logical flows, not necessarily physical flows of physical
objects.

Data stores are places where data is stored. The type of storage is not denoted - remember
DFDs are logical not physical representations of a system.
1
Note: some textbooks discuss "physical DFDs" but these are not in general use in the real world and only cause
confusion when learning about DFDs. Instead, we will focus on the logical/conceptual aspect of DFDs.
External entities are those persons, systems or organizations outside of the system being
described that interact with it. Examples include customers, suppliers, government, banks, and
other subsystems of the organization that are outside the scope of the DFDs being drawn.

That's all there is to it. Well, mostly. These four symbols are used to describe the system and its
logical processes. DFDs are prepared in sets. The set is hierarchical in nature. Each additional
DFD shows an increasing level of logical detail. Going from a higher level diagram to a lower
level diagram is referred to as "exploding" the diagram or process bubble, to show a more
detailed picture.

The first diagram, the context diagram, is used to set the system in its context. The context
diagram is the most general or broad DFD. It shows all the external entities that interact with
the system and the major data flows. It need not show every data flow that goes into or out of
the system!

The second diagram is always the Level 1 diagram or Diagram One. This diagram shows the
basic logical processes in the system.

Every other additional diagram is drawn to explain the detail represented by just one process
bubble in a higher level diagram. Every diagram after the diagram zero will be named for the
(numbered) process bubble it is exploding or explaining.

Some conventions to know about DFDs are:

A. Every diagram and element has a name.
1. Process bubbles are labeled with verb phrases (except sometimes on the context
diagram).
2. Data flows, data stores and external entities are named with descriptive noun
phrases.
B. Every process bubble and every data store should be numbered.
C. When process bubbles are exploded, use decimal numbering to indicate related detailed
processes
D. Avoid duplication of identical entities and data stores on the same diagram page.
E. Avoid crossing data flow lines.
F. Keep external entities near the outer edges of the diagram.
G. Use a top down approach when developing a set of DFDs.
H. All data flows either originate or terminate at a process bubble.
I. Diagrams should be balanced. Every flow shown going into or out of a process bubble,
should also appear on its lower level diagram.
J. Redraw diagrams and re-label symbols as needed for clarity.
1. Avoid crossing lines if at all possible.
2. If necessary, use hoops to show that lines cross but do not intersect.
K. If the rules get in the way, bend the rules.