Data Flow Diagram with Examples & Tips


This article describes the Data Flow Diagram devised by Larry Constantine in the 1970s as part of the Structured Analysis movement. It follows logically from the Context Diagram article in which we used a much simplified Data Flow Diagram to show a proposed system in the context of its external interfaces and actors.


The Data Flow Diagram (DFD) provides a graphical representation of the flow of data through a system. It shows logically what information is exchanged by our system processes and external interfaces or data stores, but it does not explicitly show when or in what sequence the information is exchanged.

Data Flow Diagrams are one of the three essential perspectives of the Structured Systems Analysis and Design Method (SSADM) that predates the more recent object oriented design methods and notations such as UML. This does not mean that the DFD has lost its usefulness even for new analysis endeavors, and any business analyst is bound to encounter them while reviewing the original design documentation for ‘legacy’ systems.

Diagram Elements

The diagram elements listed below and in the subsequent worked example are based on the Gane-Sarson symbol set (or notation) for Data Flow Diagrams. There are other symbol sets such as Yourdon-Coad, which comprise the same four element types albeit represented using different shapes.



This lozenge shape represents a system Process which typically consumes data from an Interface or Data Store (see below), transforms it in some way, and then feeds out the end result. to an Interface or Data Store.



This rectangle shape represents an external Interface, which is any external system or human actor that interacts with our system processes. In some alternative notations the Interface shape may be known as a Terminator, an Input/Output or an Entity.




A Data Flow line shows data flowing from a Process to an external Interface or Data Store, or data flowing from an external Interface or Data Store to a Process. The data flows in the direction of the arrow.



A Data Store may represent an entire database or a more specific entity within a database or other persistent data store.


While this table of diagram elements is informative, the only way to truly appreciate the role of the Data Flow Diagram is via a concrete worked example.

Worked Example

The figure below shows a Data Flow Diagram that was drawn in Microsoft Visio using the Gane-Sarson symbol set.

A good Data Flow Diagram should be easy to comprehend and intuitively obvious to the lay person; ideal for reviewing with non-technical project stakeholders. So take time to interpret the diagram yourself, and then read the description that follows.

This worked example DFD comprises five processes, four external interfaces / actors, and two data stores. It is not meant to be an exhaustive representation of the data flows in a banking system, but sufficiently comprehensive to give a good feel for how a DFD might be constructed

A Bank Manager actor provides New account details to the Open Account process which results in Customer details being persisted in the Customer Database data store and Account details being persisted in the Account Database data store. Although we have used the phrase ‘results in’ as part of this explanation, the DFD implies no such cause and effect; all it shows is that the Open Account process can read in data from the Bank Manager interface and write out data to the Customer Database and Account Database data stores in no particular order.

A Customer actor using the Online Banking Login process must provide some data in the form of a set of Login credentials such as a user name and password.

A Customer actor can receive a Money amount from the Withdraw process and can supply a Money amount to the Deposit process; in either case causing (although this causation cannot be explicitly modeled) an Account balance update to the Account Database data store.

A Customer actor can initiate the Transfer Funds process, to which he or she must provide an Account destination and money amount. The Transfer Funds process can send a Money amount to another bank via the Other Bank interface.

Just like the Customer actor, a Third Party actor can make use of the Deposit process (but obviously not the Withdraw process) by supplying a Money amount.

Tips and Tricks

Although our focus is on computer systems and software implementations, the DFD has wider uses in modelling non-computerised company processes and exchanges of information. The abstract symbol set could be used to model manual processes and physical data stores such as a filing cabinet. But we’re computer analysts, right?

Data flows between external interfaces and data stores should not be shown, for the simple reason that these are considered to be external and ‘out of scope’. The analyst should have no knowledge of the interconnections between external entities.

Notice how in the worked example, when modeling the data flow from the Customer to the Login process we chose to label the data flow with the phrase Login credentials rather than (for example) username and password. This gives us some flexibility in defining elsewhere what the required login credentials are without invalidating the diagram. In the future we may require the customer to supply an email address and PIN in order to log in. Note, however, that this is a personal preference and some analysts may prefer to be absolutely explicit when labeling data flows.

The external interfaces and actors in this DFD correspond with those shown on the Context Diagram in the previous article, so all we have really done here is to decompose the all-encompassing Bank System process from the Context Diagram into a set of internal processes for specific tasks. We have defined these processes with a view to making each one a discrete use case on a UML Use Case Diagram, with each data flow between an Interface and a Process in this diagram suggesting an association between an Actor and a Use Case. This is not obligatory and is merely a suggestion for aiding traceability between the various systems analysis diagrams and artifacts.

The DFD might also drive the creation of another UML diagram: the UML Activity Diagram which would show the order in which the Processes -- to be re-branded as Activities -- would be performed. This would resolve the problem of the DFD show what data is exchanged but not when.

Next Stop: the Entity-Relationship Diagram

The Data Flow Diagram focuses on the data that flows between system processes and external interfaces, and alludes to the fact that some data are persisted in data stores. The data store that has ‘persisted’ (pun intended) for longest, i.e. has stood the test of time, is the relational database. So in the next article we’ll look at how to model a relational database structure using an Entity-Relationship Diagram.

Author : Tony Loton - Author & Self-Publisher

As a former IT consultant and consultancy practice manager, Tony has published many IT feature articles and books including the most recent "UML Software Design with Visual Studio 2010"

Like this article:
  421 members liked this article


ajmarkos posted on Monday, October 10, 2011 1:46 PM

It is important that BA's understand the very unique powers of Data Flow Diagrams in deciding whether to use DFD's, BPMN, or any other process/functional modleing technique.

* Only DFD's have a built in mechanism to lead to a logical, natural partitioning (decomposition) of a system. This, basically, is provided via the BA following the DFD "interview the data" approach in which he/she follows data flows as they naturally converge and diverge to discover essential processes/functions upon which a proper decompostion are based.

* Only DFD's have a buil- in "litmus test of completedness": With DFD's , when the data flows do not "hook together", or come from or go to no where, it is very obvious that something is amiss.

* Systems at high levels of abstraction are very non-sequential. Sequentially based techniques, like BPMN, can not be used to model non-sequential systems.

* Only DFD's offer an Agile approach to big picture analysis. While Agile is about minimal documentation, it is also about quality documentation. Some high level DFD's (forget about written text), that strongly focus on the essitials (i.e., the data flows), provide the vehicle for minimal yet quality (i.e., capture the essentials) requirements specs.

jeysubbiah posted on Tuesday, October 11, 2011 3:23 PM
It might be a good idea to show as well. Then it will be up to the BA to chose one.

maiti.satarupa123 posted on Sunday, October 23, 2011 9:37 AM
Thanks Tony for sharing such a nice comprehensive article on DFD. Could please suggest some sites which has case studies and we can practice creating DFDs.

Thanks in Advance.
ajmarkos posted on Tuesday, October 25, 2011 8:30 AM

I have in the past tried to find such on-line. I have also done a significant amount of review of literature. Unfortunately, all the current on-line and book literature that I have seen about DFD's is very immature.

There is a alot of discussion about what the circles or lines mean,and maybe a brief mention of decomposition, but that is about it. I have found nothing in recent writings about, for example, the importance of and how to proceed in a logical, natural partioning (and conversely nothing about how poor man DFD techniques such as Use Cases and User Stories lead to forced, artificial partitioninig).

You may have to go back to Structure Analysis and System Specification by Tom DeMarco (70's) for an intelligent discussion on partitioning, the non-sequential nature of systems, the need for litmus test of completedness, etc, etc. Tom's friend Ed Yourdon also had some good writings. I learn about effective partitioning, etc. by tacking a Yourdon course using the DeMarco book and planned lessons.

shogun68 posted on Wednesday, September 26, 2012 10:56 PM
It was a good read, I am currently at university and we have to use Structured Analysis for our specifications. The thing I would like to point out in a more commercial sense is that processes should be numerated so that you can drill down into them. The above example is a good example of a DFD Level 0 Diagram. Except on a personal bias, I don't like bridges in diagrams it shows up as a mess. Also I like to put verb actions to my processes so that you know what is supposed to be happening.


Only registered users may post comments.

Latest Articles

Management Consulting – A New Opportunity for Business Analysts, but is it for me?
Sep 15, 2014
Are you a Senior BA who is looking for a new challenge? The Management Consulting BA role may be for you. This role is particularly interesting for ...

Featured Digital Library Resources 

brought to you by enabling practitioners & organizations to achieve their goals using:

Copyright 2006-2014 by Modern Analyst Media LLC