Back to List

How to Use Data Flow Diagrams to Model and Analyze BI Requirements

Rachael Wilterdink Rachael Wilterdink  |  
May 16, 2019
 
If you’re involved in eliciting, modeling, analyzing, or consuming requirements for BI projects, this post is for you. Over the next several months, we will be releasing 10 Techniques for Business Analysts (BAs) to model and analyze Business Intelligence (BI) requirements on our blog.
 
The third technique in this blog series is Data Flow Diagramming. This is one of my favorite techniques for scope definition.
 

What is a Data Flow Diagram?

The technical definition of this technique from the International Institute of Business Analysis (IIBA®) is: "Data flow diagrams show where data comes from, which activities process the data, and if the output results are stored or utilized by another activity or external entity.” – BABOK® v3.0
 
These types of diagrams simply depict the sources of data, what happens to the data, and where it goes to be used.
 
Data Flow Diagrams show:
 
  • Source – where the data comes from
  • Activities – what happens to the data
  • Inputs/Outputs – what goes in, and what comes out
  • Transformations – any changes that take place to the data
  • Temporary or permanent repository locations – where the data lives
 

What are the Elements of a Data Flow Diagram?

  • External components:
    • Entity – person, system, device
    • Source – when the data comes from
    • Sink – where the data goes
  • Data Stores – data at rest
  • Processes
    • Manual, or
    • Automated
    • Data Flow – holds processes together
 

What are the Levels of Abstraction?

There are multiple levels of abstraction possible using data flow diagrams. Level 0 is great for identifying scope, and the other levels are great for going into more detail about the movement and processes of data.
 
Level 0 – (aka Context Diagram) often used to depict scope
 
context diagram
Example from: “Business Analysis for Practitioners, a Practice Guide”, published by PMI®

Levels 1+ - breaks down the major processes from a Level 0 diagram. These include the additional element of data stores.
level zero diagram
Example from: “Business Analysis for Practitioners, a Practice Guide”, published by PMI®
 

Pros

I know I am a little bit biased, but I love this modeling technique. It’s really easy to create, and it’s also easy for business people to understand. The notation set is very simple, and it requires little to no explanation. The model also really helps you understand what is happening in a system, and it is a great source of identifying gaps in your requirements.
 

Cons

Depending on how large your project is, this type of model could become too large and unwieldly fairly quickly. If it does get too large, it would be advisable to split it into smaller components that can be combined to depict a whole system.
 
Another con with this technique is that it does not show the details of the data – this is often included in a data dictionary, necessitating two different techniques being used.
 
One other con of this technique is that it doesn’t necessarily show the actors in the flow of data, it’s primarily a system-to-system look at where the data comes from and where it goes.
 

Conclusion

Data modeling is a great tool to help you discover your scope and identify gaps, and it is easily understood. However, it doesn’t dig into the details, so it must be supplemented with other models. This technique is especially useful in Business Intelligence projects, or any projects that are data heavy (which is pretty much all software development projects).
 
Next in my blog series: Data Modeling.
 

Free Agile Resources


References:
“IIBA Home.” IIBA | International Institute of Business Analysis, www.iiba.org/.
“PMI.” PMI | Project Management Institute, www.pmi.org/.
 
Business AnalysisBusiness Intelligence

 

Love our Blogs?

Sign up to get notified of new Skyline posts.

 


Related Content


Blog Article
Agile Story Splitting by Capabilities/User Goals & Workflow Steps
Rachael WilterdinkRachael Wilterdink  |  
Feb 18, 2020
In this blog series, Rachael Wilterdink (CBAP, PMI-PBA, PSM I, CSM) dives into 25 different techniques for approaching story splitting that she has used throughout her career. Make sure to subscribe to our blog or stop by each week to catch all 25!   #1 - Capabilities/User Goals ...
Blog Article
How to Identify Good and Bad Agile User Stories
Rachael WilterdinkRachael Wilterdink  |  
Feb 11, 2020
If you read my previous blog, you’ll know the basics of a User Story. But what makes for a good or bad agile user story? In this blog, I’ll cover the criteria that will help you identify one from the other.   What Makes a Good User Story? The most common checklist that is...
Blog Article
What are Agile User Stories and Why Should You Split Them?
Rachael WilterdinkRachael Wilterdink  |  
Feb 04, 2020
Story splitting is one of the most deceptively difficult skills to master in agile. It sounds so easy, “Let's just a break a big story part into smaller pieces.” But as easy as it sounds, I struggled with it when I first transitioned to agile. I have since seen many other teams...
Blog Article
4 Agile Transformation Pain Points with Managing Work
Rachael WilterdinkRachael Wilterdink  |  
Jan 28, 2020
In this blog, Rachael Wilterdink, CBAP®, PMI-PBA®, CSM®, PSM, pulls from her extensive experience to guide professionals along their agile journey. For a full overview on this topic, download her eBook: 20 Advanced Agile Transformation Pain Points.    As a Business Analyst with...
Blog Article
How to Form an Effective Agile Team: The Experts' Guide
Brian LaehnBrian Laehn  |  
Jan 21, 2020
In this actionable guide, Brian Laehn distills his 20+ years of experience as a Senior Business Analyst, Scrum Manager, Project Manager and Agile Team Lead.   Has your organization identified the need to create a new project team? You may be wondering what the best way is to form this new...