Project resources are limited and the one wearing the BA hat has to decide how to get the best requirements in the allotted time. Understanding how people use existing technology to do their job is a critical prerequisite to defining changes. This KnowledgeKnugget™ explains why drawing and using a Data Flow Diagram (DFD) might be the best decision you can make. If you are responsible for eliciting the requirements for an IT application or for improving manual procedures, the Data Flow Diagram might just be your best ally. It helps you and the business community visualize the process, current problems, and potential solutions.

Understanding Workflows and Business Processes

This KnowledgeKnugget™ explains why you should draw a Data Flow Diagram, what a fully balanced DFD looks like, and what value a DFD fragment provides. These simple techniques will help you when you are the one wearing the BA hat.

From the perspective of the one wearing the BA hat, the act of creating a Data Flow Diagram (DFD) is an awakening. Drawing the diagram forces you to ask questions that you might otherwise overlook. It is also an awakening for members of the business community whose process you are depicting. The people in the trenches and those managing them quite often have never seen a picture of their process and a picture activates parts of the human brain that words cannot. As a result, the phrase, “I see” takes on a whole different meaning when you are presented with picture of your process. For that reason, I recommend drawing a DFD just to get everyone involved on the same page.

Once you have a DFD, exploding a process and balancing the data inputs and outputs between the levels often reveals missed data flows. After all, no one can think of everything at once. If the tool finds a single missed data flow, it is probably well worth the time it took to draw the diagram and apply the technique. The same is true of horizontal balancing to reveal missing data elements. If we asked IT to automate a process with a missing data flow or data elements, we most likely will end up with an application that does not meet the business needs.

IT professionals are generally extremely good at their job and they will most likely recognize that they are missing something at some point in the development process. The problem is the timing of the discovery and the related cost when the omission is discovered. Adding a missing process late in the project is a relatively simple step, but missing data often affects a multitude of processes, making it one of the most expensive errors for IT projects. The simple act of identifying data elements and ensuring their completeness allows you to recognize and resolve these issues before you involve the developers. In my experience, that is one of the most powerful arguments for spending time to develop and analyze a data flow diagram.

Start Your DFD with a Context Diagram (aka Level 0 Diagram)

A completely balanced or levelled data flow diagram starts at the top with a context diagram consisting of one or more processes that are in scope for your project and all external entities with which those processes exchange data.

… [end of excerpt]