What is a Data Flow Diagram (DFD) and How to Create One

A data flow diagram (DFD) maps out the flow of information for any process or system. It uses defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs, outputs, storage points and the routes between each destination. Data flowcharts can range from simple, even hand-drawn process overviews, to in-depth, multi-level DFDs that dig progressively deeper into how the data is handled. They can be used to analyze an existing system or model a new one. Like all the best diagrams and charts, a DFD can often visually “say” things that would be hard to explain in words, and they work for both technical and nontechnical audiences, from developer to CEO. That’s why DFDs remain so popular after all these years. While they work well for data flow software and systems, they are less applicable nowadays to visualizing interactive, real-time or database-oriented software or systems.

The most common systems of symbols are named after their creators:

• Yourdon and Coad
• Yourdon and DeMarco
• Gane and Sarson

One main difference in their symbols is that Yourdon-Coad and Yourdon-DeMarco use circles for processes, while Gane and Sarson use rectangles with rounded corners, sometimes called lozenges. There are other symbol variations in use as well, so the important thing to keep in mind is to be clear and consistent in the shapes and notations you use to communicate and collaborate with others.

Using any convention’s DFD rules or guidelines, the symbols depict the four components of data flow diagrams.

1. External entity:

   an outside system that sends or receives data, communicating with the system being diagrammed. They are the sources and destinations of information entering or leaving the system. They might be an outside organization or person, a computer system or a business system. They are also known as terminators, sources and sinks or actors. They are typically drawn on the edges of the diagram.

2. Process:

   any process that changes the data, producing an output. It might perform computations, or sort data based on logic, or direct the data flow based on business rules. A short label is used to describe the process, such as “Submit payment.”

3. Data store:

   files or repositories that hold information for later use, such as a database table or a membership form. Each data store receives a simple label, such as “Orders.”

4. Data flow:

   the route that data takes between the external entities, processes and data stores. It portrays the interface between the other components and is shown with arrows, typically labeled with a short data name, like “Billing details.”

• Each process should have at least one input and an output.
• Each data store should have at least one data flow in and one data flow out.
• Data stored in a system must go through a process.
• All processes in a DFD go to another process or a data store.

A data flow diagram can dive into progressively more detail by using levels and layers, zeroing in on a particular piece.  DFD levels are numbered 0, 1 or 2, and occasionally go to even Level 3 or beyond. The necessary level of detail depends on the scope of what you are trying to accomplish.

• DFD Level 0 is also called a Context Diagram. It’s a basic overview of the whole system or process being analyzed or modeled. It’s designed to be an at-a-glance view, showing the system as a single high-level process, with its relationship to external entities. It should be easily understood by a wide audience, including stakeholders, business analysts, data analysts and developers. 

• DFD Level 1 provides a more detailed breakout of pieces of the Context Level Diagram. You will highlight the main functions carried out by the system, as you break down the high-level process of the Context Diagram into its subprocesses. 

• DFD Level 2 then goes one step deeper into parts of Level 1. It may require more text to reach the necessary level of detail about the system’s functioning. 

​

• Progression to Levels 3, 4 and beyond is possible, but going beyond Level 3 is uncommon. Doing so can create complexity that makes it difficult to communicate, compare or model effectively.

Using DFD layers, the cascading levels can be nested directly in the diagram, providing a cleaner look with easy access to the deeper dive.

By becoming sufficiently detailed in the DFD, developers and designers can use it to write pseudocode, which is a combination of English and the coding language.  Pseudocode facilitates the development of the actual code.

Data flow diagrams are well suited for analysis or modeling of various types of systems in different fields.

DFD in software engineering: This is where data flow diagrams got their main start in the 1970s. DFDs can provide a focused approached to technical development, in which more research is done up front to get to coding.

DFD in business analysis: Business analysts use DFDs to analyze existing systems and find inefficiencies. Diagramming the process can uncover steps that might otherwise be missed or not fully understood.

DFD in business process re-engineering:  DFDs can be used to model a better, more efficient flow of data through a business process. BPR was pioneered in the 1990s to help organizations cut operational costs, improve customer service and better compete in the market.

DFD in agile development: DFDs can be used to visualize and understand business and technical requirements and plan the next steps. They can be a simple yet powerful tool for communication and collaboration to focus rapid development.

DFD in system structures: Any system or process can be analyzed in progressive detail to improve it, on both a technical and non-technical basis.

While a DFD illustrates how data flows through a system, UML is a modeling language used in Object Oriented Software Design to provide a more detailed view. A DFD may still provide a good starting point, but when actually developing the system, developers may turn to UML diagrams such as class diagrams and structure diagrams to achieve the required specificity.

These are the two categories of a data flow diagram.  A Logical DFD visualizes the data flow that is essential for a business to operate. It focuses on the business and the information needed, not on how the system works or is proposed to work. However, a Physical DFD shows how the system is actually implemented now, or how it will be. For example, in a Logical DFD, the processes would be business activities, while in a Physical DFD, the processes would be programs and manual procedures.

Want to know more? See our deeper look into Logical DFDs vs. Physical DFDs.

1. Identify major inputs and outputs in your system 

Nearly every process or system begins with input from an external entity and ends with the output of data to another entity or database. Identifying such inputs and outputs gives a macro view of your system—it shows the broadest tasks the system should achieve. The rest of your DFD will be built on these elements, so it is crucial to know them early on.

2. Build a context diagram

Once you’ve identified the major inputs and outputs, building a context diagram is simple. Draw a single process node and connect it to related external entities. This node represents the most general process information undergoes to go from input to output. 

The example below shows how information flows between various entities via an online community. Data flows to and from the external entities, representing both input and output. The center node, “online community,” is the general process. 

3. Expand the context diagram into a level 1 DFD

The single process node of your context diagram doesn’t provide much information—you need to break it down into subprocesses. In your level 1 data flow diagram, you should include several process nodes, major databases, and all external entities. Walk through the flow of information: where does the information start and what needs to happen to it before each data store?

4. Expand to a level 2+ DFD

To enhance the detail of your data flow diagram, follow the same process as in step 3. The processes in your level 1 DFD can be broken down into more specific subprocesses. Once again, ensure you add any necessary data stores and flows—at this point you should have a fairly detailed breakdown of your system. To progress beyond a level 2 data flow diagram, simply repeat this process. Stop once you’ve reached a satisfactory level of detail.

5. Confirm the accuracy of your final diagram

When your diagram is completely drawn, walk through it. Pay close attention to the flow of information: does it make sense? Are all necessary data stores included? By looking at your final diagram, other parties should be able to understand the way your system functions. Before presenting your final diagram, check with co-workers to ensure your diagram is comprehensible.

Data Flow Diagram (Logical) Example

This particular DFD is a logical DFD, which focuses on the business and the information needed, not on how the system works or is proposed to work (which is what a physical DFD does). For example, in a logical DFD, the processes would be business activities.

Data Flow Diagram (Physical) Example

This particular DFD is a physical DFD, which shows how the system is currently (or will be) implemented. For example, in a logical DFD, the processes would be programs and manual procedures rather than business events, which is what a logical DFD focuses on. 

Context Diagram Example

This particular DFD is a context diagram, a basic, high-level overview of the whole system or process. It should be easily understood by a wide audience, including stakeholders and developers.