what is dfd diagram?

So many moving parts go into an organization’s day-to-day systems and operations—each as crucial to the success of a business or project as the next. Without the proper tools and techniques, it can be difficult to keep track of all the important details these complex schemes entail. This is where a data flow diagram or DFD comes in.

We’ve put together a crash course to help you master this powerful management tool so you can apply it to your own plans and strategies. From the different kinds of diagrams to their layouts, symbols, and functions—this short guide will take you through it all so you can quickly make your own in no time.

You can create your own DFDs with Venngage’s diagram maker, even without diagramming experience., Our customizable templates are made by experts for non-designers.

A data flow diagram is a visualization tool used to illustrate the flow of processes in a company or a specific project within it. It highlights the movement of information as well as the sequence of steps or events required to complete a work task.

DFDs can vary in design and complexity, depending on the process it represents. It can be a simple outline of a general system or a more granular sketch of a multi-level procedure, such as the example below.

By visually dissecting these otherwise abstract concepts, DFDs allow teams and managers to better comprehend how a system works as well as identify and troubleshoot potential problems to improve effectiveness.

Return to Table of Contents

A data flow diagram is typically organized hierarchically, showing the entire system at one level, followed by major subsystems at the next. Finally, details are shown for each primary subsystem, with components identified last.

Here’s an example, which details the flow of customer data through the different layers of a business transaction.

Each of the diagram’s elements is assigned a specific shape or symbol to stress its role in the process. More on those symbols later.

The data flow diagram process comprises four main components:

A data flow diagram makes use of standardized symbols to represent the different components and functions that make a system or process.

There are four common symbol conventions in data flow diagramming.

You can select any of these conventions for your DFDs, just bear in mind to be clear and consistent with the shapes you use. Additionally, if you need to include more details about each process, you can make use of bubble charts to break these down.

Now that you’re familiar with the key components and symbols used in data flow diagrams, it’s time to look at how to arrange these elements into one cohesive layout.

As DFDs represent a chronological process, their parts are generally organized from top to bottom, left to right. Here’s a quick sketch to give you a better idea of the order of elements in a DFD:

External entity → Data inputs → Process → Data outputs → Data storage → External entity

This illustrates how an external entity feeds the data or information that goes through a process that transforms it into output. Unless used immediately, the output can go through data storage, where it is kept until needed.

A real-life example of this would be a food establishment’s customer reservations system, such as the example below.

The guest (external entity) enters their booking request into the system (data input) which then runs a process to find the guest a table on their preferred schedule (data output).

The system can be programmed to retain the guest’s information in a database (data storage) for easy access next time the same guest books a table at the establishment. Meantime, the guest (external entity) receives the details of their current reservation (data output).

Some processes can also be represented in values or percentages to show the amount of a product or service that can be delivered within a given period of time. For instance, in the example above, the reservations system can display the volume of guests expected on a given date so the host can make informed recommendations to the guest.

Return to Table of Contents

There are two types of data flow diagrams: logical data flow diagram (LFD) and physical data flow diagram (PFD).

A logical DFD shows the conceptual flow of information through a process, focusing on the kind of data needed, its source, destination, and the transformation desired from the process. Here’s an example.

This type of DFD is often used in the early stages of system or process design when requirements are being determined. In the world of information systems design, this is where developers conduct a structured systems analysis.

On the other hand, a physical DFD visualizes how the system plan will be executed, including the specific tools, hardware, or players needed to make it work. Just like this example.

In information systems design, physical DFDs show how a system works after its requirements has been finalized and moved into full production.

Return to Table of Contents

Data flow diagrams can be used to document and analyze processes and systems in both virtual and real-life settings. In software engineering, where DFDs first came to be known, they can provide thorough technical guidance prior to encoding digital programs or applications.

Meanwhile, in business and project management, they can help managers and their teams master internal or external processes upon which the success of projects or the satisfaction of customers depend.

In both cases, DFDs can point out potential problems or bottlenecks by virtue of breaking down complex procedures and uncovering every last detail that goes into them. By doing so, DFDs ensure the effectiveness of a plan or strategy.

Here are some examples used for specific purposes:

These DFDs show the flow of information through the frames of an application. It visualizes how a user moves through an application such as a POS system or an e-commerce portal based on the data they input and the process this data goes through until output is delivered.

This diagram can be used when application requirements are determined during application design.

The sample DFD below details the process a shopper might take when shopping via a supermarket’s mobile app.

These DFDs illustrate how work is done on inputs to produce an output. To depict this transformation, the elements in a system DFD are connected to show what happens to data and where it goes when a specific action is performed upon it.

For example, this system DFD for an automobile’s cruise control program shows how the program responds when a user decides (action) to go fast or slow.

These DFDs map out the flow of information from data storage through a process towards an endpoint, like a user or a customer, just as in the example below.

This type of diagram does not illustrate external controls or decisions. As such, it is typically used when application or system requirements have been ironed out, performance bottlenecks are determined and addressed, or system interfaces and logic are combined into one process.

User interface flow diagrams illustrate how users navigate a system or the actual process a user takes to complete a task. Take a look at this example.

This type of DFD is particularly helpful during the early stages of system or application design, when the intended user experience is being mapped out and fine-tuned.

Return to Table of Contents

Now combine everything you know so far about data flow diagrams, their symbols, components, and layouts to make your own. Here are some steps to help simplify and guide you through the task:

Step zero is, of course, determining the system or process you want to analyze. Once you’ve identified that, you must deliberate and plan the outcomes you want to accomplish through this visualization exercise.

Is it to find a possible cause for bottlenecks in your implementation? To refine your internal processes? Or simply to help your team members to better understand how things work?

Identify which elements of your chosen methodology are your external entities, data inputs and outputs, data storage, and process steps.

One way to go about it is to locate the major inputs and outputs of your process, which will give you a good overview of your system and what you want to achieve. From there, you can easily fill the space between.

A context diagram is a level 0 DFD. It’s basically an outline of a high-level scheme. It’s designed to be straightforward, depicting a single process.

Here is an example.

To create one, connect your major inputs and outputs to your external entities. This illustrates the most general path data goes through from input to output.

You’ll need to break down your context diagram to reveal the details of your main systems. A level 1, 2, or 3 DFD will do just that—take the example below.

To do this, simply add and connect elements to your subprocesses and -systems. Do it one tier or section at a time, making sure to add more data storage and flows when and where necessary.

Once you’ve mapped out every detail, you must make sure your final diagram is accurate and correct. Proofread it by walking through each level and each step, paying close attention to the movement of information. Validate that the data flow makes sense and that you have all the necessary components where you need them to be.

Make sure your diagram can be easily understood by external parties, too. You can do this by running your DFD by a colleague or team member to check if they are able to comprehend the process and data transformation you wish to illustrate through it.

Return to Table of Contents

Let’s take a look at some DFD examples and how they can be used across businesses.

This diagram uses the Gane and Sarson symbol system to create a clear hierarchy and distinction among its components. The variety and organized use of figures make it easy for those reading or using this diagram to identify the data inputs, outputs, storage, and process.

In the next example, elements are arranged from left to right, creating a clean visual that’s easy to read and understand.

Colors can also enhance the look of your DFD. Assign specific shades to each component to drive home the significance of their roles in the process or system.

Return to Table of Contents

Businesses require a whole universe of systems and processes to be effective. These, in turn, must be managed properly in order to achieve their intended outputs and objectives.

Data flow diagrams can help business managers and teams competently carry out plans and accomplish tasks by providing a straightforward yet engaging visual guide on multi-level—and otherwise complicated—methodologies. They’re also easy on the eyes.

DFDs can also help teams identify potential obstacles that can cause a project or program to perform poorly or, worse, fail to meet expectations. By addressing these kinks in data flows, organizations can efficiently reduce costs and improve overall productivity.

Additionally, flow diagrams can help executives with external audits and assist organizations when it comes to obtaining and maintaining ISO certifications.

Return to Table of Contents

A data flow diagram comprises four essential components: external entities, process, data flow, and data storage. It makes use of standardized symbols (i.e. shapes and figures) to denote the role of each of these elements in a given system or process.

A data flow diagram details the process by which data flows and transforms through a system. Meanwhile, a flowchart illustrates a sequence of steps that must be taken to accomplish a task or solve a problem.

Return to Table of Contents

A data flow diagram is a powerful tool that companies can use to ensure the effective implementation of a system or process.

By providing a visual representation of the methodologies involved in a business process, it can help managers and their teams develop a deeper, more comprehensive grasp of the strategies and techniques necessary to make a project succeed.

Don’t miss out on these benefits and create your own data flow diagrams today. Sign up for an account on Venngage (it’s free!) and gain access to a whole library of diagram templates you can easily customize with the site’s drag-and-drop editor. No design experience required.

We also invite you to upgrade to a Venngage business account to access My Brand Kit, which lets you add your company’s logo, color palette, and fonts to all your designs with a single click.

A data-flow diagram is a way of representing a flow of data through a process or a system (usually an information system). The DFD also provides information about the outputs and inputs of each entity and the process itself. A data-flow diagram has no control flow — there are no decision rules and no loops. Specific operations based on the data can be represented by a flowchart.[1]

There are several notations for displaying data-flow diagrams. The notation presented above was described in 1979 by Tom DeMarco as part of structured analysis.

For each data flow, at least one of the endpoints (source and / or destination) must exist in a process. The refined representation of a process can be done in another data-flow diagram, which subdivides this process into sub-processes.

The data-flow diagram is a tool that is part of structured analysis and data modeling. When using UML, the activity diagram typically takes over the role of the data-flow diagram. A special form of data-flow plan is a site-oriented data-flow plan.

Data-flow diagrams can be regarded as inverted Petri nets, because places in such networks correspond to the semantics of data memories. Analogously, the semantics of transitions from Petri nets and data flows and functions from data-flow diagrams should be considered equivalent.

The DFD notation draws on graph theory, originally used in operational research to model workflow in organizations. DFD originated from the activity diagram used in the structured analysis and design technique methodology at the end of the 1970s. DFD popularizers include Edward Yourdon, Larry Constantine, Tom DeMarco, Chris Gane and Trish Sarson.[2]

Data-flow diagrams (DFD) quickly became a popular way to visualize the major steps and data involved in software-system processes. DFDs were usually used to show data flow in a computer system, although they could in theory be applied to business process modeling. DFDs were useful to document the major data flows or to explore a new high-level design in terms of data flow.[3]

DFD consists of processes, flows, warehouses, and terminators. There are several ways to view these DFD components.[4]

Process

The process (function, transformation) is part of a system that transforms inputs to outputs. The symbol of a process is a circle, an oval, a rectangle or a rectangle with rounded corners (according to the type of notation). The process is named in one word, a short sentence, or a phrase that is clearly to express its essence.[2]

Data flow

Data flow (flow, dataflow) shows the transfer of information (sometimes also material) from one part of the system to another. The symbol of the flow is the arrow. The flow should have a name that determines what information (or what material) is being moved. Exceptions are flows where it is clear what information is transferred through the entities that are linked to these flows. Material shifts are modeled in systems that are not merely informative. Flow should only transmit one type of information (material). The arrow shows the flow direction (it can also be bi-directional if the information to/from the entity is logically dependent – e.g. question and answer). Flows link processes, warehouses and terminators.[2]

Warehouse

The warehouse (datastore, data store, file, database) is used to store data for later use. The symbol of the store is two horizontal lines, the other way of view is shown in the DFD Notation. The name of the warehouse is a plural noun (e.g. orders) – it derives from the input and output streams of the warehouse. The warehouse does not have to be just a data file but can also be, for example, a folder with documents, a filing cabinet, or a set of optical discs. Therefore, viewing the warehouse in a DFD is independent of implementation. The flow from the warehouse usually represents reading of the data stored in the warehouse, and the flow to the warehouse usually expresses data entry or updating (sometimes also deleting data). The warehouse is represented by two parallel lines between which the memory name is located (it can be modeled as a UML buffer node).[2]

Terminator

The Terminator is an external entity that communicates with the system and stands outside of the system. It can be, for example, various organizations (eg a bank), groups of people (e.g. customers), authorities (e.g. a tax office) or a department (e.g. a human-resources department) of the same organization, which does not belong to the model system. The terminator may be another system with which the modeled system communicates.[2]

Entity names should be comprehensible without further comments. DFD is a system created by analysts based on interviews with system users. It is determined for system developers, on one hand, project contractor on the other, so the entity names should be adapted for model domain or amateur users or professionals. Entity names should be general (independent, e.g. specific individuals carrying out the activity), but should clearly specify the entity. Processes should be numbered for easier mapping and referral to specific processes. The numbering is random, however, it is necessary to maintain consistency across all DFD levels (see DFD Hierarchy). DFD should be clear, as the maximum number of processes in one DFD is recommended to be from 6 to 9, minimum is 3 processes in one DFD.[1][2] The exception is the so-called contextual diagram where the only process symbolizes the model system and all terminators with which the system communicates.

DFD must be consistent with other models of the system – entity relationship diagram, state-transition diagram, data dictionary, and process specification models. Each process must have its name, inputs and outputs. Each flow should have its name (exception see Flow). Each Data store must have input and output flow. Input and output flows do not have to be displayed in one DFD – but they must exist in another DFD describing the same system. An exception is warehouse standing outside the system (external storage) with which the system communicates.[2]

To make the DFD more transparent (i.e. not too many processes), multi-level DFDs can be created. DFDs that are at a higher level are less detailed (aggregate more detailed DFD at lower levels). The contextual DFD is the highest in the hierarchy (see DFD Creation Rules). The so-called zero level is followed by DFD 0, starting with process numbering (e.g., process 1, process 2). In the next, the so-called first level – DFD 1 – the numbering continues. E.g. process 1 is divided into the first three levels of the DFD, which are numbered 1.1, 1.2 and 1.3. Similarly, processes in the second level (DFD 2) are numbered eg 2.1.1, 2.1.2, 2.1.3 and 2.1.4. The number of levels depends on the size of the model system. DFD 0 processes may not have the same number of decomposition levels. DFD 0 contains the most important (aggregated) system functions. The lowest level should include processes that make it possible to create a process specification for roughly one A4 page. If the mini-specification should be longer, it is appropriate to create an additional level for the process where it will be decomposed into multiple processes. For a clear overview of the entire DFD hierarchy, a vertical (cross-sectional) diagram can be created. The warehouse is displayed at the highest level where it is first used and at every lower level as well.[2]

But implementing a process into a business, department, or even a team is a completely different animal than honing your own personal process. With so many moving parts, how do you track each aspect of your business' process and how do you refine it?

Data flow diagrams provide a straightforward, efficient way for organizations to understand, perfect, and implement new processes or systems. They’re visual representations of your process or system, so they make it easy to understand and prune.

Before we dive into how data flow diagrams can help refine any of your business’ systems or processes, let’s go over what it exactly is.

Image Source

DFDs became popular in the 1970s and have maintained their widespread use by being easy to understand. Visually displaying how a process or system works can hold people’s attention and explain complex concepts better than blocks of text can, so DFDs are able to help almost anyone grasp a system’s or process’ logic and functions.

There are two types of DFDs — logical and physical. Logical diagrams display the theoretical process of moving information through a system, like where the data comes from, where it goes, how it changes, and where it ends up.

Physical diagrams show you the practical process of moving information through a system, like how your system’s specific software, hardware, files, employees, and customers influences its flow of information.

You can either use logical or physical diagrams to describe the same flow of information or you can use them in conjunction to understand a process or system on a more granular level. But, before you can use a DFD to understand your system or process’ flow of information, you need to know the standard notations or symbols used to describe it.

Data Flow Diagram symbols are standardized notations, like rectangles, circles, arrows, and short-text labels, that describe a system or process’ data flow direction, data inputs, data outputs, data storage points, and its various sub-processes.

There are four common methods of notation used in DFDs: Yourdon & De Marco, Gene & Sarson, SSADM and Unified. All use the same labels and similar shapes to represent the four main elements of a DFD — external entity, process, data store, and data flow.

Image Source

An external entity, which are also known as terminators, sources, sinks, or actors, are an outside system or process that sends or receives data to and from the diagrammed system. They’re either the sources or destinations of information, so they’re usually placed on the diagram’s edges. External entity symbols are similar across models except for Unified, which uses a stick-figure drawing instead of a rectangle, circle, or square.

Process is a procedure that manipulates the data and its flow by taking incoming data, changing it, and producing an output with it. A process can do this by performing computations and using logic to sort the data, or change its flow of direction. Processes usually start from the top left of the DFD and finish on the bottom right of the diagram.

Data stores hold information for later use, like a file of documents that’s waiting to be processed. Data inputs flow through a process and then through a data store while data outputs flow out of a data store and then through a process.

Data flow is the path the system’s information takes from external entities through processes and data stores. With arrows and succinct labels, the DFD can show you the direction of the data flow.

Before you start mapping out data flow diagrams you need to follow four best practices to create a valid DFD.

1. Each process should have at least one input and one output.

2. Each data store should have at least one data flow in and data flow out.

3. A system’s stored data must go through a process.

4. All processes in a DFD must link to another process or data store.

DFDs can range from simple overviews to complex, granular representations of a system or process with multiple levels, starting with level 0. The most common and intuitive DFDs are level 0 DFDs, also called context diagrams. They’re digestible, high-level overviews of the flow of information through a system or process, so almost anyone can understand it.

This DFD level focuses on high-level system processes or functions and the data sources that flow to or from them. Level 0 diagrams are designed to be simple, straightforward overviews of a process or system.

While level 1 DFDs are still broad overviews of a system or process, they’re also more detailed — they break down the system’s single process node into subprocesses.

The next level of DFDs dive even deeper into detail by breaking down each level 1 process into granular subprocesses.

Level 3 and higher-numbered DFDs are uncommon. This is largely due to the amount of detail required, which defeats its original purpose of being easy to understand.

Professionals in various industries, like software engineering, IT, ecommerce, and product management & design, can use DFDs to better understand, refine, or implement a new system or process.

But what does a data flow diagram look like in practice — and how does it help your business? Here are three examples to help contextualize DFD impact.

Image Source

This Level 0 DFD provides a contextual map of a securities trading platform. Data flows in one direction from the customer service assistant and the broker to the platform, and in two directions from customers to the platform and back again.

Image Source

This Level 1 DFD breaks down the customer process in more detail, expanding it to include account creation, cash withdrawals, and eventual securities transactions.

Image Source

This Level 2 DFD decomposes the “Place Order” process to contextualize the steps required to place an order — either by a customer or by a broker. It even accounts for a third-party stock exchange center where transaction details are forwarded after an order is placed.

Begin by selecting a specific system or process you want to analyze. While any system or process can be turned into a DFD, the larger the process the more complicated the diagram and the more difficult it will be to contextualize. Wherever possible, start with a small function or process you’re looking to improve.

Next, categorize all activities related to this process into external entities, data flows, processes, and data stores.

Consider a restaurant food ordering system. Customers are external entities, the food ordering system is a process, and the interaction between customers and the system (which goes in both directions) is the flow.

Also worth noting? The ordering system doubles as a data store, so for an SSADA model, this means drawing it as a rectangle with rounded corners with two horizontal lines inside to represent its dual function.

Now it’s time to start drawing. DFDs can be created by hand, using free templates available online, or via browser extensions.

Begin with a simple, Level 0 DFD: Start with your process or system, then map all basic connections and flows.

Before diving into more complex DFDs, check the work you’ve already done to make sure it’s accurate and complete. If you’ve missed (or added) a process, entity, or flow, your next-level DFDs may not make sense and you may be forced to start over.

For each process or system described in your Level 0 DFD, create a new child diagram with its own entities and flows. Eventually, you can use these child diagrams to connect processes together.

Using your child diagrams, you should map more in-depth connections between each process. In the case of our restaurant example, this could mean digging deeper into the food ordering system and its connection to suppliers, managers, customers, and kitchen staff.

Each process — no matter how large or small — can be reimagined as a Level 0 context diagram and the cycle can begin again. Repeat these steps as needed to create as many DFDs as required, or break processes down further to develop Level 2, 3, etc. DFDs.

While there’s no such thing as a “perfect” data flow diagram, continued practice can help streamline the process and offer critical insight into what’s working, what isn’t and where your business can make improvements that offer the biggest impact.

Your best bet? Remember the rule: Keep it simple. Start with context, build out connected processes, and repeat as needed to map key connections, flows, and entities across your organization.

• Example of Logical vs. Physical DFDs.
• Using Logical vs. Physical DFDs.
• Level 0 DFDs: What are Context Diagrams?
• Level 1 DFDs.
• Level 2 DFDs and Adding Higher Levels.
• Using Layers for DFD Levels.