Data Flow Diagram - DFD Levels, Symbols, Case Study, Tutorial, Example,

The Level 1 DFD presents us with an overview of the system, a description that could come from a preliminary interview with departmental managers, perhaps. Now we must examine each process in more detail and break it down into other processes. The following steps explain how this is done. Step 1. Make each process box the system boundary. All data flows to or from that process are now flows across the lower-level system boundary. Step 2. Draw, outside the new boundary, the sources and recipients of these flows, as shown on the higher level DFD, (these can be external entities, data stores or other processes. Ensure the labelling is consistent with the higher level. Step 3. Identify and draw the processes at the lower levels that act on these data flows. Number the sub-processes with a decimal extension of the higher level number. i.e. Level 1, Process 3 will break down to processes 3.1, 3.2, 3.3 etc. Those processes that cannot be decomposed further, mark with an asterisk in the

There are many errors that may occur when drawing data flow diagrams. Here is a check list to help you avoid some of the major difficulties. External entities must be people or systems that send information to or accept information form the system to be engineered Data flows must always be labelled with the data they contain. Do not put verbs in the data flow description as this implies a process Parent and child diagrams should be consistent. Do not shows a data flow coming from or to an external entity on a level 1 DFD that isn’t shown on the context diagram (and vice versa). Check the direction of data flows to and from data stores Make sure each process has at least one input and one output Each data store should have at least one input and one output on the DFDs somewhere Each process name should start with a verb Where a process has only two data flows (one input and one output) then check it. Usually a data flow has been omitted.

The normal stages are Model the current system as it is presently implemented. It is rare that a system is designed to do something entirely new. Normally the intention is to make an existing system efficient by automating it to streamline more than one system by integrating them to replace a sequence of tasks with a new process The DFD drawn at the end of this stage is called the Current Physical System. The main characteristics of a Physical DFD are that a user will recognise how a system currently operates, warts and all. It should not attempt to improve the system, although it may document problems. The essential activities of the system are extracted. What is now left is just the data, information stores and starts and destinations. What is removed is physical things like any IT used, the media on which the data is recorded and stored, and who does what. The idea is to focus attention on what is being done to the data and free the mind from

All the data flows are labelled and describe the information that is being carried. It tends to make the diagram easier to read if the processes are kept to the middle, the external entities to the left and the data stores appear on the right hand side of the diagram. The process names start with a strong verb Each process has access to all the information it needs. In the example above, process 4 is required to check orders. Although the case study has not been given, it is reasonable to suppose that the process is looking at a customer’s order and checking that any order items correspond to ones that the company sell. In order to do this the process is reading data from the product data store. Each process should have an output. If there is no output then there is no point in having that process. A corollary of this is that there must be at least one input to a process as it cannot produce data but can only convert it form o

A Data Flow Diagram (DFD) is a diagrammatic representation of the information flows within a system showing How information enters and leaves the system  What changes the information  Where information is stored The purpose of a DFD is To show the scope and boundaries of a system  To show that the whole system has been considered May be used as a communications tool between a systems analyst and any person who plays a part in the system To act as the starting point for redesigning a system 

All information systems respond to events and conditions in the system’s environment. System’s environment includes external agents that form the boundary of the system and define where the system interfaces with its environment. It’s also referring to source or sink. External agents give an input to a system and receive an output from the system. An external agent of an information system are already fixed and defined. When the system is getting big, the external agents may be changed. An external agent can be an outside person, organization unit, system or organization that interacts with a system and eternal organization It can be such as : ·          An office, department, division or individual from the same organization ·          An organization, agency, or individual that is outside the organization ·          Another business or information system ·          System’s end users or managers The name of the entity appears inside the symbols. External agents should be named wit

Process modeling is a formal way of representing how an information system operates. It illustrates the processes or activities that are performed and how data moves among them in the system environment. Process modeling involves representing the functions, processes, manipulate, store and distribute the data among them and its environment. There are many different process modeling techniques can be used today. The most popular one is Data flow diagram (DFD). Data flow diagramming is a technique that diagrams the processes and the data passes among them in the system. It’s a traditional process modeling technique of structured analysis and design. Data flow diagram uses various symbols to show how the system transforms input data into useful information. There are two standard sets of data flow diagram symbols being used; DeMarco and Yourdon and Gane and Sarson.

Data Flow Diagrams :  graphical system model that shows all main requirements for an IS in one diagram. Inputs/outputs, processes, data storage. DFD’s and levels of abstraction: Higher-level diagrams provide general views of system Lower-level diagrams provide detailed views of system Differing views are called levels of abstraction. Context diagrams: DFD   that summarizes all processing activity for the system or subsystem Highest level (most abstract) view of system Shows system boundaries System scope is represented by a single process, external agents, and all data flows into and out of the system. DFD fragments: Created for each use case in the event table Represent system response to one event within a single process symbol Self-contained models Focus attention on single part of system Show only data stores required in the use case Event-partitioned system model: DFD to model system requirements using single process for each use case/activity in system or sub

Data Flow Symbols Unique Names for Data Flows.   No two data flows should ever have the same name.  (Remember, data is transformed by a process, so the input and output data flows from a process will have different names.) Data Flows should be consistent and cascade among levels. For example, if a “Student” EE provides an application to a process on a level 1 DFD (Figure 1 or Figure 2 or Figure 3), then it must appear on the Figure 0 DFD and the context diagram As a quick double-check before you turn in home work and projects: Count all the data flows on your context diagram from each EE.  On the level 0 diagram, the counts should be the same.  Cascade this rule for each subordinate level. NOTE: You should perform this same check for each data store. Process Symbols DFD Process symbols have 3-parts : a numeric id on top, a verb-object process label in the middle, and an actor-place-system identifier