How do we begin to construct Data Flow Diagrams (DFDs)?

A data flow diagram (DFD) is a graphical representation of the “flow” of data through an information system, modeling its process aspects. A DFD is often used as a preliminary step to create an overview of the system, which can later be elaborated.

Data flow diagram is a popular way to visualize the major steps and data involved in software system processes. This is not the same as business process modeling; DFDs were usually used to show data flows in a computer system, although they could in theory be applied to business process modeling. DFDs were useful to document the major data flow or to explore a new high-level design in terms of data flow.

How do we begin to construct Data Flow Diagrams (DFDs)?

To sharpen more understanding of data flow diagrams go through these two articles on our blog before starting to construct Data Flow Diagrams.

Some examples of Data Flow Diagrams build for different project scenario are :

Before we begin, you’ll have to know some thing about tools used to draw Data Flow Diagrams or any other visual UML diagrams, diagrams in this tutorial were drawn using Microsoft Visio Tool, there are still more tools like Dia, Umbrello (for ubuntu). Microsoft Visio tool comes with various features to draw Data Flow Diagrams and other diagrams too.

So lets begin with the top-down process you need to follow to construct draw DFD (data flow diagrams) in a easy way:

  1. Draw a bubble/circle to represent the process you are about to define.
  2. Ask yourself what thing(s) initiate the process: what is coming in? You will find it advantageous to be consistent in where you show process inputs. Try to model them to the left of the process. You will later be able to immediately define your process inputs when looking back at your DFD, especially when using them for system enhancements.
  3. Determine the process outputs, or what things are coming out, and model them to the right of the process as best you can.
  4. Establish all files, forms or other components that the process needs to complete its transformation. These are usually data stores that are utilized during processing. Model these items either above or below the process.
  5.  Name and number the process by its result. For example, if a process produces invoices, label it “Create Invoices.” If the process accomplishes more than one event, label it by using the “and” conjunction. This method will allow you to determine whether the process is a functional primitive. Ultimately, the name of the process should be one that most closely associates the DFD with what the user does. Therefore, name it what the user calls it! The number of the process simply allows the analyst to identify it to the system and most important to establish the link to its children levels during functional decomposition.

Let us now apply this procedure to the example below problem domain given below.

Problem domain to construct Data Flow Diagram:

Vendors send Mary invoices for payment. Mary stamps on the invoice the date received and matches the invoice with the original purchase order request. Invoices are placed in the Accounts Payable folder. Invoices that exceed thirty days are paid by check in two-week intervals

Step 1: Draw the bubble

A process bubble used in Data Flow Diagram

A process bubble used in Data Flow Diagram

Figure 1: A process bubble.

Step 2: Determine the inputs

In this example we are receiving an invoice from a Vendor. The Vendor is considered a Terminator since it is a boundary of the input and the user cannot control when and how the invoice will arrive. The invoice itself is represented as a data flow coming from the Vendor terminator into the process as shown in Figure 2:


Vendor invoice (as entity) to process to DFD

Vendor invoice (as entity) to process to DFD

Figure 2: Terminator sending invoice to the process.

Step 3: Determine the outputs of the process

In this case the output of the process is that the Vendor receives a check for payment as shown in Figure 3:

DFD with output to the Vendor through Process

DFD with output to the Vendor through Process

Figure 3: DFD with output of check sent to vendor

Step 4: Determine the “processing” items required to complete the process

In this example, the user needs to:

  • match the invoice to the original purchase order;
  • create a new account payable for the invoice in a file; and
  • Eventually retrieve the invoice from the Accounts Payable file for payment.

Note that in Figure 4 the Purchase Order file is accessed for input (or retrieval) and therefore is modeled with the arrow coming into the process.

The Accounts Payable file, on the other hand, shows a two-sided arrow because entries are created (inserted) and retrieved (read). In addition, arrows to and from data stores may or may not contain data flow names. For reasons that will be explained later in the chapter, the inclusion of such names is not recommended.

DFD with interfaceing data store

DFD with interfaceing data store

Figure 4: DFD with interfacing data stores.

Step 5: Name and number the process based on its output or its user definition.


Final named DFD

Final named DFD

Figure 5: Final named DFD.

The process in Figure 5 is now a complete DFD that describes the event of the user. You may notice that the procedures for stamping the invoice with the receipt date and the specifics of retrieving purchase orders and accounts payable information are not explained. These other components will be defined using other modeling tools. Once again, the DFD reflects only data flow and boundary information of a process.

The DFD in Figure 5 can be leveled further to its functional primitive. The conjunction in the name of the process can sometimes help analysts to discover that there is actually more than one process within the event they are modeling.

Based on the procedure, the event really consists of two processes: Recording Vendor Invoices and Paying Vendor Invoices. Therefore, P1 can be leveled as shown in Figure 6.

Leveled DFD for Record and Pay Invoices process

Leveled DFD for Record and Pay Invoices process

Figure 6: Leveled DFD for Record and Pay Invoices process.

So, by this time I hope you are able to design DFD by using symbols used in DFD

Leave a Reply to Difference between Physical and Logical Data Flow Diagrams Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>