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.

Data Flow Diagram Spec Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, 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.

How it works

A DFD has four element types: external entities (sources and sinks outside the system), processes (transformations of data), data stores (databases, files, queues), and data flows (labelled arrows carrying data from one element to another). 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.

Tips and example

Name flows after the data, not the action. A flow is customer order or payment receipt, not “send” — the verb belongs to the process.
Every process needs input and output. A process with only inputs is a black hole and one with only outputs is a miracle; if you have either, an element or flow is missing.
Balance your levels. When you decompose a process into a sub-DFD, the inputs and outputs of the sub-diagram must match the parent flows exactly.

Example: external entity Customer sends order details to process Validate Order, which writes validated order to data store Orders DB and returns confirmation to the customer.