What is a data flow diagram (DFD)?

Data Flow Diagrams (DFD) helps us in identifying existing business processes. It is a technique we benefit from particularly before we go through business process re-engineering. At its simplest, a data flow diagram looks at how data flows through a system. It concerns things like where the data will come from and go to as well as where it will be stored. But you won't find information about the processing timing (e.g. whether the processes happen in sequence or in parallel). We usually begin with drawing a context diagram, a simple representation of the whole system. To elaborate further from that, we drill down to a level 1 diagram with additional information about the major functions of the system. This could continue to evolve to become a level 2 diagram when further analysis is required. Progression to level 3, 4 and so on is possible but anything beyond level 3 is not very common. Please bear in mind that the level of detail asked for depends on your process change plan. Diagram Notations Now we'd like to briefly introduce to you a few diagram notations which you'll see in the tutorial below.
External Entity

An external entity can represent a human, system or subsystem. It is where certain data comes from or goes to. It is external to the system we study, in terms of the business process. For this reason, people use to draw external entities on the edge of a diagram.

Process

A process is a business activity or function where the manipulation and transformation of data takes place. A process can be decomposed to finer level of details, for representing how data is being processed within the process.

Data Store

A data store represents the storage of persistent data required and/or produced by the process. Here are some examples of data stores: membership forms, database table, etc.

Data Flow

A data flow represents the flow of information, with its direction represented by an arrow head that shows at the end(s) of flow connector.

What will we do in this tutorial?

In this tutorial we will show you how to draw a context diagram, along with a level 1 diagram. Note: The software we are using here is Logizian Analyst edition. You are welcome to download a free 30-day evaluation copy of Logizianto walk through the example below. No registration, email address or obligation is required.

Steps to Draw a Context Diagram

1. To create a new DFD, select Business > Data Flow Diagram from the toolbar at the top.

2. To rename the new diagram, right click on the background and select Rename.... In the diagram's name box (at the top left corner), enter Context and press ENTER.

3. We'll now draw the first process. From the Diagram Toolbar, drag Process onto the diagram. Name the new process System.

4. Next, let's create an external entity. Place your mouse pointer over System. Drag the resource icon Bidirectional Data Flow --> External Entity to the left and release your mouse to create one.

5. Name the new external entity Customer.

6. Now we'll model the database accessed by the system. Again, place your mouse pointer over System but this time drag a different resource icon called Bidirectional Data Flow --> Data Store to the right. Then release your mouse to create a new data store.

7. Name the new data store Inventory.

8. Create two more data stores, Customer and Transaction, as shown below. We have just completed the Context diagram.

Steps to Draw a Level 1 DFD

1. Instead of creating another diagram from scratch, we will decompose the System process to form a new DFD. Right click on System and select Decompose from the popup menu.

2. The data stores and/or external entities connected to the selected process (System) would be referred to in the level 1 DFD. So when you are prompted to add them to the new diagram, click Yes to confirm. Note: The new DFD should look very similar to the Context diagram initially. Every element should remain unchanged, except that theSystem process (from which this new DFD decomposes) is now gone and replaced by a blank space (to be elaborated). 3. Rename the new DFD. Right click on its background and select Rename.... In the diagram's name box, enter Level 1 DFD and pressENTER.

4. Create three processes (Process Order, Ship Good, Issue Receipt) in center as shown below. That is the old spot for the Systemprocess and we place them there to elaborate System.

Wiring with connection lines for data flows

The remaining steps (6-16) in this section are about connecting the model elements in the diagram. For example, Customer provides order information when placing an order for processing. 1. Place your mouse pointer over Customer. Drag the resource icon Data Flow --> Process to the right and drop it over Process Order.

2. After dropping the data flow over Process Order, a text box near the connection line will open for you to put a label in. Enter order information and press ENTER.

3. Meanwhile the Process Order process also receives customer information from the database in order to process the order. Place your mouse pointer over the Customer data store. Drag the resource icon Data Flow --> Process to the left and drop it overProcess Order.

Optional: You can label the data flow "customer information" if you like. But since this data flow is quite self-explanatory visually, we are going to omit it here. 4. By combining the order information from Customer (external entity) and the customer information from Customer (data store), Process Order (process) then creates a transaction record in the database. Place your mouse pointer over Process Order. Drag the resource icon Data Flow --> Data Store to the right and drop it overTransaction. Name the data flow order details.

Drawing Tips: To rearrange a connection line, place your mouse pointer over where you want to add a pivot point to it. You'll then see a bubble at your mouse point. Click and drag it to where you need.

Up to this point, your diagram should look something like this.

5. Once a transaction is stored, the shipping process follows. So we will now create a data flow from Process Order (process) to Ship Good (process). Place your mouse pointer over Process Order. Drag the resource icon Data Flow --> Process downwards and drop it over to Ship Good.

6. Ship Good needs to read the transaction information (i.e. the order) in order to pack the right product for delivery. So we'll create a data flow from Transaction (data store) to Ship Good (process).

Note: If there is a lack of space, feel free to move the shapes around to make room.

7. Ship Good also needs to read the customer information for his/her shipping address. So let's create a data flow from Customer (data store) to Ship Good (process).

8. Ship Good then updates the Inventory database to reflect the goods shipped. So we'll create a data flow from Ship Good (process) to Inventory (data store). Name it updated product record.

9. Once the order arrives in the customer's hands, the Issue Receipt process begins. In it, a receipt is prepared based on the transaction record stored in the database. So let's create a data flow from Transaction (data store) to Issue Receipt (process).

10. Then a receipt is issued to the customer. Let's create a data flow from Issue Receipt (process) to Customer (external entity). Place your mouse pointer over Issue Receipt. Drag the resource icon Data Flow --> External Entity to the left and drop it overCustomer (the external entity, not the data store). Name the data flow receipt.

You have just finished drawing the level 1 diagram which should look something like this.

Steps to Make the Level 1 Diagram Easier to Read

The completed diagram above looks a bit rigid and busy. In this section we are going to make some changes to the connectors to increase readability.

1. Right click on the diagram (Level 1 DFD) and select Connectors > Curve. Connectors in the diagram are now in curve lines.

2. Move the shapes around so that the diagram looks less crowded.

THE TECHNIQUE OF DATA FLOW DIAGRAMMING

This section describes in detail the data flow diagramming technique. It is intended to serve as a handbook to guide the reader in developing data flow diagramming skills.

Definition:
Data Flow Diagramming is a means of representing a system at any level of detail with a graphic network of symbols showing data flows, data stores, data processes, and data sources/destinations.

Purpose/Objective:
The purpose of data flow diagrams is to provide a semantic bridge between users and systems developers. The diagrams are:

graphical, eliminating thousands of words; logical representations, modeling WHAT a system does, rather than physical models showing HOW it does it; hierarchical, showing systems at any level of detail; and jargonless, allowing user understanding and reviewing.

The goal of data flow diagramming is to have a commonly understood model of a system. The diagrams are the basis of structured systems analysis. Data flow diagrams are supported by other techniques of structured systems analysis such as data structure d iagrams, data dictionaries, and procedure-representing techniques such as decision tables, decision trees, and structured English. Data flow diagrams have the objective of avoiding the cost of:

user/developer misunderstanding of a system, resulting in a need to redo systems or in not using the system. having to start documentation from scratch when the physical system changes since the logical system, WHAT gets done, often remains the same when technology changes. systems inefficiencies because a system gets "computerized" before it gets "systematized". being unable to evaluate system project boundaries or degree of automation, resulting in a project of inappropriate scope.

Description:
Data Flow Diagrams are composed of the four basic symbols shown below.

The External Entity symbol represents sources of data to the system or destinations of data from the system. The Data Flow symbol represents movement of data. The Data Store symbol represents data that is not moving (delayed data at rest). The Process symbol represents an activity that transforms or manipulates the data (combines, reorders, converts, etc.). Any system can be represented at any level of detail by these four symbols.

External Entities:
1. are named with appropriate name. 2. can be duplicated, one or more times, on the diagram to avoid line crossing. 3. determine the system boundary. They are external to the system being studied. They are often beyond the area of influence of the developer. 4. can represent another system or subsystem. 5. go on margins/edges of data flow diagram.

Data Flows:
1. are represented with a line with an arrowhead on one end. A fork in a data flow means that the same data goes to two separate destinations. The same data coming from several locations can also be joined. 2. should only represent data, not control. 3. are ALWAYS named. Name is not to include the word "data".

4. are referenced by a combination of the identifiers of the constructs that the data flow connects. (14-A references a data flow from process 14 to external entity A)

Data Stores:
1. are generic for physical files (index cards, desk drawers, magnetic disk, magnetic tape, shirt pocket, human memory, etc.) 2. are named with an appropriate name, not to include the word "file", and numbered with a number preceded with a capital letter D 3. can be duplicated, one or more times, to avoid line crossing. 4. can show two or more systems that share a data store. This is done by adding a solid stripe on the left boundary. (Figure 5.34) This can occur in the case of one system updating the data store, while the other system only accesses the data. For ex ample, the data store could be a freight rate book that one system builds and maintains, but is used by the represented system. 5. are detailed in the data dictionary or with data description diagrams.

Processes:
1. show data transformation or change. Data coming into a process must be "worked on" or transformed in some way. Thus, all processes must have inputs and outputs. In some (rare) cases, data inputs or outputs will only be shown at more detailed levels of the diagrams. Each process in always "running" and ready to accept data. 2. are represented by a rounded corner rectangle 3. are named with one carefully chosen verb and an object of the verb. There is no subject. Name is not to include the word "process". Each process should represent one function or action. If there is an "and" in the name, you likely have more than o ne function (and process). 4. have physical location shown only for existing physical systems or a physical design is being represented. 5. are numbered within the diagram as convenient. Levels of detail are shown by decimal notation. For example, top level process would be Process 14, next level of detail Processes 14.1-14.4, and next level with Processes 14.3.1-14.3.6. 6. should generally move from top to bottom and left to right.

Procedure:
The procedure for producing a data flow diagram is to: 1. identify and list external entities providing inputs/receiving outputs from system; 2. identify and list inputs from/outputs to external entities; 3. create a context diagram with system at center and external entities sending and receiving data flows; 4. identify the business functions included within the system boundary; 5. identify the data connections between business functions; 6. confirm through personal contact sent data is received and vice-versa; 7. trace and record what happens to each of the data flows entering the system (data movement, data storage, data transformation/processing) 8. attempt to connect any diagram segments into a rough draft; 9. verify all data flows have a source and destination; 10. verify data coming out of a data store goes in; 11. redraw to simplify--ponder and question result; 12. review with "informed"; 13. explode and repeat above steps as needed.

Guidelines/Gumption Traps:
(Places where DFDing can go astray) 1. System boundary establishment is an important judgment call. External entities aid in determining where the boundary is established. An interfacing system can be shown as an external entity. It may be necessary to dictate the input of the external entity to assure system control. For example, customers may be required to submit orders or refund requests containing specific information which may require that the system aid in completion of a form. Use of output such as reports by management may re quire some agreement on tactics to be performed which may mean the entity becomes part of the system, not external to it. When in doubt, include the external entity as processes within the system and then evaluate with those concerned. 2. Label your processes carefully and vividly. A process that is labeled "Produce Report" and has the output of "Report" tells a reviewer very little. If you have trouble labeling anything on the diagram, it often is because you do not have adequate un derstanding. Choose names carefully.

3. Think logical, not physical. Ignore media, color, font, layout, packaging, time, sequencing, etc. Think "what", not "how". Something logical can be implemented physically in more than one way. Including "when" and "where" and "how" means you are g etting physical. 4. Think data, 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. 5. Concentrate first on what happens to a "good" transaction. Systems people have a tendency to lose sight of the forest because they are so busy concentrating on the branches of the trees. 6. Reviewers will not be convinced by confusion. A quality data flow diagram will be so simple and straightforward that people will wonder what took you so long. 7. Data store to data store, external entity to external entity, or external entity to data store connection usually do not make sense. Data flows with an arrowhead on each end cause confusion in labeling. Do not use them. 8. 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. Good Luck, Have Fun, and Stay on those Happy Trails......

Data Flow Diagram Notations

You can use two different types of notations on your data flow diagrams: Yourdon & Coad or Gane & Sarson.

Process Notations

Process
A process transforms incoming data flow into outgoing data flow. Learn how to edit text on this object.

Yourdon and Coad Process Notations

Gane and Sarson Process Notation

Datastore Notations

DataStore
Datastores are repositories of data in the system. They are sometimes also referred to as files. Learn how to edit text on this object.

Yourdon and Coad Datastore Notations

Gane and Sarson Datastore Notations

Dataflow Notations

Dataflow
Dataflows are pipelines through which packets of information flow. Label the arrows with the name of the data that moves through it. Learn how to connect objects.

External Entity Notations

External Entity
External entities are objects outside the system, with which the system communicates. External entities are sources and destinations of the system's inputs and outputs. Learn how to edit text on this object.

Context Diagrams
A context diagram is a top level (also known as Level 0) data flow diagram. It only contains one process node (process 0) that generalizes the function of the entire system in relationship to external entities.

DFD levels
The first level DFD shows the main processes within the system. Each of these processes can be broken into further processes until you reach pseudocode.

An example first-level data flow diagram