Rules for Drawing Logical DFD
. Any data flow leaving a process must be based on data input to the process.
. All data flows are named; the name reflects that data flowing between processes, data stores, sources and sinks.
. Only data needed to perform the process should be an input to the process.
. A process should know nothing about, that is, be independent of any other process in the system; it should depend only on its own input and output.
. Processes are always running; they do not start or stop. Analysts should assume a process is always ready to function or perform necessary work.
. Output from processes can take one of several forms:
a) An input data flow with information added by the process (for example, an annotated invoice).
b) A response or change of data form (such as a change of £’s profit to profit percentage.
c) Change of status (from unapproved to approved status).
d) Change of content (assembly or separation of information contained in one or more incoming data flows).
e) Change in organisation (e.g. the physical separation or rearrangement of data).
When developing DFDs in more detail it is important to maintain consistency between levels. No new inputs or outputs to a process should be introduced at a lower level that were not identified at a higher level. However, within a process, new data flows and data stores may be identified.
Levelling refers to the handling of local files (those that are used within a process). The details that pertain only to a single process on a particular level should be held within the process. Data stores and data flows that are relevant only to the inside of a process are concealed until that process is exploded into greater detail.
The logical data flow diagrams developed to this point do not include control information. No mention has been made of how to handle errors or exceptions. Although this information is necessary in the final analysis, it should not be a concern while identifying the overall data flow. The secondary diagrams (below second or third level) show error and exception handling in the process being exploded.
Some physical control information is unnecessary in logical DFDs. Copy numbers or annotations for documents (e.g. Copy 1, Copy 2, Shipping copy or Accounting copy), procedural orders (e.g. Find the record; Review the record; Annotate the record), or day-of-the-week triggers (e.g. Do on Monday; Do the last day of the month) do not belong with the logical and data aspects of requirements determination. The important elements for understanding a process during logical data flow analysis are not document copy numbers but descriptions of the data needed to perform the process.
The descriptions assigned to data flows and processes should tell the reader what is going on. All data flows should be named to reflect their content accurately.
The names assigned to data flows should reflect the data of interest to the analysts, not the documents on which they reside. For example, an invoice contains many different elements of information. Analysts are concerned with the contents of the invoice that are important for a particular process. It may be the invoice number and date of issue or the signature or authorisation associated with the invoice. It is not the sheet of paper itself.
Data flowing into a process undergo change. Therefore, the outbound data flow is named differently from the inbound one. (If no change is made to the data flow, what is the purpose of the process?)
All processes should be assigned names that tell the reader something specific about the nature of the activities in the process. The names INVENTORY CONTROL, PURCHASING and SALE are too general to be useful in a logical DFD. It is much better to use ADJUST QUANTITY ON HAND, PREPARE PURCHASE ORDER or EDIT SALES ORDER to describe the process.