Data flows: Note on Data-Driven Process Modeling

Data flow diagramming mistakes

DFDs look easy on the surface - after all, what's hard about writing down a few bubbles and arrows? In practice the techniques proves to be somewhat more difficult than one might initially anticipate. Obtaining appropriate names for both processing steps and data flows can require careful thought. As one rule of thumb, imagine that you are producing a diagram that must pass this test: you will finish the DFD, 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. The symbols shown below are purposefully left blank (e.g., without captions) so that it is easier for you to recognize patterns such as these in your own DFDs.

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 [3]. 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..."). The following diagram illustrates these common DFD mistakes. By tracing the inputs and outputs affecting each processing step, you can avoid them in your own diagrams.

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).