The Benefits of Data Flow Diagrams

DFDs are visual representations that can help almost anyone grasp a system’s or process’s logic and functions. Aside from being accessible, I find they provide much-needed clarity and improve productivity. Here’s how.

Accessibility

Because visual information is easier to digest, DFDs typically explain complex concepts better than blocks of text can.

Visual presentations of how a process works can also hold people’s attention longer — making it easier to retain the information.

Clarity

DFDs clarify the systems and processes necessary for your team to do their best work. Whether implementing a new company-wide system or refining a department’s existing process, a DFD gets you and your team on the same page.

Creating DFDs will give you clarity about business operations, too. I think a clearer understanding enables you to refine and track your business processes with less friction.

Productivity

The accessibility and clarity created with DFDs will leave less room for error. Your team will better master systems and processes because they understand them.

Greater understanding — paired with a repeatable process — will likely boost team effectiveness and productivity.

On a broader level, DFDs can help you streamline your business operations. When mapping out your processes, you’ll gain insights into what does and doesn’t work.

These insights help boost you and your team’s productivity. As a bonus, you can share any best practices across departments.

Data Flow Diagram Symbols

Before using a DFD, let me share the symbols you need to describe it.

Data flow diagram symbols are standardized notations, like rectangles, circles, arrows, and short-text labels. These symbols represent a system’s data flow direction, inputs, outputs, storage points, and sub-processes.

Four common methods of notation are 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 — so I’ll focus on explaining those, regardless of which notation method you choose.

1. External Entity

External entities — which are also known as terminators, sources, sinks, or actors — are outside systems that send or receive 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.

2. Process

Process is a procedure that manipulates the data and its flow by taking incoming data, changing it, and producing an output. 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.

3. Data Store

Data stores hold information for later use, like a file of documents 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.

4. Data Flow

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.

DFD Levels

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.

On the other extreme, level 3+ diagrams contain lots of detail and complexity.

Level 0: Context Diagram

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.

Level 1: Process Decomposition

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.

Level 2: Deeper Dives

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

Level 3: Increasing Complexity

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.

Data Flow Diagram Examples

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? I’ll share three examples to help you contextualize DFDs’ impact.

1. Level 0 DFD

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. It also flows in two directions from customers to the platform and back again.

As you can see, it is exceedingly simple and straightforward.

2. Level 1 DFD

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

As you can see, it breaks down the customer interactions into more specific actions, allowing viewers to grasp what the whole process looks like.

3. Level 2 DFD

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. This provides a more granular depiction of a specific process.

1. Know the basics.

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.

2. Select a system or process.

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, I recommend starting with a small function or process you’re looking to improve.

3. Categorize related business activities.

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

Data Flow Diagram Tips

Perfecting Your Process

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 impactful improvements.

My example is considerably simple compared with DFDs I’ve created for much larger clients as we define their marketing and reporting processes to create systems where things don’t fall through the cracks.

After all, the more moving parts, the more important it is to dial in your processes so nothing gets dropped or missed.

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.

Editor’s note: This post was originally published in September 2018 and has been updated for comprehensiveness.