Guidelines for Drawing Dataflow Diagrams

Naming conventions:
o Processes: strong verbs
o dataflows: nouns
o datastores: nouns
o external entities: nouns

No more than 7 - 9 processes in each DFD.

Data flow diagramming mistakes

As one rule of thumb, imagine that you are producing a diagram that must pass this test: you will
finish the DFD, and then hand it to someone (of reasonable intelligence) who will then proceed
to describe the process back to you based upon what he or she sees in your diagram. If this
process recitation captures your original process description (and, of course, the appropriate
characteristics of the business process itself), your DFD is reasonably accurate.
With such problems in mind, this section considers some of the common mistakes that occur
when one first tries to build DFDs. There are several common types of mistakes. One that is easy
to check for and correct involves using so-called illegal data flows.
Illegal data flows
One of the patterns of data flow analysis is that all flows must begin with or end at a processing
step. This makes sense, since presumably data cannot simply metastasize on its own without
being processed (in spite of the circumstantial evidence we might have gathered in our own
business experience...). This simple rule means that the following mistakes can be fairly easily
identified and corrected in a DFD.

Diagramming mistakes: Black holes, grey holes, and miracles

A second class of DFD mistakes arise when the outputs from one processing step do not match
its inputs. It is not hard to list situations in which this might occur:

A processing step may have input flows but no output flows. This situation is sometimes
called a black hole.

A processing step may have output flows but now input flows. This situation is
sometimes called a miracle.

A processing step may have outputs that are greater than the sum of its inputs - e.g., its
inputs could not produce the output shown. This situation is sometimes referred to as
a grey hole.

When one is trying to understand a process during the course of an interview (and consequently
drafting DFDs at high speed), it is not hard to develop diagrams with each of the above
characteristics. Indeed, scanning DFDs for these mistakes can raise questions that provide
questions for use in further process analyses (e.g., "Where do you get the data that allows you to
do such-and-such...").

DFDs are not flow charts

A last class of DFD mistakes are somewhat more difficult to identify. Many of us have had prior
experience developing flow charts. Flow chart diagrams can be useful for describing
programming logic or understanding a single sequence of process activities. It is important to
recognize, however, that DFDs are not flow charts. Flow charts often show both processing steps
and data "transfer" steps (e.g., steps that do not "process" data); DFDs only show "essential"
processing steps. Flow charts might (indeed, often do) include arrows without labels: DFDs
never show an unnamed data flow. Flow charts show conditional logic; DFDs don't (the
conditional decisions appear at lower levels, always within processing steps). Flow charts show
different steps for handling each item of data; DFDs might include several data items on a single
flow arrow.
With these distinctions in mind, the following diagrams suggest some DFD drafting mistakes
that might be influenced by prior experience with flow charts.

In the example above, a processing step is included that does not actually change any data. This
step (titled "route transaction") might appear on a flow chart but would not appear on a DFD.

In the example above, the left side tries to represent the disposition of a credit receipts after a
credit card purchase has been approved. Branching, whether relating to data or to conditional
decision-making, might appear on a flow chart but would not appear on a DFD.
How does one decide what goes on a DFD? One answer lies in understanding the difference
between a physical and logical model of a process. The logical model describes only those
processing steps that are essential to completing the process. These may not be immediately
obvious during early steps in process analysis, so be prepared to sketch multiple drafts of a
DFDs. One of the reasons that this technique was developed was to enable systems analysts to
sketch meaningful process descriptions on a single piece of paper during discussions with
business managers (even an envelope or a napkin, no kidding). The technique is designed for

rapid diagramming and multiple iterations. Don't be dismayed if your first draft has mistakes those mistakes are one of the ways that you know how to ask more insightful questions of the
process.
As a final aid in developing DFDs, consider the following description of processing steps. It
suggests five characteristics of processing steps that change data (and so deserve to be included
on a DFD).