Data Flow Diagramming by Example. Process Modeling Techniques for Requirements Elicitation (2015)

Discovering Missing Processes and Data

Questions answered in this chapter:

§ What does balancing a Data Flow Diagram mean?

§ What is the business value of balancing?

§ What is the most efficient approach to balancing a DFD?

To confirm that it is indeed correct and complete, the next step is to ‘balance’ the two diagrams. What does that mean?

There are actually two steps to balance the individual levels of DFDs. The first step is very simple in that you are comparing flows entering and leaving the detail level diagram with the higher level diagram. To do that, I need to be able to view both diagrams at the same time.

In our example, we exploded the ENTER ORDERS process from the context diagram. If I now compare the exploded version with the context version, logic dictates that all flows going into or coming out of the ENTER ORDERSprocess on the context diagram have to show up on the exploded version going into or coming from one of the more detailed processes at that level and vice versa.

I find it simplest to balance starting at the upper level and comparing flows clockwise from that diagram to make sure they all appear on the lower level. I check the flows off on both diagrams as I go to have a visible trail and ensure that I am not missing anything. Looking at the context diagram, I see Orders, Payments, Complaints coming from customer into ENTER ORDERS. I see the same flow on the detailed view coming from CUSTOMER into SORT MAIL. These flows are the same; therefore, I put a checkmark on them on each diagram.

Continuing clockwise around ENTER ORDERS on the Context Level diagram, I see a New Customer Order going to the CREDIT DEPARTMENT. I see the same flow in the same direction on the lower level diagram, so I check those off. I also see matching Credit OK Orders coming back from the CREDIT DEPARTMENT and can check them off as well.

Next I see Valid Orders going from ENTER ORDERS to the WAREHOUSE. On the detailed diagram, I see Groups of Valid Orders going to the WAREHOUSE. After confirming with Paul that that is the only data flow to the warehouse, I would like to remove the discrepancy to avoid misinterpretation. Since the detailed level is more specific, I change the context diagram to read Groups of Valid Orders and check both flows off.

On the context diagram, the next flow out of ENTER ORDERS is the Copy of Order with Payment, Payments being sent to ACCOUNTING. On the detail level I see Payments going from SORT MAIL to ACCOUNTING, so I can check off that part of the flow, but what about the other half? It appears that we missed something.

I ask Paul where the Copy of Order with Payment comes from and he explains that ACCOUNTING requested a copy of any order that has an attached payment. As a result, while they sort the mail, they separate orders with payment from orders without payment. Once they are done sorting, they go through the stack with attached payments, remove attached checks from orders, make a physical copy of that order, attach the check to the copy, and put the copy of the order with the attached check on the stack of payments destined for ACCOUNTING. If the attached payment is at least half of the total order price, the original order is stamped “Credit OK” and sent directly to the VALIDATE ITEMS process, bypassing the VERIFY CREDIT process.

This additional information creates a problem. Obviously, we missed this little nuance in our original analysis, so we have no choice but to correct the lower level diagram to reflect the newly discovered facts. We add a process COPY ORDERS w/$ between SORT MAIL and ACCOUNTING. We add a flow Orders w/$ from SORT MAIL to COPY ORDERS w/$ and then add the outgoing flows Copied Orders w/$ to ACCOUNTING, Original Order to VERIFY CREDIT, and Credit OK ORDERS flow to the VALIDATE ITEMS process. I have to change the Order flow between SORT MAIL and VERIFY CREDIT to read Orders w/o $. In addition, I change the context diagram flow Copy of Order with Payment, Payments to read Copied Orders W/$, Payments and check matching flows off on both diagrams.

That is a great example of how exploding and leveling a data flow diagram can identify a missing process.

Back to the context diagram, I see a New Order coming in from CUSTOMER SERVICE. On the detail view, I have a Valid Order and a Credit OK Order both coming from CUSTOMER SERVICE. Which is the New Order? Paul explains that the New Order is one that CUSTOMER SERVICE creates in response to a complaint. It is considered a Credit OK Order by the Order Entry Department and they just check the item numbers, so I change the New Orderflow on the context diagram to read Credit OK Order and mark those two flows off. Note, I can only mark the Credit OK Order from CUSTOMER SERVICE off on the detailed diagram although I have three other flows on that diagram that are all named Credit OK Orders. I also mark the matching flows Complaints going from ENTER ORDERS to CUSTOMER SERVICE on both diagrams.

Having completed that step, I am satisfied that all flows that are on the context diagram involving ENTER ORDERS are taken care of. What about the opposite, have I checked off all of the flows coming into or leaving the detailed diagram? Here I am only interested in flows that are between the detailed processes and external entities and can ignore the internal flows between processes.

Starting with the data flow Orders, Payments, Complaints coming from the CUSTOMER, I proceed clockwise around the lower-level diagram to see if there are any unmatched flows. I note an Invalid Items data flow going to CUSTOMER SERVICE that has no match at the context level. Confirming with Paul that the detailed view is correct, I simply have to add that flow to the context diagram flowing from ORDER ENTRY to CUSTOMER SERVICE. I can then mark both flows as matching.

Continuing, I discover that the detailed diagram also shows CUSTOMER SERVICE sending Valid Orders directly into the internal data store with that name. On the context level diagram, they only send Credit OK Orders. Checking with Paul, I discover that Valid Orders from Customer Service are the corrected Invalid Orders they received from VALIDATE ITEMS. As a result, I add a separate flow Valid Orders from CUSTOMER SERVICE to ENTER ORDERS on the higher level diagram.

Finally, I find a Credit NOK Order going to the CREDIT DEPARTMENT on the lower level that is also unmatched. Again, since the flow is correct, I simply add it to the context diagram and mark it off on both diagrams.

I now have a wonderfully balanced set of two diagrams, one showing the context of the project and the second detailing the ENTER ORDERS process. Obviously, if my project had included the WAREHOUSE or CREDIT DEPARTMENT, I would repeat the process for each respectively and would probably identify additional disconnects there. Given the scope of this project, I could be done at this time. If I feel that all project stakeholders understand every process on my lower level diagram at the level of detail they need to make their contributions, I would consider the diagramming step complete. Otherwise, there is still work to be done.