s1ne206 Data Flows: Common DFD Mistakes Data flows: Note on Data-Driven Process Modeling [introduction [Data flow diagrams (DFDs} |A Focus on Data (Common DED mistakes Summary/next steps Data flow diagramming mistakes DEDs look easy on the surface - afier 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 DED, 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. legal 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 (¢.g., without captions) so that it is easier for you to recognize patterns such as these in your own DFDs. Table2: Common data flow diagramming mistakes Wren, Right Deaiption ‘A source or asmk cannot provide x [ { data to another source or sink without some processing ‘Data cannot move divecly from @ source to a date stoze without being processed. ] ‘Data canaot move dveclly from @ x = data store to asink without beng processed. ‘Data cannot move dieclly fom | oO Pred cone data store to another without being processed Tous Aiaped San igus )9,p Si Wate | Ly Bakey, L Ds, VME QOS, Spine aoabis and Design Matos EE Editon. Bub Bilge, inwin Diagramming mistakes: Black holes, grey holes, and miracles A second class of DFD mistakes arise when the outputs from one processing step do not mateh its inputs. It is not hard to list situations in which this might occur: eptaculy babscn eduldewiralReadingslcist im “4ina20%6 Data lows: Common DFD Mistakes ‘+ 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), itis 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 DED mistakes. By tracing the inputs and outputs affecting each processing step, you can avoid them in your own diagrams. Figure 5: Common DFD drafting errors: black holes, grey. holes, miracles Eapiyes Bank aaternent Inputsaot product ostouts: Inoute het mo outa: ‘4 bizch hole Membeihip Arey hole application Ganante 43 employee EXSTaCOUA—*} member [Enpioyca dae statements oocunt and adsrest Member accounts Employees 20 3 Modified accountstatie | Freeze Taner nocay nde Accounts soocunt Recsivable rumber Department Dutouts tut a ints: A mirgole Soumoe Adapedsean Figue 95, y 296 in Qh JL; Baey,L Dsl V. M0009, Syrtans nadie and Design Mettods (Thad Eaten Butt Ride, Ls tren DEDs are not flow charts A last class of DED 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. eptaculy babscn eduldewiralReadingslcist im 8s1ne206 Data Flows: Common DFD Mistakes With these distinctions in mind, the following diagrams suggest some DED drafting mistakes that might be influenced by prior experience with flow charts. Figure 6: Processing steps that do not change data don’t belong in DED, Wrong, Right nm aI sha a oe LT |. FS = coon | Foes [Recei [raven Pees | teceipp —= payment Complaint ~) Lo aa Compe Pact | rasan a compial caplant Response Toa Abyedaon Rgue dp a7 in Wane, PEs Beniey Ly Rais VM GO), Speen aa and Desa eos Ga Baiting. Bu Bilge, I: ine 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. Figure 7: Conditional/diverging data flows should he replaced by individual flows Wrong Right Bi Rather — Sat J Batons — rest + payment aymen by spiner [See a voucher] ead Felt saa oucner dus [ wovchers cue Payments on Tomes Adapedon Rogue 0S, p G0 Wainan} Ls SenieyL Ds eavlow, Wh (OM), Sysmns Aula aa Desa hetiow Tae Eaten, Bue Bdge, Is inc 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 DED. How does one decide what goes on a DED? 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. Asa 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). eptaculy babscn eduldewiralReadingslcist im a4ine20%6 Data Flows: Common DFD Mistakes Table3: Processing steps to he considered in drafting DFDs Tndlude processing steps that Example) Pesfomn computations ‘A procesing step that develops chaiges associated with a predurt or sevice, eg, “Price consulting engagement” “Wake decsioas ‘A processing step that qualifies a potential customer as a good prospect based on demographes, income level, and the number of times that the incivical has responded to company product tris Spit dita Hows based on content ox business mules ‘A processing step that separates approved oxdes from rejected orden based on cerdlit mies, Filter and/orsummazze data fous to produce nzw data Dow() ‘A procesing step where speciiio data temas may nol change, but the structure ofthe data dots, eg, fikesiag invoice data to identify products thet woes in higheot domand dusing tho past turo welt Tomer Adaya any Tm Whiten J Ly Sewwky LD Barlow, WM G0s4) Syste AnalyasansDesgn Metiods Thid ator) Bar Hid, I: Dum, Next: Summary and next steps. @ 1999 Charles Osbom eptaculy babscn eduldewiralReadingslcist im 4s