Drawing a Detail Level DFD - Data Flow Diagramming by Example. Process Modeling Techniques for Requirements Elicitation (2015)

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

Drawing a Detail Level DFD

Business Analysis Questions Answered

Questions answered in this chapter:

§ What is a simple approach for drilling down into a process?

§ Why do it and where can I start?

§ How can I show the internal processes and flows that produce the results?

Looking at the Context diagram, the “Orders, Complaints, and Payments” data flow from the CUSTOMER is where it all starts and looking at our list of potential internal processes, SORT MAIL appears to be the first step in the process.

The customer triggers all the action in our department. We receive an order (with or without payment), a complaint, or a payment (with or without invoice copy) from the customer. These are separated and the following actions take place:

Therefore, I start my detailed diagram on the left side of a new sheet of paper with the Orders, Complaints, and Payments flow coming from the left into the process SORT MAIL. By the way, data flow diagrams tend to grow wide as opposed to high so I suggest drawing the diagram in ‘Landscape’ orientation. With that layout option, I am going to try to simply draw the diagram horizontally across the middle of the page, leaving space both above and below the symbols for additional information that I somehow always need.

Note that I am exploding a process ENTER ORDERS from a higher level diagram which clearly shows the Orders, Complaints, and Payments data flow coming from the external entity CUSTOMER. Technically speaking, I do not have to repeat the external entity symbol on the lower level diagram — but I will if it adds clarity.

Based on Paul’s explanation of what the SORT MAIL process entails, I add three separate flows Orders, Complaints, Payments as the outcome of the process. Since my primary interest is the Orders, that is the data flow going out to the right of the process. The other two secondary flows come out of the lower part of the process symbol.

Enter Orders

Based on the narrative, the next step in the process is VERIFY CREDIT so I add a process with that name to the right of the SORT MAIL process with the Orders data flow coming into it from the left.

Interview Notes

If it is an order, we verify an existing customer's credit status and then we verify that the item numbers are valid by checking our inventory file. New customer's orders are sent to the credit department and held until they clear a credit check. (If half payment or more is included, that order is treated as if it were a credit order with good credit.)

The verb ‘Verify’ on a process model always implies two inputs. I need something to verify (in this case the customer info from the Order) and something to verify it against. The narrative does not state what that is but Paul explains to me that he verifies a customer’s credit status by checking the CUSTOMERS data store.

This revelation causes me to add the data store CUSTOMERS above the VERIFY CREDIT process and the data flow Customer Credit Status from CUSTOMERS to VERIFY CREDIT. Drawing this forces me to ask Paul what happens if the customer is not in the CUSTOMERS data store? “Well, that would mean it is a new customer in which case we send the order over to the CREDIT DEPARTMENT for a credit check,” Paul replies.

I represent this knowledge by adding a data flow labeled New Customer Order coming out of the bottom of the VERIFY CREDIT process. Since the flow with that name is shown on the Context Diagram going from ENTER ORDERS to the CREDIT DEPARTMENT, I do not have to draw the external entity CREDIT DEPARTMENT on my detailed diagram (but I will if it adds clarity).

Enter Orders Continued

Customers with good credit go to the next process, which our narrative indicates is the VALIDATE ITEMS process so I add Credit OK Orders coming out of the right-hand side of the VERIFY CREDIT process going into the left side of the new VALIDATE ITEMS process.

Interview Notes

If it is an order, we verify an existing customer's credit status and then we verify that the item numbers are valid by checking our inventory file. New customer's orders are sent to the credit department and held until they clear a credit check. (If half payment or more is included, that order is treated as if it were a credit order with good credit.)

That begs the question, “What happens to customers with bad credit?” which Paul explains are also sent to the CREDIT DEPARTMENT. This adds the flow Credit NOK Orders drawn parallel to the New Customer Orders flow below the process. Since both data flows are going to the CREDIT DEPARTMENT, I add that external entity to the diagram to make it visible at this level.

Enter Orders Continued

Having done that, I refer back to the context diagram and see the Credit OK Orders data flow coming from the CREDIT DEPARTMENT once a new customer has cleared a credit check. I ask Paul and he explains that these orders go directly into the VALIDATE ITEMS process the same as the Credit OK Orders coming from our internal VERIFY CREDIT process. I can simplify my diagram then by merging the two incoming flows and removing the name from the data flow from the CREDIT DEPARTMENT. I like to keep the diagram as ‘clean’ as possible as too much clutter confuses people. If two flows are identical, I would like to have the name of the data flow on the diagram where the two become one.

Enter Orders Continued

According to the narrative, the VALIDATE ITEMS process needs access to an INVENTORY file, so we add the data store symbol with that name. When I ask Paul what they need from the INVENTORY file to verify the item numbers, he replies Item Numbers and Descriptions, so I add that flow from INVENTORY to VALIDATE ITEMS.

The action ‘validate’ is just like ‘verify’ in that there will always be two possible outcomes, a good and a bad. Orders on which all item numbers are valid are called Valid Orders and these are accumulated — which is not a legitimate internal process but implies a data store. I add the data flow Valid Orders going out the right side of VALIDATE ITEMS into a new data store with the same name.

Another convention of DFD’s states that if the data flow going into a data store has the same name as the data store itself, I do not have to name the data flow as it is self-evident. Removing the name from the flow allows me to shorten the arrow and move the data store VALID ORDERS closer to VALIDATE ITEMS, which frees up space for one more process.

First, however, I have to ask Paul what happens if there is a mismatch between an item number and description on the order and the item number and description on the INVENTORY file. He replies that would make it an Invalid Order which they send to CUSTOMER SERVICE so they can contact the customer to clarify exactly what the customer intended to order. Since this revelation is new to me, I add the external CUSTOMER SERVICE below the VALIDATE ITEMS process as the recipient of the Complaints flow and add the data flow Invalid Orders coming from VALIDATE ITEMS to CUSTOMER SERVICE.

Enter Orders Continued

As always when I discover a new flow to an external, I need to ask the follow-on question, “Do you get anything back?”

“Sure, we get a Valid Order back from CUSTOMER SERVICE,” Paul replies.

“And what do you do with that Valid Order?”

“It goes directly into the VALID ORDERS pile just like those orders that passed the VALIDATE ITEM test.”

This statement adds the flow from CUSTOMER SERVICE to the data store VALID ORDERS. Again, since the data flow and the data store have the same name, I do not put the name on the data flow.

Enter Orders Continued

The final internal process on our list of candidates is GROUP ORDERS and the narrative confirms that valid orders are ‘grouped into shipping zones’, so I add a process GROUP ORDERS to the diagram and add a data flow coming from the VALID ORDERS data store.

Interview Notes

Valid orders are accumulated and grouped into shipping zones and transmitted to the warehouse to be filled. After an order is filled, the customer address is attached, the best or requested shipping method determined, postage or shipping costs calculated, the order is shipped, and the . . .

My discussion with Paul reveals that SHIPPING ZONES is a data store, which I add above the process GROUP ORDERS and connect the two with a data flow down to the process.

Enter Orders Continued

The phrase ‘transmitted to the warehouse’ represents a flow from the GROUP ORDERS process to the WAREHOUSE.

Interview Notes

Valid orders are accumulated and grouped into shipping zones and transmitted to the warehouse to be filled. After an order is filled, the customer address is attached, the best or requested shipping method determined, postage or shipping costs calculated, the order is shipped, and the . . .

Logically, we name the data flow Groups of Valid Orders to indicate that both the validation and grouping processes are complete. As per convention, I can either put the WAREHOUSE entity on the diagram or leave it off, as it is obvious on the context diagram.

Enter Orders Continued

The next sentences in the interview notes from Mary describe what the WAREHOUSE then does with the order. The WAREHOUSE might be of interest if I decide to create a data flow diagram of the order fulfillment process, but in that case, I would really have to talk to someone in the WAREHOUSE to make sure I understand that process. Since the WAREHOUSE is an external entity, I do not have to worry about that for this project.

At this point, we have used all of the internal processes we identified in our initial analysis of the interview notes. Looking at the diagram, I notice that every flow leaving one of the internal processes goes to an external entity at this level with the exception of the Payments flow, so I add ACCOUNTING to the diagram to make it consistent. Voila, we now have a first cut data flow diagram of how the ENTER ORDERS process works. The only question is, how can we confirm that it is complete?

Enter Orders Continued