How to Build a Data Flow Diagram (DFD) | The Logic of Levelling and the Four Symbols

A DFD turns up in a system document and you cannot tell how it differs from a flowchart. Or you sit down to draw one and cannot decide how far to break things down. A DFD has only four symbols, but it comes with a distinctive idea called levelling. This article covers what the symbols mean and the rules that govern levelling.

What a DFD Is: A Diagram of How Data Moves

A DFD (data flow diagram) represents how data travels through a system. It shows where data comes in, what transforms it, where it is stored, and where it goes out.

The decisive difference from a flowchart is that a DFD has no concept of time. Where a flowchart expresses the sequence of "what happens next," a DFD expresses only the relationship of "where the data goes." Branches and loops are not drawn.

What it is used for

The main use is sharing a picture of the whole system among the people involved. It is particularly effective when replacing an existing system, or when connecting several systems together.

Questions like "where does this information come from?" and "why are we holding the same data in two places?" become visible once you draw a DFD. It is also an opportunity to notice duplicated data, or outputs nobody uses.

The Four Symbols

A DFD has only four building blocks. The exact shapes vary between conventions, but the meanings are consistent.

Process (circle or rounded rectangle)

Something that transforms data. Write it ending in a verb: "register the order," "calculate the invoice amount."

One rule matters here: a process always has both an input and an output. A process with input but no output, or output but no input, is a drawing error.

Data store (two parallel lines)

Where data is held. A database table, a file, a paper ledger. Drawn as a shape enclosed by lines above and below, or as a rectangle open on the right.

A data store does nothing by itself. Processes write to it and processes read from it. You cannot draw an arrow directly from one data store to another.

External entity (rectangle)

Someone or something outside the system that exchanges data with it. Customers, suppliers, other departments, external services.

Settling these is in fact the most important judgment in drawing a DFD, because how much you treat as your own system determines the scope of the diagram.

Data flow (arrow)

The direction data moves. Always label the arrow with what is flowing: "order data," "customer information," "stock count" — a noun.

An unlabelled arrow carries no meaning in a DFD. If you cannot write what is flowing, the arrow probably should not be there.

The Logic of Levelling

The defining feature of a DFD, and the part people find hardest. Rather than cramming everything onto one page, you expand progressively from a coarse diagram to finer ones.

Context diagram

The coarsest, first diagram. The entire system is drawn as a single process, with external entities arranged around it.

What it shows is only the system boundary: who exchanges data with it, what comes in and what goes out. Data stores are not drawn.

It is tempting to skip as too simple, but skipping it means entering the detail with the scope still undefined.

Level 0

The context diagram opened up. The single process is broken into the major functions. Data stores appear here for the first time.

Five to seven processes is the guide. Beyond ten it becomes hard to read; at three or fewer the decomposition adds little.

Level 1 and beyond

Each level 0 process opened further. Opening process 1 produces a level 1 diagram, and if needed you continue to level 2.

The test for how far to go is the point at which further decomposition stops being useful. In practice, most work stops at level 1 or 2.

The Balancing Rule

The most important rule in levelling. The data entering and leaving must match between the higher-level and lower-level diagrams.

Concretely: if process 1 at level 0 has three arrows entering and leaving it, the level 1 diagram that opens it must also have exactly those three arrows crossing its outer edge.

While drawing the lower-level diagram you sometimes realise a new data exchange is needed. When that happens, fix the higher-level diagram too. Fixing only one side is the classic reason a set of DFDs stops being trusted.

How to Build One

1. Settle the external entities: who exchanges data with the system. This defines the boundary.
2. List the data in and out: what arrives from each party and what goes back, written as nouns.
3. Draw the context diagram: everything above, on one page.
4. Break it into major functions: five to seven processes, with data stores placed.
5. Expand only where it is needed: there is no requirement to expand every process equally.

The fifth is the practical point. Expand the complex parts to level 2 and stop the simple parts at level 0. Trying to expand uniformly returns little for the effort.

Common Drawing Errors

• Connecting data stores directly: a process must sit between them. Data does not move on its own.
• Connecting external entities to each other: what happens outside the system is out of scope for this diagram.
• Drawing a process with no input: data does not appear from nothing.
• Drawing branches and conditions: a DFD has no notion of control. That is the flowchart's job.

The fourth is the most frequent. If you are used to flowcharts, the urge to draw a decision diamond is strong. In a DFD, a flow that varies by condition is simply drawn as multiple arrows.

Frequently Asked Questions

How does it differ from a flowchart in use?

They answer different questions. To organise where data lives and how it moves, use a DFD. To show the order of work and its branches, use a flowchart. In system development it is not unusual to produce both.

How does it relate to an ER diagram?

They complement each other. An ER diagram shows the structure of the data; a DFD shows how that data moves. A DFD's data stores often correspond to an ER diagram's entities.

Should the client understand it too?

You do not need to draw one, but reading one is useful. The context diagram in particular works well as a document for confirming system scope. Noticing that an exchange with a particular party is missing is something only the client side can do.

Can you draw one with no existing system?

Yes. For a new build, you draw the DFD of the intended state. Where an existing system is being replaced, producing both a current-state and a future-state DFD and comparing the difference is an effective approach.

The Work That Remains After the Diagram

A DFD shows only the structure of data movement. It cannot show by when, or by whom, that structure gets implemented. Once the design settles, the remaining work is turning it into dates and owners.

Xtrategy manages campaign schedules alongside budget and KPIs on a single screen.

Summary

• A DFD shows how data moves. Unlike a flowchart, it has no notion of time or branching.
• Four symbols: process, data store, external entity, data flow.
• Start with the context diagram, then expand to level 0 and level 1.
• The data crossing the boundary must match between levels.
• Do not expand every process equally; go deep only where it is complex.
• Never connect two data stores, or two external entities, directly.

A DFD has few symbols and little to memorise. What feels difficult is the levelling, but that too is simple once you think of it as starting coarse and opening only what needs opening. Begin by listing the external entities and drawing a single context diagram.