Business Analyst Articles: Business Analysis & Systems Analysis



BA ARTICLE ARCHIVE
» April 2014 (3)
» March 2014 (7)
» February 2014 (6)
» January 2014 (6)
» December 2013 (7)
» November 2013 (4)
» October 2013 (5)
» September 2013 (6)
» August 2013 (8)
» July 2013 (8)
» June 2013 (7)
» May 2013 (8)
» April 2013 (8)
» March 2013 (4)
» February 2013 (6)
» January 2013 (6)
» December 2012 (5)
» November 2012 (7)
» October 2012 (6)
» September 2012 (6)
» August 2012 (5)
» July 2012 (9)
» June 2012 (5)
» May 2012 (9)
» April 2012 (7)
» March 2012 (7)
» February 2012 (5)
» January 2012 (7)
» December 2011 (6)
» November 2011 (6)
» October 2011 (8)
» September 2011 (6)
» August 2011 (8)
» July 2011 (7)
» June 2011 (7)
» May 2011 (5)
» April 2011 (8)
» March 2011 (6)
» February 2011 (5)
» January 2011 (6)
» December 2010 (5)
» November 2010 (9)
» October 2010 (5)
» September 2010 (6)
» August 2010 (8)
» July 2010 (6)
» June 2010 (6)
» May 2010 (10)
» April 2010 (5)
» March 2010 (8)
» February 2010 (7)
» January 2010 (7)
» December 2009 (7)
» November 2009 (7)
» October 2009 (6)
» September 2009 (8)
» August 2009 (10)
» July 2009 (9)
» June 2009 (5)
» May 2009 (10)
» April 2009 (5)
» March 2009 (12)
» February 2009 (8)
» January 2009 (6)
» December 2008 (9)
» November 2008 (8)
» October 2008 (9)
» September 2008 (4)
» August 2008 (6)
» July 2008 (8)
» June 2008 (17)
» May 2008 (12)
» April 2008 (7)
» March 2008 (21)
» February 2008 (16)
» January 2008 (13)
» December 2007 (9)
» November 2007 (25)
» October 2007 (2)
» September 2007 (23)
» August 2007 (12)
» July 2007 (11)
» June 2007 (7)
» May 2007 (6)
» April 2007 (9)
» March 2007 (5)
» February 2007 (3)
» January 2007 (2)
Articles and White Papers
Monday, October 10, 2011
75924 Views 5 Comments 402 members voted Article Rating

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.

Introduction

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"

Rate this:

COMMENTS

Posted on Monday, October 10, 2011 1:46 PM by
ajmarkos
Tony:

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.

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

Jey
jeysubbiah
Posted on Sunday, October 23, 2011 9:37 AM by
maiti.satarupa123
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.
maiti.satarupa123
Posted on Tuesday, October 25, 2011 8:30 AM by
ajmarkos
Maiti:

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.

Tony
ajmarkos
Posted on Wednesday, September 26, 2012 10:56 PM by
shogun68
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.

Cheers

Anthony
shogun68
Only registered users may post comments.

Do you twitter?: If you want short updates on what's going on in the BA world and at ModernAnalyst.com, simply follow us on Twitter: http://twitter.com/ModernAnalyst



Featured Digital Library Resources 

Big Data Analytics for Dummies
Finally, a Big Data book written for business analysts, BI professionals, and data scientists!  Big Data Analytics for Dummies is a valuable resource that addresses the practical dilemmas surrounding Big Data...

A Buyer’s Guide to Customer Analytics
Discover the five crucial criteria of a customer analytics platform in A Buyer’s Guide to Customer Analytics now.

Free Analytics software: Alteryx Project Edition
Alteryx Project Edition provides you with a single solution that delivers the data blending, analytics, and sharing capabilities of Alteryx with just enough allowed runs of your workflow to solve one business problem or to complete one project.

The Business Analyst's Guide to Hadoop
Get started with Hadoop using this whitepaper, "The Business Analyst's Guide to Hadoop".

Copyright 2006-2013 by Modern Analyst Media LLC