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:

DFD in business analysis:

DFD in business process re-engineering:

DFD in agile development:

DFD in system structures:

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.