Other Tutorials by

Visual Basic - Visual Basic tutorials

VB6 beginners tutorial - Learn VB6

Advanced VB6 tutorial - Learn Advanced VB6

You are here: > Systems Analysis and Design

The procedure for producing a data flow diagram

  • Identify and list external entities providing inputs/receiving outputs from system;

  • Identify and list inputs from/outputs to external entities;

  • Draw a context DFD

    Defines the scope and boundary for the system and project

    1. Think of the system as a container (black box)
    2. Ignore the inner workings of the container
    3. Ask end-users for the events the system must respond to
    4. For each event, ask end-users what responses must be produced by the system
    5. Identify any external data stores
    6. Draw the context diagram
        i. Use only one process
        ii. Only show those data flows that represent the main objective or most common 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 (data 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 details 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 parent processes

  • Can be achieved by either:

  • exactly the same data flows of the parent process enter and leave the child diagram, or

  • the same net contents from the parent process serve as the initial inputs and final 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. Processes 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 describes the information processing activity.

  • Name each data flow with a noun that describes the information going into and out 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 entire 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 about 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. Think about the data flows, data processes, and data storage that are needed to move a data structure through a system.

  • Do not try to put everything you know on the data flow diagram. The diagram should serve as index and outline. The index/outline will be "fleshed out" in the data dictionary, data structure diagrams, and procedure specification techniques.

Related Topics

See Also


<< Previous Page | Contents | Next Page (Functional Modeling - Part II)>>


Home | About Us | Privacy Policy | Contact Us

Copyright © | All Rights Reserved