data flow diagram case study examples pdf

Context and Level 1 Data Flow Diagram Examples With Explanation and Tutorial

The best way to explain things is with examples. We will show you context (also called simple or level 0) and level 1 data flow diagram examples to understand better the meaning behind it.

On this page:

• What is data flow diagram? Definition, advantages, and disadvantages – a tutorial for beginner.
• Rules and symbols for creating DFD.
• Context data flow diagram example (in PDF) with an explanation step by step.
• Level 1 data flow model diagram example (in PDF) with an explanation.
• How to draw DFD online? Best software tools and solutions.

Let’s define and explain it:

A data flow diagram (DFD) represents graphically a flow of data within a system. It illustrates how data is input and output from the system.

So, we can say a data flow diagram has 4 major elements:

• Processes – the main activities that are happening within the system boundary. The process can be as simple as collecting customer data and storing it in the company database. Also, it can be a very complicated process such as creating a report containing bank contracts with customers of all bank clones in a region.
• External entities – the sources of information coming to or leaving the system. External entities are outside systems such as people (customers, stakeholders, managers), organizations, computers and other systems that send or receive data from our system.
• Data stores – places where data is held such as files or repositories. Data stores show information that is not moving.
• Data flows – illustrate the movements that data have between the external entities, data stores, and the processes.

Symbols used in data flow diagrams

Each of the above elements has a symbol that represents it. Typically, data flow diagram uses the following symbols:

The above ones are so-called symbols of Yourdon and Coad.

There is also the symbol system of Gane and Sarson, but in our data flow diagram examples, we will use Yourdon and Coad symbols as they are easier for drawing and remembering.

DFD rules, guidelines, and tips:

Creating data flow diagrams requires some guidelines and rules that should be followed. These guidelines make DFD easily understandable and lucid.

Here are some of the key rules and tips.

1. Each process has at least one outgoing data flow and at least one ingoing data flow.

2. Each process can go to any other symbol (other processes, data store, and entities).

3. Each data store should have at least one incoming and at least one outgoing data flow.

4. Entities must be connected to a process by a data flow.

5. Data flows cannot cross with each other.

6. Data stores cannot be connected to external entities. Otherwise, it means you’re allowing an external entity access to your data files and stores.

7. The labels of processes can be verb phrases. Data stores are displayed by nouns.

8. Data flows cannot run between two external entities without going through a process (as you will see in the data flow diagram examples below).

Advantages and disadvantages of data flow diagrams:

Before going further to data flow diagram examples, let’s see what are some key benefits and cons of DFD.

Advantages:

• A graphical technique that is relatively easy to understand for stakeholders and other users.
• Provides a detailed view of the system components and boundaries.
• Provide clear and detailed information about the processes within a system.
• Shows the logic of the data flow.
• Presents a functional breakdown of the system.
• Used as a part of the system documentation.

Disadvantages:

• Takes a long time to create.
• Does not give any information about the timing, sequence, and synchronization of processes i.e. data flow diagrams do not specify when the processes are performed. Therefore it should not be confused with a process or flowchart diagram which can illustrate these things.
• Sometimes might be difficult for non-technical users to understand the diagram.

Data Flow Diagram Examples

1. Context data flow diagram: definition and example with explanation

When it comes to simple data flow diagram examples, context one has the top place.

Context data flow diagram (also called Level 0 diagram) uses only one process to represent the functions of the entire system.

It does not go into details as marking all the processes.

The purpose is to express the system scope at a high level as well as to prevent users from deep down into complex details.

The major advantage of context DFD is simplicity.

Key context DFD characteristics:

• Simple to draw.
• No need of technical knowledge to understand it.
• Shows the system boundaries.

Steps for creating a context DFD:

• Step1: Define the process.
• Step2: Create a list of all external entities (all people and systems).
• Step3: Create a list of the data flows.
• Step4: Draw the diagram.

Let’s illustrate the things with a context data flow diagram example.

Below is shown a simple context DFD drawn for a Clothes Ordering System and explanation.

Download the above diagram in PDF

Now, let’s explain how we create the diagram.

Srep1: Define the process.

As it is a context data flow diagram, the process is only one. In our case, it is Clothes Ordering System . Draw a rectangle for the process.

Step 2: Create the list of all external entities.

In our example, the external entities are:  C ustomer, Clothes Store, Clothes Supplier, and the Sales Manager .  These are all entities who are involved with our system. Also, now you can draw a rectangle for each of the entities.

Step 3:  Create a list of the data flows.

In between our process and the external entities, there are data flows that show a brief description of the type of information exchanged between the entities and the system.

In our example, the list of data flows includes: Customer Order, Receipt, Clothes Order, Receipt, Clothes Order, and Management Report.

Now, connect the rectangles with arrows signifying the data flows.

If data flows both ways between any two rectangles, create two individual arrows.

Step4: It is our diagram.

2. Level 1 data flow diagram: definition and example with explanation

As you saw above context DFD contains only one process and does not illustrate any data store.

This is the main difference with level 1 DFD.

Level 1 DFD breaks down the main process into subprocesses that can then be seen on a more deep level. Also, level 1 DFD contains data stores that are used by the main process.

• Step1: Define the processes (the main process and the subprocesses).
• Step3:  Create a list of the data stores.
• Step4: Create a list of the data flows.
• Step5: Draw the diagram.

Here is our level 1 data flow example – a decomposition of the Clothes Ordering System illustrated in the context DFD.

As you see, the above Clothes Order System Data Flow Diagram Example shows three processes, four external entities, and also two data stores.

Here are the steps for creating the level 1 DFD:

Step 1:  Define the processes.

The three processes are: Order Clothes, Generate Reports, and Order Inventory.

Step 2:  Create the list of all external entities.

The external entities are:  Customer, Clothes Store, Sales Manager, and Supplier

Step 3:  Create the list of the data stores.

These are: Order and Inventory

Step 4:  Create the list of the data flows

Data flows are:  Order, Bill, Order, Order, Inventory details, Inventory details, Orders, Reports, Inventory Order, Inventory Order, Inventory details.

Step5: Create the diagram.

How to Create Data Flow Diagrams?

It might seem a little bit difficult to create data flow diagram examples. But in our IT world, it can be very easy and even fun to make them using the appropriate software tools.

You can use paid or free graphing software , free mind mapping software  or diagramming solutions such as:

• VisualParadigm
• Realtime Board  – this is my favorite one.

The diagramming software tools like the above ones provide pre-ready templates that save your time and efforts.

They also make creating multi-level DFD (such as level 2 DFD) easier and at the same time deeper enough to represent clearly how the data is handled.

These tools also allow building very visually appealing DFDs with the use of a variety of shapes, colors, symbols, and arrows.

In addition to the context and level 1 data flow diagram, there are also level 2 and level 3 DFD.

Level 2+ DFD just breaks processes down into more subprocesses. Teoritucaly, DFD could go even beyond level 3, but they rarely do this on practice.

Hopefully, the above tutorial and context and level data flow diagram examples help you understand better the meaning and steps for creating DFDs.

Data flow diagrams are very useful types of graphs in the business that can support your data-driven decision-making , simply because the businesses are based on systems and processes.

From customer ordering methods to banking processes and operations, nearly everything an organization makes involves a system and processes of some sort.

About The Author

Silvia Valcheva

Silvia Valcheva is a digital marketer with over a decade of experience creating content for the tech industry. She has a strong passion for writing about emerging software and technologies such as big data, AI (Artificial Intelligence), IoT (Internet of Things), process automation, etc.

One Response

It was a nice experience and it provides detailed information that is easier to understand in all ways.

Leave a Reply Cancel Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed .

• Demo Videos
• Interactive Product Tours
• Request Demo

Data Flow Diagram: Examples - Food Ordering System

Data Flow Diagram (DFD) provides a visual representation of the flow of information (i.e. data) within a system. By drawing a Data Flow Diagram, you can tell the information provided by and delivered to someone who takes part in system processes, the information needed to complete the processes and the information needed to be stored and accessed. This article describes and explains the Data Flow Diagram (DFD) by using a food ordering system as an example.

Compatible edition(s): Enterprise , Professional , Standard , Modeler

• February 16, 2015
• Views: 976,295

The Food Ordering System Example

Context dfd.

A context diagram is a data flow diagram that only shows the top level, otherwise known as Level 0. At this level, there is only one visible process node that represents the functions of a complete system in regards to how it interacts with external entities. Some of the benefits of a Context Diagram are:

• Shows the overview of the boundaries of a system
• No technical knowledge is required to understand with the simple notation
• Simple to draw, amend and elaborate as its limited notation

The figure below shows a context Data Flow Diagram that is drawn for a Food Ordering System. It contains a process (shape) that represents the system to model, in this case, the " Food Ordering System ". It also shows the participants who will interact with the system, called the external entities. In this example, the Supplier , Kitchen , Manager , and Customer are the entities who will interact with the system. In between the process and the external entities, there is data flow (connectors) that indicate the existence of information exchange between the entities and the system.

Context DFD is the entrance of a data flow model. It contains one and only one process and does not show any data store.

Level 1 DFD

The figure below shows the level 1 DFD, which is the decomposition (i.e. break down) of the Food Ordering System process shown in the context DFD. Read through the diagram and then we will introduce some of the key concepts based on this diagram.

The Food Order System Data Flow Diagram example contains three processes, four external entities, and two data stores.

Based on the diagram, we know that a Customer can place an Order . The Order Food process receives the Order , forwards it to the Kitchen , store it in the Order data store, and store the updated Inventory details in the Inventory data store. The process also delivers a Bill to the Customer .

The Manager can receive Reports through the Generate Reports process, which takes Inventory details and Orders as input from the Inventory and Order data store respectively.

The Manager can also initiate the Order Inventory process by providing Inventory order . The process forwards the Inventory order to the Supplier and stores the updated Inventory details in the Inventory data store.

Data Flow Diagram Tips and Cautions

• Process labels should be verb phrases; data stores are represented by nouns
• A data store must be associated with at least a process
• An external entity must be associated with at least a process
• Don't let it get too complex; normally 5 - 7 average people can manage processes
• DFD is non-deterministic - The numbering does not necessarily indicate sequence, it's useful in identifying the processes when discussing with users
• Datastores should not be connected to an external entity, otherwise, it would mean that you're giving an external entity direct access to your data files
• Data flows should not exist between 2 external entities without going through a process
• A process that has inputs but without outputs is considered to be a black-hole process

Don't mix up data flow and process flow

Some designers may feel uncomfortable when seeing a connector connecting from a data store to a process, without seeing the step of data request being shown on the diagram somehow. Some of them will try to represent a request by adding a connector between a process and a data store, labeling it "a request" or "request for something", which is wrong.

Keep in mind that Data Flow Diagram was designed for representing the exchange of information. Connectors in a Data Flow Diagram are for representing data, not for representing process flow, step or anything else. When we label a data flow that ends at a data store "a request", this means we are passing a request as data into a data store. Although this may be the case in implementation level as some of the DBMS do support the use of functions, which intake some values as parameters and return a result, in Data Flow Diagram, we tend to treat data store as a sole data holder that does not possess any processing capability. If you want to model the system flow or process flow, use UML Activity Diagram or BPMN Business Process Diagram instead. If you want to model the internal structure of a datastore, use an Entity Relationship Diagram .

• Food-Ordering-System.vpp

Readers of this tutorial also read

• What is Data Flow Diagram (DFD)? How to Draw DFD?
• How to Write Effective Use Cases?
• How to Develop As-Is and To-Be Business Process?
• How to Model Relational Database Design with ERD?
• How to Draw UML Diagrams in NetBeans?
• Enterprise Architecture
• TOGAF ADM Software: How to Use?
• Drawing ArchiMate Diagram
• Design & Modeling
• Problem Desc. to Model
• Creating Activity Diagram
• Creating State Machine Diagram
• Creating Component Diagram
• Creating Deployment Diagram
• Cause and Effect Diagram
• Drawing Timing Diagram
• Class Diagram in Java, C# and VB
• Animating Activity Diagram
• Drawing Profile Diagram
• Attach file reference to model
• Using sub-diagrams
• UML Package Diagram
• Mult-party service in SoaML
• Drawing SoaML Diagram
• Stereotypes and tagged values
• Define custom element properties
• Merge actors in use case diagram
• Numbering sequence messages
• Using Textual Analysis
• Seq. Diagram duration constraint
• Fill-in UML state's body
• Edit attribute's initial value
• Drawing Sequence Diagram
• Test cases for SysML requirement
• Customize requirement types
• Drawing Communication Diagram
• Develop Sequence Diagram with keybaord
• Abstract Factory Pattern Tutorial
• Factory Method Pattern Tutorial
• Builder Pattern Tutorial
• Prototype Pattern Tutorial
• Singleton Pattern Tutorial
• Adapter Pattern Tutorial
• Proxy Pattern Tutorial
• Composite Pattern Tutorial
• Bridge Pattern Tutorial
• Decorator Pattern Tutorial
• Flyweight Pattern Tutorial
• Facade Pattern Tutorial
• Command Pattern Tutorial
• Chain of Responsibility Pattern Tutorial
• Interpreter Pattern Tutorial
• Iterator Pattern Tutorial
• Observer Pattern Tutorial
• Memento Pattern Tutorial
• Mediator Pattern Tutorial
• Template Pattern Tutorial
• Strategy Pattern Tutorial
• State Pattern Tutorial
• Visitor Pattern Tutorial
• Create BPMN diagram
• Business process modeling
• Business Process Mapping
• Creating BPMN diagram
• Using Data Object in BPMN
• BPD Example - Leave Application
• BPMN Intro I
• BPMN Intro II - Swimlanes
• BPMN Intro III - Flow/Connectors
• BPMN Intro IV - Data & Artifacts
• Develop As-is & To-be BPD
• Working procedures of BP tasks
• Link data object with ERD entity
• Animate BPMN business process
• BPMN process simulation
• Import Bizagi project
• Use stereotype in EPC Diagram
• Secondary pools for BPMN task
• Drill-down a BPMN sub-process
• Process simulation example
• Drawing BPMN Conversation Diagram
• BPMN 2.0 BPD
• Create Circuit Diagram
• Create Venn Diagram
• Create Floor Plan
• Create Network Diagram
• Flowchart Tutorial
• DFD Example - Customer Service
• DFD Example - Food Ordering
• DFD Example - Securities Trading
• DFD Example - Supermarket App
• DFD Example - Vehicle Main. Depot
• DFD Example - Video rental
• Functional decomposition in DFD
• Data Flow Diagram Tutorial
• Using Storyboard with User Story
• Wireframe for Android apps design
• Product Breakdown Structure
• Work Breakdown Structure
• Radar Chart tutorial
• Creating Fishbone Diagram
• Customer Journey Mapping (CJM)
• Create stereotyped model element
• Bookmark shapes
• Select shapes with Handi-Selection
• Diagram annotation with layer
• Diagram Info Shape
• Appearance of stereotyped shape
• Tidy-up diagram with Sweeper/Magnet
• Convert model element's type
• Import Visio drawing as stencil
• Create Mind Map
• What is Mind Mapping? How to Draw a Mind Map?
• Edit model elements with Excel
• Associat parent & subdiagram flow
• Listing elements with grid
• Ad-hoc idea capturing with Brainstorm Diagram
• Identify use cases from BP process
• Refactor classes to ref. project
• Create project reference
• Create nickname for multi-name set
• Animating Sequence Diagram
• Organize domaing and impl. model
• Align business goal & logic with Decision Table
• Decision Table in-action
• Discover business logic with Decision Table
• Sensible business with Decision Table
• Decision Table in EA
• Using Matrix Diagram
• Using Analysis Diagram
• SWOT Analysis Tutorial
• Five Forces Analysis Tutorial
• Agile Requirements
• Add classes to flow-of-events
• Advanced use case flow-of-events
• Test procedures in flow-of-events
• Produce use cases from BPD
• Agile Scrum Tutorial
• User Story - Confirmation items
• Mapping BPMN with User Stories
• Using Storyboard
• Using tag on user story
• Model business goals of a system
• Using UeXceler - YouTube example
• Writing effective use case
• Generate Seq. Diagram from user story
• Generate Activity Diagram from user story
• Code & DB
• Generate ERD from RedShift DB
• Generate RedShift DB from ERD
• Compare logical and physical ERD
• Design & generate SQL Server DB
• Generate ERD from DDL
• Generate DB spec. from DB
• Keep data dict. in-sync with ERD
• Database design with ERD
• Edit nullable column in ERD
• Insert sample data into ERD
• Model RDBMS with ERD
• Generate class diagram from ERD
• Oracle DB design tool
• Oracle DB design with ERD
• Mass edit DB design with Excel
• Oracle DB reverse engineering
• Generate DB change script
• Compare DB schemas visually
• Define custom implementations for ORM Class
• Hibernate ORM in Eclipse
• Using Hibernate Criteria
• Generate Hibernate mapping for Oracle DB
• Java round-trip engineering
• C++ round-trip engineering
• Generate code from State Machine
• REST API - Twitter example
• REST API - Simple Reg. example
• Form Seq. Diagram from Java
• Hibernate ORM in NetBeans
• Visual modeling in NetBeans
• UML modeling in Eclipse
• C# round-trip engineering
• Generate C# from UML in VS
• Generate Java from UML classes in NetBeans
• Keep code and UML model in-sync in Eclipse
• Task Management Guide
• Share & review process design
• Share & discuss BPD online
• Prioritize tasks in Tasifier
• Storing reference files in project
• View and Revert changes with Visual History
• Communicate process design with PostMania
• Communicate software design with PostMania
• Concurrent process modeling
• Create Use Case report
• Create software req. spec.
• Customize Doc. Composer templates
• Maintain project of glossary
• Maintain glossary for terms
• Build glossary from class model
• Extract glossary from BPMN process
• Extract glossary terms from shapes' name
• Track occurrence of glossary terms
• Derive use case from terms
• Derive data dict. from Textual Analysis
• Generate RACI from BPMN
• Customize RACI chart
• Develop Visual Paradigm plug-in
• Change application's font settings
• Hide-away toolbar buttons

I am extremely pleased in both its ease of use as well as its breadth of features. Of particular value to me is the Textual Analysis tool.

Prof. William Burrows

University of Washington, Seattle

Turn every software project into a successful one.

We use cookies to offer you a better experience. By visiting our website, you agree to the use of cookies as described in our Cookie Policy .

© 2024 by Visual Paradigm. All rights reserved.

• Privacy statement

Home » DFD » Comprehensive Guide to Data Flow Diagrams (DFD): Demystifying Information Flow

Comprehensive Guide to Data Flow Diagrams (DFD): Demystifying Information Flow

• Posted on October 10, 2023
• / Under DFD

Introduction

Navigating the labyrinth of complex systems demands a beacon of clarity, and that’s where Data Flow Diagrams (DFD) come into play. In this comprehensive guide, we will delve into the depths of DFD, offering not just examples but a detailed exploration of its components, rules, advantages, disadvantages, and a step-by-step tutorial.

Understanding Data Flow Diagrams (DFD):

At its essence, a Data Flow Diagram is a visual representation of how data moves within a system. It serves as a dynamic map illustrating the input, output, sources, storage, and destinations of data within a system. The key elements of a DFD are:

• Processes: These are the core activities within the system, ranging from simple tasks like data collection to complex processes such as generating comprehensive reports.
• External Entities: These are the sources or destinations of information that interact with the system, including individuals, organizations, computers, or other systems.
• Data Stores: Repositories where data is held, representing information that is static and not in motion.
• Data Flows: These illustrate the movement of data between external entities, data stores, and processes, mapping the paths data takes within the system.

Symbols Used in DFD:

To bring the elements of a DFD to life, symbols such as those from the Yourdon and Coad system are employed, simplifying the creation and understanding of these diagrams.

Rules and Guidelines for Crafting DFD:

Creating a coherent and intelligible DFD requires adherence to certain rules:

• Process Flows: Each process must have at least one outgoing and one ingoing data flow.
• Data Store Connectivity: Data stores should have at least one incoming and outgoing data flow.
• Entity-Process Link: Entities must be connected to a process by a data flow.
• Avoiding Crossings: Data flows cannot cross with each other.
• External Entity Access: Data stores cannot directly connect to external entities.

Advantages and Disadvantages of DFD:

Understanding the pros and cons of DFD is essential:

Advantages:

• Graphical Simplicity: A visually intuitive technique, easy for stakeholders and users to understand.
• Detailed View: Provides an in-depth view of system components and boundaries.
• Functional Breakdown: Illustrates a functional breakdown of the system, showcasing how different components interact.
• Documentation Value: Serves as a valuable part of system documentation.

Disadvantages:

• Time Consumption: Creating DFD can be time-intensive.
• Timing Information Gap: Lacks information about the timing, sequence, and synchronization of processes.
• Non-Technical User Challenge: Might pose a challenge for non-technical users to comprehend the diagram.

DFD Examples:

This high-level overview uses a single process to represent the entire system’s functions. An example for a Clothes Ordering System is illustrated below:

Steps for Creating Context DFD:

• Define the process.
• Create a list of external entities.
• List data flows.
• Draw the diagram.

Breaking down the main process into subprocesses and including data stores, the Level 1 DFD offers a more detailed view. Example:

Steps for Creating Level 1 DFD:

• Define processes (main process and subprocesses).
• List external entities.
• List data stores.

Creating Data Flow Diagrams:

Visual Paradigm is an excellent choice for creating Data Flow Diagrams (DFD) due to its versatility, user-friendly interface, and availability in both online and desktop editions. Here’s why Visual Paradigm stands out as a top recommendation:

Visual Paradigm: A Comprehensive DFD Tool

1. versatility:.

Visual Paradigm supports a wide range of diagram types, making it a comprehensive solution for various visual modeling needs. From DFDs to UML diagrams, it covers a diverse spectrum of diagramming requirements.

2. User-Friendly Interface:

Whether you are a seasoned professional or a beginner, Visual Paradigm provides an intuitive interface that simplifies the process of creating complex diagrams. The drag-and-drop functionality and customizable templates make it easy to craft visually appealing DFDs.

3. Online and Desktop Editions:

Visual Paradigm offers the flexibility of both online and desktop editions, allowing users to choose the platform that best suits their preferences and needs. The online edition enables collaborative work, while the desktop edition provides offline capabilities.

4. Free Version Availability:

While Visual Paradigm offers premium features in its paid versions, it also provides a free version with essential functionalities. This makes it accessible to users with varying budget constraints while still delivering a powerful diagramming experience.

5. Real-Time Collaboration:

The online edition of Visual Paradigm facilitates real-time collaboration, allowing multiple users to work on the same project simultaneously. This is particularly beneficial for teams working on complex systems that require collaborative diagram development.

6. Extensive Documentation and Tutorials:

Visual Paradigm provides extensive documentation and tutorials, making it easier for users to learn and make the most of its features. This support is valuable for both beginners and advanced users seeking to explore the full potential of the tool.

7. Integration Capabilities:

Visual Paradigm integrates seamlessly with other tools and platforms, enhancing its utility in diverse development environments. Whether you are working with version control systems or project management tools, Visual Paradigm can fit into your workflow.

How to Get Started:

• Visit the Visual Paradigm Website: Go to the Visual Paradigm website and choose the edition that suits your needs (online or desktop).
• Download and Install: Download and install the desktop edition or access the online edition through your web browser.
• Create a Free Account: If using the online edition, create a free account to get started. If using the desktop edition, follow the installation instructions.
• Explore Templates and Features: Visual Paradigm offers a variety of templates for DFDs. Explore these templates and start creating your Data Flow Diagram.

In addition to the context and Level 1 DFD, there are deeper levels (Level 2 and Level 3) that provide a more intricate understanding of system dynamics. While DFD creation might demand time, its indispensable value in expressing and communicating crucial information within business processes cannot be overstated. From customer ordering systems to intricate banking processes, DFDs stand as indispensable companions in our data-driven decision-making journey. Understanding the intricate flow of information within a system is pivotal for optimizing processes and making informed decisions, and Data Flow Diagrams serve as the compass in this voyage.

Visual Paradigm emerges as a robust choice for individuals and teams seeking a versatile, user-friendly, and free DFD tool. Its availability in both online and desktop editions ensures flexibility, while its rich feature set and collaborative capabilities make it an invaluable asset for system modeling and diagramming needs.

Leave a Comment Cancel reply

You must be logged in to post a comment.

• Visual Paradigm Online
• Request Help
• Customer Service
• Community Circle
• Demo Videos
• Visual Paradigm
• YouTube Channel
• Academic Partnership

The Community

Modern analyst blog, community blog.

• Member Profiles

Networking Opportunities

Community spotlight, business analysis glossary, articles listing, business analyst humor, self assessment.

• Training Courses
• Organizations
• Resume Writing Tips
• Interview Questions

Let Us Help Your Business

Advertise with us, rss feeds & syndication, privacy policy.

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.

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.

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"

Related Articles

Article/Paper Categories

Upcoming live webinars, ace the interview.

Roles and Titles

• Business Analyst
• Business Process Analyst
• IT Business Analyst
• Requirements Engineer
• Business Systems Analyst
• Systems Analyst
• Data Analyst

Career Resources

• Interview Tips
• Salary Information
• Directory of Links

Community Resources

• Project Members

Advertising Opportunities  | Contact Us  | Privacy Policy