What is a data flow diagram?

A data flow diagram (DFD) models how data moves through a system. It uses four element types — external entities, processes, data stores, and data flows — to show where information comes from, how it is transformed, and where it is stored, without describing control logic or timing.

What do the four DFD element types mean?

External entities are sources or sinks of data outside the system (users, other systems). Processes transform incoming data into outgoing data. Data stores are repositories like databases or files. Data flows are the labelled arrows that carry data between the others.

What is the difference between DFD levels?

A level-0 (context) diagram shows the whole system as one process with its external entities. Level-1 and below decompose that single process into sub-processes, adding detail. This builder produces a flat element-and-flow list you can use at any level.

How is a DFD different from a flowchart?

A flowchart shows control flow — the order of steps and decisions. A DFD shows data flow — what information moves where — and deliberately omits sequencing and conditional logic. They answer different questions about a system.

Is my spec sent anywhere?

No. The specification is assembled entirely in your browser from the elements and flows you enter. Nothing is uploaded, so you can document internal systems privately.

What is the Data Flow Diagram Spec Builder?

Builds a textual data flow diagram specification listing external entities, processes, data stores, and directional data flows — a clean, reviewable spec you can convert into a visual DFD in any diagram tool. It runs free in your browser on Gera Tools, with nothing uploaded.

Data Flow Diagram Spec Builder

Name: Data Flow Diagram Spec Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

The Data Flow Diagram Spec Builder produces a clean, text-based DFD specification you can review in a pull request or paste into a diagramming tool. Drawing a DFD by hand is slow, but the underlying model is just a typed list of elements plus the labelled flows between them — exactly what this tool captures.

The four DFD element types

Element	Symbol (Yourdon-DeMarco)	Role
External entity	Rectangle	Source or sink of data outside the system
Process	Circle or rounded rectangle	Transforms input data into output data
Data store	Open-ended rectangle	Persistent storage — database, file, queue
Data flow	Labelled arrow	Carries named data between two elements

The two common notations — Yourdon-DeMarco and Gane-Sarson — use slightly different shapes but identical semantics. This builder produces notation-agnostic text that works with either.

How it works

You register each entity, process, and store, then define flows by choosing a source, a destination, and the name of the data that moves. The builder validates that every flow connects two real elements and renders the result as a numbered specification with a flow table, so a reviewer can trace each piece of data end to end without needing a visual diagram.

DFD levels — context, level-1, and beyond

A context diagram (level 0) shows the entire system as a single process with all its external entities and boundary flows. It answers “what goes in and what comes out” without internal detail. A level-1 diagram decomposes that single process into sub-processes, each becoming a circle with its own input and output flows. Level-2 and below decompose further.

This builder produces a flat element-and-flow list that can represent any single level. For multi-level diagrams, build one spec per level and verify that each level-1 process’s inputs and outputs balance with its parent level-0 flows — this is called balancing.

Worked example

System: an online order processing system.

External entities: Customer, Payment Gateway, Warehouse
Processes: Validate Order, Process Payment, Dispatch Order
Data stores: Orders DB, Product Catalogue
Flows:
- Customer → Validate Order: order details
- Validate Order → Orders DB: pending order
- Validate Order → Process Payment: payment request
- Process Payment → Payment Gateway: charge request
- Payment Gateway → Process Payment: payment confirmation
- Process Payment → Dispatch Order: confirmed order
- Dispatch Order → Warehouse: pick list
- Dispatch Order → Customer: shipment notification

Every element has at least one input and one output flow; both external entities and data stores appear as sources and sinks; the spec is reviewable as plain text before a visual diagram is drawn.

Tips for clean DFDs

Name flows after the data, not the action. Use customer order, not “send order”.
Every process must have at least one input and one output. A process with only inputs is a black hole; fix it by adding the output flow you forgot.
Processes should not talk directly to each other through a data store without a flow label. Label every arrow explicitly.
Keep each level to 7 ± 2 processes. More than nine processes at one level makes the diagram hard to read; decompose the complex ones into their own sub-diagram.