The Data Flow Diagram is commonly used also for the visualization of structured design data processing. The normal flow is represented graphically. A designer typically draws context level DFD first showing interaction between the system and the outside entities. Then this context level DFD will then be exploded in order to further show the details of system being modeled.

Larry Constantine invented the first data flow diagrams based on Martin and Estrin’s data flow graph model of computation.

A DFD is one of the three essential perspectives of Structured Systems Analysis and Design Method (SSADM). In this method, both the project sponsors and the end users need to collaborate closely throughout the whole stages of the evolution of the system. Having a DFD will make the collaboration easy because the end users will be able to visualize the operation of the system, the will see a better perspective what the system will accomplish and how the whole project will be implemented.

A project implementation can also be made more efficient especially in progress monitoring. The DFD of the old system can be laid side by side with the new system’s DFD so that comparisons can be made and weak points can be identified so that the appropriate innovations can be developed.

There are four components of a data flow diagram which are the following:

External Entities / Terminators – These refer or points to the outside parts of the system being developed or modeled. Terminators, depending on whether data flows into or from the system, are often called sinks or sources. They represent the information as wherever it comes from or where it goes.

Processes – The Processes component modifies the inputs and corresponding outputs.

Data Stores – refers to any place or area or storage where data will be placed whether temporarily or permanently.

Data Flows – refers to the way data will be transferred from one terminator to another, or through processes and data stores.

As a general rules, every page in a DFD should not contain more than 10 components. So, if there are more than 10 components in one processes, one or more components should have to be combined and then make another DFD to detail the combination in another page.

Each component needs to be number. Same goes for each subcomponent so that it will be easy to follow visually. For example, a top level DFD must have components numbered 1,2,3,4,5 and next level subcomponent (for instance of number 2) numbered 2.1, 2.2, 2.3 and so on.

There are two approaches to developing a DFD. The first approach is the Top Down Approach where a DFD starts with a context level DVD and then the system is slowly decomposed until the graphical detail goes down to a primitive level.

The other approach, Event Partitioning Approach, was described by Edward Yourdon in Just Enough Structured Analysis. In Event Partitioning Approach, a detailed DFD is constructed all events are made. For every event, a process is constructed and then each process is linked with other processes through data stores. Each process’ reaction to a given event is modeled by an outgoing data flow.

There many DFD tools available in the market today. Some of these DFD tools include Microsoft Visio, ConceptDraw, Dia, SmartDraw and SILVERRUN ModelSphere. Most of these tools have drag and drop capabilities and have analysis tools to help a designer see instant potential flaw in the diagram so correction can done immediately.