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

@ 1999 Charles Osborn