How to Build a Data Flow Diagram (DFD) | The Logic of Levelling and the Four Symbols
Published:
Last Updated:
Category: Campaign Management,
Published:
Last Updated:
Category: Campaign Management,
Authors: Shusaku Yosa
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.
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.
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.
A DFD has only four building blocks. The exact shapes vary between conventions, but the meanings are consistent.
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.
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.
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.
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 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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
A beginner-friendly guide to shinchoku (progress): its meaning in business, common phrases and example sentences, polite...
A beginner-friendly guide to the five reasons to-do lists never get finished and how to build one you can complete: sort...
A beginner's guide to to-do lists and how they differ from task lists. Covers a five-step way to use one, examples of cl...
