In the late 1970s data-flow diagrams (DFDs) were introduced and popularized for structured analysis and design

(Gane and Sarson 1979). DFDs show the flow of data from external entities into the system, showed how the data moved from one process to another, as well as its logical storage. Figure 1 presents an example of a DFD using the Gane and Sarson notation. There are only four symbols: 1. Squares representing external entities, which are sources or destinations of data. 2. Rounded rectangles representing processes, which take data as input, do something to it, and output it. 3. Arrows representing the data flows, which can either, be electronic data or physical items. 4. Open-ended rectangles representing data stores, including electronic stores such as databases or XML files and physical stores such as or filing cabinets or stacks of paper. 5.1 What is the main merit of DFD? 5. The main merit of DFD is that it provides an overview of what data flows in a 6. system, what transformations are done on the data, what files are used and where results flow. 5.2 What is the role of DFD as a documentation aid? 7. It is a good documentation aid which is understood by both programmers and 8. non-programmers (i.e., laypersons). As DFD specifies only what processes are 9. performed and not how they are performed it is easily understood by a non programming user. 5.3 What is a context diagram? 10. A diagram giving an entire system s data flows and processing with a single 11. Process (circle) is called a context diagram.

5.4 What do you understand by levelling of DFD? 12. A context diagram is expanded into a number of interrelated processes. Each 13. process may be further expanded into a set of interconnected sub processes. This procedure of expanding a DFD is known as levelling. 5.5 What is a physical DFD? 14. A physical DFD specifies from where data flows and who processes the data and to whom the processed data is sent. 5.6 In what way is physical DFD useful? 15. It is easy to develop during fact gathering stage of systems analysis. Such a 16. physical DFD is easily understood by a lay user who can verify the DFD drawn 17. by an analyst and tell whether such a DFD corresponds to a particular operation 18. taking place in an organization. Physical DFD is the starting point for developing the logical DFD. DFD Principles
y

The general principle in Data Flow Diagramming is that a system can be decomposed into subsystems, and subsystems can be decomposed into lower level subsystems, and so on. Each subsystem represents a process or activity in which data is processed. At the lowest level, processes can no longer be decomposed. Each 'process' (and from now on, by 'process' we mean subsystem and activity) in a DFD has the characteristics of a system. Just as a system must have input and output (if it is not dead), so a process must have input and output.

Data enters the system from the environment; data flows between processes within the system; and data is produced as output from the system

General Data Flow Rules 1. Entities are either 'sources of' or 'sinks' for data input and outputs - i.e. they are the originators or terminators for data flows. 2. Data flows from Entities must flow into Processes 3. Data flows to Entities must come from Processes 4. Processes and Data Stores must have both inputs and outputs (What goes in must come out!) 5. Inputs to Data Stores only come from Processes. 6. Outputs from Data Stores only go to Processes. 7. DFD Levels 8. The Context and Top Level diagrams in the example start to describe 'Home Catalogue' type sales system. The two diagrams are just the first steps in creating a model of the system. (By model we mean a co-ordinated set of diagrams which describe the target system and provide answers to questions we need to ask about that system).As suggested the diagrams presented in the example will be reworked and amended many times - until all parties are satisfied. But the two diagrams by themselves are not enough; they only provide a high level description. On the other hand, the initial diagrams do start to break down, decompose, what might be quite a complex system into manageable parts. A data flow diagram (DFD) is a significant modeling technique for analyzing and constructing information processes. DFD literally means an illustration that explains the course or movement of information in a process. DFD illustrates this flow of information in a process based on the inputs and outputs. A DFD can be referred to as a Process Model.

Additionally, a DFD can be utilized to visualize data processing or a structured design. A DFD illustrates technical or business processes with the help of the external data stored, the data flowing from a process to another, and the results. A designer usually draws a context-level DFD showing the relationship between the entities inside and outside of a system as one single step. This basic DFD can be then disintegrated to a lower level diagram demonstrating smaller steps exhibiting details of the system that is being modelled. Numerous levels may be required to explain a complicated system. Data Flow Diagram Software Edraw is the business diagram software of choice to create structured analysis, information flow, process-oriented, dataoriented, and data process diagrams as well as data flowcharts. With Edraw, creating a wide range of diagrams such as business process diagrams, work flow diagrams, value stream maps, TQM diagrams, and cause and effect diagrams is a snap. Data flow diagram templates, symbols and samples are also provided with this tools; these ready-to-use templates and symbols will enable rapid designing of important complicated DFDs and process models. Free download Data flow diagram software Data Flow Diagram Template Use the Data Flow Diagram template to describe data processes. You can use this diagram to assist in data analysis or show the flow of information for a process. The Data Flow Diagram Shapes template includes shapes for entities, states, and data processes. In general, you'll use this template to diagram the

actions within a data flow, rather than the static state of a database. Review the Data flow diagram symbols. Examples of Data Flow Diagrams - These examples demonstrate how to draw data flow diagram. Before it was eventually replaced, a copy machine suffered frequent paper jams and became a notorious troublemaker. Often, a problem could be cleared by simply opening and closing the access panel. Someone observed the situation and flowcharted the troubleshooting procedure used by most people. When to use Data Flow Diagram The DFD is an excellent communication tool for analysts to model processes and functional requirements. One of the primary tools of the structured analysis efforts of the 1970's it was developed and enhanced by the likes of Yourdon, McMenamin, Palmer, Gane and Sarson. It is still considered one of the best modeling techniques for eliciting and representing the processing requirements of a system. Used effectively, it is a useful and easy to understand modeling tool. It has broad application and usability across most software development projects. It is easily integrated with data modeling, workflow modeling tools, and textual specs. Together with these, it provides analysts and developers with solid models and specs. Alone, however, it has limited usability. It is simple and easy to understand by users and can be easily extended and refined with further specification into a physical version for the design and development teams.

The different versions are Context Diagrams (Level 0), Partitioned Diagrams (single process only -- one level), functionally decomposed, leveled sets of Data Flow Diagrams.

Principle for Creating Data Flow Diagrams Therefore, the principle for creating a DFD is that one system may be disintegrated into subsystems, which in turn can be disintegrated into subsystems at a much lower level, and so on and so forth. Every subsystem in a DFD represents a process. In this process or activity the input data is processed. Processes cannot be decomposed after reaching a certain lower level. Each process in a DFD characterizes an entire system. In a DFD system, data is introduced into the system from the external environment. Once entered the data flows between processes. And then the processed data is produced as an output or a result. Create a Data Flow Diagram Data flow diagrams can be used to provide a clear representation of any business function. The technique starts with an overall picture of the business and continues by analyzing each of the functional areas of interest. This analysis can be carried out to precisely the level of detail required. The technique exploits a method called top-down expansion to conduct the analysis in a targeted way. Identifying the existing business processes, using a technique like data flow diagrams, is an essential precursor to business process reengineering, migration to new technology, or refinement of an existing business process. However, the level of detail required will depend on the type of change being considered.

The process model is typically used in structured analysis and design methods. Also called a data flow diagram (DFD), it shows the flow of information through a system. Each process transforms inputs into outputs. The model generally starts with a context diagram showing the system as a single process flowchart connected to external entities outside of the system boundary. This process explodes to a lower level DFD that divides the system into smaller parts and balances the flow of information between parent and child diagrams. Many diagram levels may be needed to express a complex system. Primitive processes, those that don't explode to a child diagram, are usually described in a connected textual specification. Home > Product Center > UML Diagram

How to Draw Data Flow Diagrams What is Data Flow Diagram Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs. Data flow diagrams can be used to provide a clear representation of any business function. The technique starts with an overall picture of the business and continues by analyzing each of the functional areas of interest. This analysis can be carried out to precisely the level of detail required. The technique exploits a method called top-down expansion to conduct the analysis in a targeted way.

As the name suggests, Data Flow Diagram (DFD) is an illustration that explicates the passage of information in a process. A DFD can be easily drawn using simple symbols. Additionally, complicated processes can be easily automated by creating DFDs using easy-to-use, free downloadable diagramming tools. A DFD is a model for constructing and analyzing information processes. DFD illustrates the flow of information in a process depending upon the inputs and outputs. A DFD can also be referred to as a Process Model. A DFD demonstrates business or technical process with the support of the outside data saved, plus the data flowing from the process to another and the end results. Data Flow Diagrams Symbols There are some symbols that are used in the drawing of business process diagrams (data flow diagrams). These are now explained, together with the rules that apply to them.

Process The process shape represents a task that handles data within the application. The task may process the data or perform an action based on the data. Multiple Process The multiple process shape is used to present a collection of sub processes. The multiple process can be broken down into its sub processes in another DFD. External Entity The external entity shape is used to represent any entity outside the application that interacts with the application via an entry point. Data Flow The data flow shape represents data movement within the application. The direction of the data movement is represented by the arrow. Data Store The data store shape is used to represent locations where data is stored. Data stores do not modify the data, they only store data. Privilege Boundary The privilege boundary shape is used to represent the change of privilege levels as the data flows through the application. Data Flow Diagrams - Context Diagrams The context diagram represents the entire system under investigation. This diagram should be drawn first, and used to clarify and agree the scope of the investigation.

The components of a context diagram are clearly shown on this screen. The system under investigation is represented as a single process, connected to external entities by data flows and resource flows. The context diagram clearly shows the interfaces between the system under investigation and the external entities with which it communicates. Therefore, whilst it is often conceptually trivial, a context diagram serves to focus attention on the system boundary and can help in clarifying the precise scope of the analysis. The context diagram shown on this screen represents a book lending library. The library receives details of books, and orders books from one or more book suppliers. Books may be reserved and borrowed by members of the public, who are required to give a borrower number. The library will notify borrowers when a reserved book becomes available or when a borrowed book becomes overdue. In addition to supplying books, a book supplier will furnish details of specific books in response to library enquiries. Note, that communications involving external entities are only included where they involve the 'system' process. Whilst a book supplier would communicate with various agencies, for example, publishers and other suppliers - these data flow are remote from the 'system' process and so this is not included on the context diagram. Data Flow Diagrams - Context Diagram Guidelines Firstly, draw and name a single process box that represents the entire system. Next, identify and add the external entities that communicate directly with the process box. Do this by considering origin and destination of the resource flows and data flows.

Finally, add the resource flows and data flows to the diagram. In drawing the context diagram you should only be concerned with the most important information flows. These will be concerned with issues such as: how orders are received and checked, with providing good customer service and with the paying of invoices. Remember that no business process diagram is the definitive solution - there is no absolute right or wrong. Data Flow Diagrams - Level 1 Diagrams The level 1 diagram shows the main functional areas of the system under investigation. As with the context diagram, any system under investigation should be represented by only one level 1 diagram. There is no formula that can be applied in deciding what is, and what is not, a level 1 process. Level 1 processes should describe only the main functional areas of the system, and you should avoid the temptation of including lower level processes on this diagram. As a general rule no business process diagram should contain more than 12 process boxes. The level 1 diagram is surrounded by the outline of a process box that represents the boundaries of the system. Because the level 1 diagram depicts the whole of the system under investigation, it can be difficult to know where to start. There are three different methods, which provide a practical way to start the analysis. These are explained in the following section and any one of them, or a combination, may prove to be the most helpful in any given investigation. There are three different methods, which provide a practical way to start the analysis. These are introduced below and any one of them, or a combination, may prove to be the most helpful in any given investigation:

Data Flow Diagrams - Resource Flow Analysis Resource flow analysis may be a useful method for starting the analysis if the current system consists largely of the flow of goods, as this approach concentrates on following the flow of physical objects. Resource flow analysis may be a useful method for developing diagrams if the current system consists largely of the flow of goods. Physical resources are traced from when they arrive within the boundaries of the system, through the points at which some action occurs, to their exit from the system. The rationale behind this method is that information will normally flow around the same paths as the physical objects. Data Flow Diagrams - Organizational Structure Analysis The organizational structure approach starts from an analysis of the main roles that exist within the organization, rather than the goods or information that is flowing around the system. Identification of the key processes results from looking at the organizational structure and deciding which functional areas are relevant to the current investigation. By looking at these areas in more detail, and analyzing what staff actually do, discrete processes can be identified. Starting with these processes, the information flows between them and between these processes and external entities are then identified and added to the diagram. Data Flow Diagrams - Document Flow Analysis The document flow analysis approach is appropriate if the part of the business under investigation consists principally of flows of information in the form of documents or computer input and output.

Document flow analysis is particularly useful where information flows are of special interest. The first step is to list the major documents and their sources and recipients. This is followed by the identification of other major information flows such as telephone and computer transactions. Once the document flow diagram has been drawn the system boundary should be added. Data Flow Diagrams - Numbering Rules The process boxes on the level 1 diagram should be numbered arbitrarily, so that no priority is implied. Even where data from one process flows directly into another process, this does not necessarily mean that the first one has to finish before the second one can begin. Therefore the processes on a level 1 diagram could be re-numbered without affecting the meaning of the diagram. This is true within any business process diagram - as these diagrams do not imply time, sequence or repetition. However, as the analysis continues beyond level 1 it is important that a strict numbering convention is followed. The processes on level 2 diagrams must indicate their parent process within the level 1 diagram. This convention should continue through level 3 diagrams, and beyond, should that level of analysis ever be required. The diagram on this screen clearly illustrates how processes on lower level diagrams identify their ancestral path.