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

Visualizing Project Scope

Questions answered in this chapter:

§ What is the difference between a Rigorous Physical Process Model and a Context-Level DFD?

§ How can I convert the RPPM to a legitimate DFD?

§ Why is this conversion necessary?

At this point, I have a great diagram of the situation described in the narrative. The problem is that it does not follow the rules governing symbols on a Data Flow Diagram. All I have are circles with NOUN names but according to the rules, circles represent PROCESSES on a DFD and PROCESSES have to have a VERB/OBJECT name (do something to something)! The reason for this is that I drew the Rigorous Physical Process Model without knowing which of these depicted people and places are in scope for my project and which are not. I need to get an answer to the scope question to convert this Rigorous Physical Process Model to a Context Data Flow Diagram.

As the one wearing the BA hat, I cannot make a decision regarding the scope of the project. That decision ultimately has to be made by the project sponsor (the common title for the individual in the organization who is funding the project). Mary is our project sponsor and the Department Manager of Order Entry. Her authority is limited to anything the Order Entry Department does. Based on her authority, I can now convert my initial diagram by following a few simple rules. First off, since ORDER ENTRY is in scope for my project, I need to change the noun ORDER ENTRY to a VERB/OBJECT to make it a legitimate function. What I look for is the primary function that ORDER ENTRY performs and Mary agrees that their primary function is to ENTER ORDERS.

By changing the name of the circle from the department ORDER ENTRY to the function ENTER ORDERS, I not only have a legitimate function, I also made a critical psychological shift. As the project progresses, I am going to analyze what happens inside the ENTER ORDERS process which will lead to the recognition that there are several problems with how the unit currently processes orders (that’s why the project was initiated).

If I leave the name of the object ORDER ENTRY, I would be accusing the department of making errors, which leads to pointing fingers and making accusations. This can result in a lot of pushback from the employees in the department as they feel unjustly criticized. Having changed the name from the department to the function, I can critically analyze the ENTER ORDERS function and find flaws in it. In this case, the same employees will join in enthusiastically because the problems are caused by the process and it is not their fault. This seemingly simple step can literally make or break the project.

Next, I convert all other circles on the diagram to squares to turn them into legitimate external entities to get to an almost legitimate DFD. The only remaining problem is that the diagram violates a simple but powerful rule of data flow diagramming, namely that flows between two external entities are logically out of scope (since both ends of the flow are out of scope).

To comply with that rule, I eliminate the Debit or Credit flow from CUSTOMER SERVICE to ACCOUNTING and the flow Response from CUSTOMER SERVICE to CUSTOMER /2. I can further ignore the Shipment flow from the WAREHOUSE to CUSTOMER /2, the Copy of Packing Slip from the WAREHOUSE to ACCOUNTING, and the Invoice flow from ACCOUNTING to CUSTOMER /2. After eliminating all of these out-of-scope flows, I see that the CUSTOMER /2 entity I had added to maintain the logical left-to-right, top-down flow is unnecessary since it is no longer involved in any data flows, so I can also delete it.

I now have a perfectly legitimate Context Level Data Flow Diagram (aka a “Context Diagram”, a “Level O (Zero) DFD”, or sometimes a “Level 1 DFD”) for the project. Note that every flow on the diagram either goes into or comes out of the one process on the diagram that is in scope, namely ENTER ORDERS. That is one of the hallmarks of a good Context Level DFD. Its primary reason for being is to manage the scope of the project. Assuming my diagram is an accurate representation of the situation, anything done during the ENTER ORDERS process is in scope and subject to change; everything else is out of scope for this project. If anyone starts to discuss problems with selecting the best shipping method for a shipment (based on the narrative this is done in the WAREHOUSE), I point to the diagram to show why that problem is irrelevant to the current scope of the project and therefore we should not spend project resources discussing it.

When I look at this diagram, I recognize a different problem. I am sending New Customer Orders to the CREDIT DEPARTMENT where according to the narrative they are ‘held until they clear a credit check’. That begs the question, ‘What happens to them once they have cleared the credit check?’ What does the CREDIT DEPARTMENT do with them? When I pose that question to my project sponsor, she explains that the CREDIT DEPARTMENT sends approved orders back to ORDER ENTRY, which ODER ENTRY has to continue processing the same as other orders from known customers with good credit. That fact causes me to add the flow Credit OK Orders from the CREDIT DEPARTMENT to the ENTER ORDERS process.

As a side note, it is not unusual to discover missing flows such as this once you start to work with the Context Level DFD. The earlier in the project that you can identify them, the cheaper it is to incorporate them into your project work. By the way, if you identified this issue while you were creating the original diagram and added this flow at that time, kudos, you are one step ahead of me.