Data-flow diagrams are an intuitive way of representing a data flow model that shows how data is processed by a system. At the analysis level, they should be used to model the way in which data is processed in the existing system. The use of data-flow models for analysis became widespread after the publication of DeMarco’s book on structured systems analysis. They are an intrinsic part of structured methods that have been developed from this work. The notation used in these models represents functional processing (rounded rectangles), data stores (rectangles) and data movements between functions (labelled arrows).
The following diagram shows a data-flow diagram for equipment procurement. This illustrates the processing steps with the area bounded by dotted lines, showing the boundaries of the system to be implemented.
Data-flow models are used to show how data flows through a sequence of processing steps. For example, a processing step could be to filter duplicate records in a customer database. The data is transformed at each step before moving on to the next stage. These processing steps or transformations represent software processes or functions when data-flow diagrams are used to document a software design. However, in an analysis model, people or computers may carry out the processing.
Data-flow models are valuable because tracking and documenting how the data associated with a particular process moves through the system helps analysts understand what is going on. Data-flow diagrams have the advantage that, unlike some other modelling notations, they are simple and intuitive. It is usually possible to explain them to potential system users who can therefore participate in validating the analysis.
The following diagram shows another examples of a data-flow model. This diagram shows which shows the steps involved in processing an order for goods (such as computer equipment) in an organisation. This particular model describes the data processing in the ‘Place equipment order’ activity in the overall process model shown in Figure 1. The model shows how the order for the goods moves from process to process. It also shows the data stores (Orders file and Budget file) that are involved in this process.
In principle, the development of models such as data-flow models should be a ‘top-down’ process. In this example, this would imply that you should start by analysing the overall procurement process. You then move on to the analysis of sub-processes such as ordering. In practice, analysis is never like that. You learn about several different levels at the same time. Lower-level models may be developed first then abstracted to create a more general model.