Scribd
Upload
755 views3 pages

Rules For Drawing Data Flow Diagrams

The document provides guidelines for creating data flow diagrams (DFDs) that model the flow of data through systems. It describes how to draw context-level, overview, and lower-level DFDs by identifying processes, data stores, and data flows and ensuring balance between diagrams. Key rules include having each process connect to at least one data flow, balancing child diagrams with their parent processes, and focusing on data flow rather than control flow or system logic.

Uploaded by

Ankur Gogate
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
755 views3 pages

Rules For Drawing Data Flow Diagrams

The document provides guidelines for creating data flow diagrams (DFDs) that model the flow of data through systems. It describes how to draw context-level, overview, and lower-level DFDs by identifying processes, data stores, and data flows and ensuring balance between diagrams. Key rules include having each process connect to at least one data flow, balancing child diagrams with their parent processes, and focusing on data flow rather than control flow or system logic.

Uploaded by

Ankur Gogate
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 3

Identify and list external entities providing inputs/receiving outputs from syst em; Identify and list inputs

from/outputs to external entities; Draw a context DFD Defines the scope and boundary for the system and project 1. 2. 3. 4. 5. 6. Think of the system as a container (black box) Ignore the inner workings of the container Ask end-users for the events the system must respond to For each event, ask end-users what responses must be produced by the system Identify any external data stores Draw the context diagram i. Use only one process ii. Only show those data flows that represent the main objective or most com mon inputs/outputs identify the business functions included within the system boundary; identify the data connections between business functions; confirm through personal contact sent data is received and vice-versa; trace and record what happens to each of the data flows entering the system (dat a movement, data storage, data transformation/processing) Draw an overview DFD - Shows the major subsystems and how they interact with one another - Exploding processes should add detail while retaining the essence of the detai ls from the more general diagram - Consolidate all data stores into a composite data store Draw middle-level DFDs - Explode the composite processes Draw primitive-level DFDs - Detail the primitive processes - Must show all appropriate primitive data stores and data flows verify all data flows have a source and destination; verify data coming out of a data store goes in; review with "informed"; explode and repeat above steps as needed. Balancing DFDs Balancing: child diagrams must maintain a balance in data content with their par ent processes Can be achieved by either: exactly the same data flows of the parent process enter and leave the child diag ram, or the same net contents from the parent process serve as the initial inputs and fi

nal outputs for the child diagram or the data in the parent diagram is split in the child diagram Rules for Drawing DFDs A process must have at least one input and one output data flow A process begins to perform its tasks as soon as it receives the necessary input data flows A primitive process performs a single well-defined function Never label a process with an IF-THEN statement Never show time dependency directly on a DFD Be sure that data stores, data flows, data processes have descriptive titles. Pr ocesses should use imperative verbs to project action. All processes receive and generate at least one data flow. Begin/end data flows with a bubble. Rules for Data Flows A data store must always be connected to a process Data flows must be named Data flows are named using nouns " Customer ID, Student information Data that travel together should be one data flow Data should be sent only to the processes that need the data Use the following additional guidelines when drawing DFDs Identify the key processing steps in a system. A processing step is an activity that transforms one piece of data into another form. Process bubbles should be arranged from top left to bottom right of page. Number each process (1.0, 2.0, etc). Also name the process with a verb that desc ribes the information processing activity. Name each data flow with a noun that describes the information going into and ou t of a process. What goes in should be different from what comes out. Data stores, sources and destinations are also named with nouns. Realize that the highest level DFD is the context diagram. It summarizes the ent ire system as one bubble and shows the inputs and outputs to a system Each lower level DFD must balance with its higher level DFD. This means that no inputs and outputs are changed. Think of data flow not control flow. Data flows are pathways for data. Think abo ut what data is needed to perform a process or update a data store. A data flow diagram is not a flowchart and should not have loops or transfer of control. Thi nk about the data flows, data processes, and data storage that are needed to mov

e a data structure through a system. Do not try to put everything you know on the data flow diagram. The diagram shou ld serve as index and outline. The index/outline will be "fleshed out" in the da ta dictionary, data structure diagrams, and procedure specification techniques.

You might also like