A Beginner's Guide to Data Flow Diagrams

Image Source

DFDs became popular in the 1970s and have maintained their widespread use by being easy to understand.

There are two types of DFDs — logical and physical.

Logical DFD

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 DFD

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

You can either use logical or physical diagrams to describe that flow of information. You can also use them in conjunction to understand a process or system on a more granular level.

Data Flow Diagram vs. Unified Modeling Language (UML)

While these two types of diagrams have some similarities, let me clarify what makes each distinct.

Data flow diagrams are designed to provide a map for how your data will flow through a system. Unified Modeling Language (UML) takes it further, providing considerably more detail.

DFDs and UML are not mutually exclusive — you might use a DFD for people who need a high-level summary and then turn your DFD into UML diagrams when it comes time to actually create your system, providing sufficient detail for developers who need to know how to create the specifics.

To continue the roadmap analogy, DFD might provide the top-level overview and potentially even turn-by-turn directions, but UML offers the street-level view with all the context of building color, tree location, and traffic patterns.

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.

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 and two horizontal lines inside to represent its dual function.

4. Draw a context DFD.

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

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

5. Check your work.

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. Trust me, it’s worth double-checking your work after each step.

6. Create child diagrams.

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.

7. Expand processes into Level 1 DFDs.

Using your child diagrams, you can map more in-depth connections between each process. I find starting with the big picture, then systematically digging into the details ensures I don’t have any missing gaps.

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.

8. Repeat as needed.

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.

Data Flow Diagram Tips

When I created a new retainer service for clients that blended marketing strategy with copywriting and tactical support, I needed a way to create a system that would help me manage all the projects while also automating the time-consuming aspects.

Since it is not a typical large-scale copywriting aspect with defined deliverables, I knew there would be more moving parts to manage and that I wouldn’t want to do it manually. So, I created a DFD to help me get clear on how the process would work. Here’s what I learned along the way.

1. Choose a platform you like.

Sure, you can draw a diagram out by hand (and you may want to start there), but my best advice is to choose software you’re somewhat familiar with.

My go-to choices are Canva and Miro because their whiteboards expand in any direction and make it easy to edit or update.

Miro has a bit more functionality with different types of fields and back-end notes, but my comfort level is highest in Canva.

2. Start at the beginning.

Because it’s important to understand every aspect of the process you’re defining.

In my case, the sales would already be complete, so my first action is to get clients into the system for onboarding.

3. Define your current process.

Start with the basics. How do things currently work? Or, if you’re defining a new process like I was, start with the minimum viable actions.

Why? I’ve found there’s nothing worse than an overcomplicated process that requires too much work or too many manual actions.

My initial DFD started with how I define and set up projects, how I manage the initial work, and how to do revisions — aka the basics.

4. Identify next-level updates or changes.

Once you define your current process, you can use your DFD to show opportunities for improvement.

Personally, manual emails and updates can be overwhelming. These elements are where I’m most likely to drop the occasional ball, so I identified opportunities for automation, specifically around notifications.

You can see in the purple items above where I noted opportunities for improvement and set up some preliminary automation in my project management software (ClickUp).

5. Test and update.

Now that you’ve dialed in your process and changes (and hopefully, put it into action), it’s time to see how it all works. Where are there holes? What is missing? What could be working better?

I found creating and setting up documents to be incredibly time-consuming, so I added in an automation to create them for me using a blend of ClickUp, Google Docs, and Zapier.

Keep in mind as your business, technology, and market changes, there will be new updates to your process. Your DFD is never 100% complete.

6. Identify ancillary processes.

In addition to the processes you outline in your DFD, you may uncover areas where you need to go deeper. For example, in the DFD I shared above, there are additional processes that I can define and potentially streamline:

• Sales
• Contracting
• Onboarding

And while my DFD covers that after a project is complete, the process starts over. There are additional client touchpoints that aren’t related to the actual project management.

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.