Data Flow Diagram Rules

Jerry Post © 2012

1. Drawing elements
   1. External Entity (or Interface): Draw with a rectangle or square. Something outside the system being described. Names with a noun. They define the scope of the problem. We interact with them but do not describe their actions. Examples: Customer, Board of Directors.
   2. Processes: Draw with a circle or rounded rectangle. Actions or activities. Named with a verb. Typically focused on information processes but might be physical. Examples: Receive Order, Print Weekly Report, Compare Values. Each process on a level should be numbered, but the sequence does not matter.
   3. Data Store: Draw with an open end rectangle. A file or place to store data. Today, commonly a database table.
   4. Data Flow: Draw with a line. Data that moves from one entity or process to another. All data flows must have names and a direction (arrow). Information sometimes travels with a physical item (such as a receipt or invoice). Eventually, the format of the data should be defined, such as report layouts. Examples: Order, Receipt, Request.
2. Levels
   1. Not counting a title page, start with a Level 0 diagram that provides an overview of the entire system using 5-9 processes.
   2. If more detail is needed, define a new level and a new page for a given process. For example, Receive Orders could be a higher level process. This process can be exploded into more detail on the next level. Each level should contain no more than 9 processes.
   3. Level balancing: Data flows between process levels must be maintained. For example, a data flow entering a higher level process must also appear on the detail explanation.
3. Data Dictionary
   1. Every object in the DFD should be clearly named and defined. These terms should be accessible via a dictionary or list interface. Ideally, an CASE tool will be used to hold all of the definitions and support searches and reports.
   2. Ultimately, the diagrams along with the dictionary should provide sufficient information for programmers to create the actual system. For example, the dictionary should contain complete detailed descriptions of all data elements, input screens, and reports.
4. Basic Rules
   1. Data flows cannot exist directly between two external entities. If you really need to show that data flow, at least one of the entities is probably a process.
   2. Data flows cannot exist directly between two data stores. Add a process as an intermediary to do something with the data.
   3. A data flow cannot exist directly from an external entity to a data store. It most go through a process.
   4. A process must always have at least one input and one output. A process that receives data and never does anything with it is called a “black hole.” A process that creates output with no inputs would be called “genesis,” or a “miracle” which cannot happen.
   5. A data process must have at least one input and should have at least one output. But some data storage is long term and might not show all outputs.
   6. Outputs from a process should be different from inputs. That is a process should modify the data.
   7. A data flow cannot return directly to the object that emitted it.

A DFD is useful for communication--with users and other developers.
It is a also a useful way to take notes.