Data flow diagram rules

A valid data flow diagram follows rules about how its components connect. The rules keep it consistent, so every arrow shows data being handled in a sensible way.

Where flows can start and end

Every data flow must go to or from a process. A flow can run between two processes, from a process to a data store, from a data store into a process, from an external entity into a process, or from a process out to an external entity. It cannot join two components that never act on the data, such as two data stores or a data store and an external entity. External entities must connect to a process, not directly to another external entity, because data is only handled once a process does something with it.

For example, in a bike repair shop a Customer sends a repair request to the process Book in repair. That process saves the job in the Repair jobs store and sends a confirmation to the Customer. A flow drawn straight from Customer to Repair jobs would break the rules, because no process would handle the request.

Every process must transform data

Each process needs at least one input and at least one output. A process with only an input would take data and do nothing with it, while a process with only an output would produce data from nowhere. The inputs must be capable of producing the outputs: a process can combine, summarise or calculate from its inputs, but it cannot add data that was never supplied. A process that calculates a repair cost from parts cost and labour hours can output a total cost, but it cannot also output a customer phone number unless that was an input.

The output also cannot be identical to the input. If data passes through unchanged, nothing has been transformed, so the step is not really a process. Sorting a list of jobs by date produces a new ordered list; copying the list exactly would not be valid.