Design/review of Data Flow Diagrams (DFD) Checklist free download

Basic review of data flow diagrams
- Has a system boundary been included in the diagram?
- Are all data sources and recipients external to the boundary?
- Does each process name start with a strong verb, and include a noun that the verb acts upon?
- Has the location part of the process symbol been specified in physical system diagrams, and left blank in logical system diagrams?
- Does each process have input and output data flows?
- Is there an input and output to every data store (if data stores are duplicated then this may occur at different places in the DFD set)?
- Data stores should only be connected to processes (by data flows)?
- Have the data store reference letters been correctly defined, i.e.
D for permanent computer data;
T for temporary computer data;
M for non-computer (manual) data storage?
- External data sources or recipients should be directly connected to processes in the system. (Where helpful to communicating an understanding of the system, sources or recipients may be connected to each other outside the system boundary.)
- Sources or recipients should not refer to people by name – use position or title.
- Can the diagram be simplified by amalgamating many recipients of one output into one generic ‘output distribution list’ (and them documenting the receivers elsewhere)?
- All data flows are named. Does each data flow start or end with a process? The only exception to this is between external sources and recipients.
- Flows that are within the system should be drawn within the system boundary. Is the diagram well laid out:
- are the symbols equally spaced?
- are data flows short, so that the symbols the flow connects are ‘visually’ close?
- does the diagram have a uniform style (e.g. straight data flows or flows with a right-angle incorporated)?
- data flows should not cross wherever possible?
- are data stores and source/recipients duplicated to reduce number of crossing flows, and also the length of data flows?
- Are any of the diagrams or parts of a diagram too detailed for the diagram level?
- The DFD diagrams should not be a documentation of computer programs.
- A process should not represent a decision – the decision is part of a process.
- In a logical data flow diagram, have all physical references in the data flow and process names been removed, e.g., locations, physical medium or time frames?

Business review
Boundary of system
- Ensure that the boundary is correct. Are any functions of organizational departments erroneously included or excluded?

Processes
- Do all the outputs require all the inputs to a process, and vice versa?
- Does each process have a distinct output?
- Are the processes a true reflection of the activity in the business system? Are any necessary manual processes or analytical processes included?
- Are housekeeping activities or custodial activities to maintain reference data, included in the diagrams?
- Could the process be better ‘levelled’ to communicate the analyst’s understanding?
- In a logical data flow diagram:
- have all redundant processes been removed?
- has all unnecessary process sequencing been erased?
- have all unnecessary processing cycles been removed?
- is the process partitioning based purely upon business functionality, with no reflection of any current organizational structure?
- does each process have one major output?
- There should be minimal portrayal of reporting or inquiry processing on data flow diagrams as this frequently causes cluttered diagrams. Inquiries should be documented as Functions.
- Include reports that are by-products of other processes as output data flows from that process.

Sources and recipients
- Are the sources and recipients depicted the correct ones for the associated data flows?
- Are the sources/recipients complete – should there be any more for a given data flow?
- For a given source/recipient are there any further inputs, or outputs to be received?
- In a logical DFD, is the source/recipient shown the actual generator or user of the data flow information, or merely the interface to the system?

Reviewing process descriptions
Basic review
- Is the input clearly stated – both in reference and descriptive terms?
- Is the main output of the process clearly stated?
- Are the sources and receivers of the data clearly stated?
- Has the reference data required been documented?
- Have any additional outputs been referenced, such as audit reports?

Semantic checks
- The process description should be used to add additional information that the DFD format is unsuitable for:
- has the frequency of the input been stated, both the average and peak volumes included when these occur?
- functional need for this process, i.e. its role within the system?
- Is the information correct?
- Is there any additional information to be added to clarify that the processing had taken place?