Chapter 8 • Basic Systems Concepts and Tools 345The Logical To-Be model is most closely associated
with the data flow diagram (DFD)(see Hoffer et al.,
2010, for a thorough discussion of DFDs). The DFD
notation itself is technology independent; the symbols
have no association with the type of equipment or the
humans that might perform the process activities or store
the data. DFD creation typically involves groups of people
and is accomplished through multiple iterations.
Four types of symbols are used in DFDs:
External EntityA square indicates some element in the
environment of the system that sends or receives data.
External entities are not allowed to directly access data
in the system but must get data from processing com-
ponents of the system. No data flows between external
entities are shown. External entities have noun labels.
Data FlowArrows indicate data in motion—that is,
data moving between external entities and system
processes, between system processes, or between
processes and data stores. Timing and volume of
data are not shown. Data flows have noun labels.
ProcessCircles represent processing components of
the system. Each process has to have both input and
output (whereas an external entity may have either
input, output, or both). Processes have verb-phrase
labels as well as a numerical identifier.
Data StoreRectangles depict data at rest—that is, data
temporarily or permanently held for repeated reference
by one or more processes. Use of a data store implies
there is a delay in the flow of data between two or
more processes or a need for long-term storage. Each
data store contained within the system must have both
input and output (i.e., be populated and be used) with-
in the system. Data stores that are outside the system
may provide only input or only output. Data stores
have noun labels and a unique identifier.The process of creating data flow diagrams is as
follows:
- Identify the entities that supply or use system
information. - Distinguish processes from the data that they use or
produce. - Explicate business rules that affect the transforma-
tion of data to information. - Identify logical relationships.
- Pinpoint duplicate storage and movements of data.
In Figure 8.13, a “top-level” DFD for the accounts
payable system is shown. Consistent with the context (data
flow) diagram of Figure 8.11, the dashed line delineates
the system boundary. The system includes four processes
(circles). Data stores internal to this system (D2, D3, and
D4) serve as buffers between the process components (e.g.,
to compensate for different processing rates of the compo-
nents or to permit batch processing of transactions) and
also as semipermanent storage for auditing purposes.
Because this is a top-level DFD, or macro view, processing
details are not depicted. For example, this top-level
diagram does not show what happens to exceptions—such
as what the process does to deal with invoices that do not
match purchase orders or shipment receipt records.
A key to the effectiveness of DFD modeling is the
enforcement of strict hierarchical relationships. Each
process (circle) on a DFD has a lower-level DFD that
documents the subprocesses, data stores, and data flows
needed to accomplish the process task (each lower-level
DFD would be a separate diagram, and for simplicity, we
do not show any of these here). This “explosion” contin-
ues for each subprocess until no further subprocesses are
needed to describe the function. A process at the lowest
level in the model must be definable by a few descriptive
sentences. The process decomposition relationship is
shown by the process numbering scheme (1.1, 1.2, etc.)
for processes on the DFD for the explosion of process
1.0, and then processes 1.1.1, 1.1.2, and so on for
processes on the DFD for the explosion of process 1.1.
The lower-level DFDs can result in the identification
of additional data stores and data flows as well as
subprocesses, but the exploded DFDs must balance with
their higher-level counterparts. All data flows identified in
a lower-level DFD must be accounted for in the descrip-
tion, source, and destination of data flows at the higher
level. During the Logical To-Be defining process, external
entities and data flows sometimes will need to be added to
higher-level DFDs to assure completeness. It is not
uncommon for business systems to have four or five levels
of DFDs before exhausting all subprocesses.
When complete, DFDs tell a story about the business
process that does not depend upon specific forms or
technology. The rigor imposed by the explosion, aggrega-
tion, balancing, and documentation of DFDs results in more
than simple circle-and-arrow diagrams. For example, from
reviewing the accounts payable DFDs, we see the following:1.Purchase orders and shipment receipt records are
produced by systems outside the accounts payable
system (because they are shown as inputs from the
environment—that is, outside the system boundary).
2.The payable invoice data store temporarily stores
and groups invoices after invoice approval and
before subsequent vendor account updating and
check writing (data flows into and out of D2). These
statements describe two aspects of the accounts