Data flows: Note on Data-Driven Process Modeling
Data Flow Diagramming
In this course we will use data flow analysis to understand patterns
of data movement within processes. DFDs provide one technique
for isolating the data stores used by a process and the major
data entities that those stores contain.
Data flow diagrams (DFDs) offer a graphical technique for summarizing
the movement of data between the processing steps that occur within
a business process. They isolate the collections of data, or data
stores, which accumulate during a process, and identify the sources
of data that arise outside process boundaries. Some key characteristics
of data flow diagrams are:
- Two-dimensional summary. DFDs offer a way to summarize
the data flow characteristics of a process on a single page. As
such they can provide a useful and concise summary of system-related
(e.g., data-driven) process attributes.
- Completeness. DFDs offer a way to check the completeness
of your process model, particularly as regards your understanding
of the data that would be required by an information system (e.g.,
is all the data that would be needed for input actually available?
Does each processing step produce data that could be used by subsequent
steps? Is all data generated usable by an information system where
necessary?). DFDs can provide a fast way to generate further questions
that need to be asked about the process.
- Processing, not processes. DFDs refer to "process"
steps. It might be more useful to think of DFD "processes"
as processing steps rather than process activities. In
essence, DFDs ask one to refer to the information systems implications
of any processing work that occurs during the tasks that comprise
a business process. DFD terminology tends to confuse the term
"process" in its connotation with business process
with the term "process" that refers to a computational
process executing within software (e.g., a software algorithm).
Whether this represents the presumption among information engineers
that everything is just a version of a computational process
is a subject for further discussion at a later time (and the winner
of the debate receives the Golden Nerd Award); the point here
is that it is safer to think of DFD "processes" as processing
steps.
- Patterns. DFDs can provide a shorthand for understanding
patterns that exist within the data flows supporting business
processes. They can show, for example, where large amounts of
data are collected, stored, transferred, generated, used, and
delivered. They can highlight areas of potentially extraneous
activity, and can suggest process components that do not receive
the information support that they deserve (or need).
Symbols used in DFDs
Table 1 summarizes the graphical symbols used in data flow diagrams.
The vocabulary used by DFDs is very simple, comprising only four
symbols: data flows, processing steps, sources/sinks, and data
stores.
see also [2]
An example can probably provide the best way to understand how
a data flow diagram can summarize knowledge about a process. The
diagram on the next page illustrates how a systems analyst might
use a DFD to describe data flows, processing steps, sources, sinks,
and data stores used to describe an individual's relationship
with his or bank. The DFD describes the processing transactions
that take place as the individual and the bank jointly manage
a set of customer accounts. The process(es) described include
most operational aspects of handling the customer's money, including
making deposits, funding withdrawals, paying bills (perhaps a
service provided by electronic banking), and reconciling account
balances. Some of the data stores can be translated almost directly
into database specifications (e.g., "Account transactions").
Others show how the notion of data stores can apply equally well
to data that are captured in paper form (e.g., "Monthly account
statements"). Throughout, the data flow arrows identify data
items and groups of data items that move between sources, data
stores, and processing steps. Note that processing steps represent
those points at which data from sources and data from data stores
come together, resulting to some change in specific data items
maintained by the bank.
Source: Adapted from Figure 9.3, p. 351 in Whitten,
J. L.; Bentley, L. D.; Barlow, V. M. (1994). Systems Analysis
and Design Methods (Third Edition). Burr Ridge, IL: Irwin.
What are some of the advantages of using DFD analysis? Here are
several:
- Data flows and process consequences. Note how this
representation of the data characteristics of banking operations
enables us to start at any point in the operation (e.g., deposits,
withdrawals, or bill payment), and follow the consequences of
that activity through to the point where all appropriate account
balances have been adjusted and reconciled. Wherever we start
in the process, we can understand the processing steps that the
bank would need to take to complete the relevant transaction(s)
and to inform its constituents of the results.
- Data inputs and outputs. The DFD also makes it possible
to understand what data are needed to provide appropriate inputs
to any processing step. If, for example, we were to build an information
system to support this individual's banking activities (in the
days before Quicken and/or Microsoft Money), we would need to
understand exactly what data items are represented by data flows
such as "Monthly Statement", "Pay earned",
"Withdraw or transfer", and other arrows shown in the
diagram.
- Simplifying complexity by isolating process components.
Note how the DFD would make it easier to capture the detail of
such data flows. By isolating "Withdraw or Transfer"
within the larger scheme of the banking process, the DFD makes
it possible to consider the details of the data items included
in this flow without reference to the flows affecting other processing
steps. All of the flows affecting withdrawals (e.g., processing
step 3.0, "Withdraw funds from account") are isolated
as entering or leaving processing step 3.0. At the time that DFDs
were developed, this shift towards modularizing data flows and
processing elements represented a major step forward in enabling
systems analysts to add useful structure to process representations
rapidly and easily.
Next: Common DFD mistakes