A Data Flow Diagram (DFD) is a phenomenal tool for visualizing and analyzing business processes and workflows by studying how business data is created, consumed, stored, and transported. This lecture describes the purpose and use of business Data Flow Diagrams (DFDs). At the end of this lecture you will understand how DFDs are an excellent tool for identifying Stakeholder, Functional, and Data Requirements.

Use a Data Flow Diagram to represent the current workflow and easily recognize disconnects. Comparing an "as-is" DFD with a proposed "to-be" DFD facilitates Gap Analysis. You can create a DFD for many reasons but the main purpose is to have a visual representation of a business process or workflow.

A Rigorous Physical Process Model (RPPM) is an easy-to-learn first step into the world of Data Flow Diagramming, Business Process Analysis, and Workflow Analysis. This lecture will address what a Rigorous Physical Process Model is, what it represents, and why you need one.We introduce the simple technique of identifying stakeholders based on sample interview notes from a project sponsor.

Creating a Rigorous Physical Process Model is a step by step process based on the analysis of any information you have available (e.g. interview results, procedure manuals, help- facilities, etc). We present this simple concept using the interview notes with identified stakeholders from the previous lecture. The end result will be an easy-to-read RPPM that follows the natural top-to-bottom, left-to-right flow of English-speaking readers.

This lecture explains the difference between a Rigorous Physical Process Model (RPPM) and a Context-Level Data Flow Diagram (DFD). It introduces a simple yet powerful technique for converting any RPPM to a legitimate DFD and explains why this conversion is necessary.

An old English idiom states, "The Devil is in the details". A Context DFD presents only the big picture view of your project.This lecture introduces the concept of levelling or exploding individual processes on a Data Flow Diagram to depict increasing levels of detail and explains why this step is critical.

Before you can explode a high-level process, you need to identify the detailed processes that you could use on a lower level Data Flow Diagram. We present a simple business analysis technique for identifying potential internal processes expressed in verb-object format (e.g. Enter Orders, Verify Credit, Ship Goods).

The technique introduced in the previous lecture can lead to an overwhelming number of candidate processes for a lower level DFD. Ideally, the ensuing diagram should contain 5-9 processes. Here, we present 2 additional simple rules designed to ferret out the "right" processes for inclusion at the next level of detail.

Ensuring that two levels of a Data Flow Diagram are balanced can be a time-consuming process. The payback for this time investment can be the discovery of missing data and processes that could endanger the project. Start by proving that all dataflows at the higher level are addressed at the lower level.

Once you know that the lower level diagram contains all flows form the higher level, you need to prove that all dataflows entering or leaving the lower level are addressed at the higher level. This step can verify or challenge the scope of your project.

Solution Providers need details at the Functional Primitive level that are not easily expressed using just the symbols of a DFD. This lecture introduces Decision Tables, Structured English, and Business Rules as options for documenting detailed process specifications.

Beyond process specifications, Solution Providers also need details about the individual Data Elements that are not easily expressed using the symbols of a DFD. This lecture introduces Metadata and provides several examples using a simple spreadsheet for managing metadata.

By mitigating the risk of missing data, Horizontal Balancing addresses one of the most costly errors made on IT projects.But what is Horizontal Balancing?

This lecture demonstrates a business analysis technique for discovering data elements that are easily overlooked. We present a simulated interview with a Subject Matter Expert (SME) to explain what questions to ask and how to document and verify the results.

For smaller or Agile projects, developing and analyzing a completely level-balanced set of diagrams can be overkill. A DFD can still be valuable for those projects if you focus on just a single piece of the overall process and develop a Data Flow Diagram fragment.

Workflow Analysis Techniques are simple-to-use overlays that add business value to your dataflow diagram by showing you and your domain experts where problems originate. They also assist in guiding a group discussion around potential solutions.

Creating an overlay of business problems on a dataflow diagram lets you and domain experts visualize where the problems occur. You can them trace the problem's origins by backtracking along the flows until you discover the real cause. That will help you define requirements for a future solution.

Example showing how dataflow analysis overlays problem statements onto a diagram to guide discussions around the causes of business problems.

This lecture describes how  business analysts and product owners can better visualize timing problems in a workflow using a DFD

This lecture demonstrates how timing analysis helps domain experts and business analysts visualize the timing of a workflow to reveal timing anomalies.

Get better organized by focusing on bottlenecks to improve your productivity. This technique makes it easier than ever to quickly figure out which parts of your workflow are causing problems. It will guide you to better requirements for future digital solutions.

Seeing is more potent than describing. See how Error and Exception Analysis help all stakeholders direct their attention to how the current digital solution handles errors and exceptions. IT leads to improvements in the overall workflow.

This lecture explains how workflow analysis leads to improved requirements and user stories. An organization's success is dependent on its ability to evolve the right capabilities to fulfill its mission. Start with requirements that define requirements for acquiring those capabilities.

When it comes down to it, there are two major points to consider when deciding whether or not to remove a feature, function, or behavior. The cost of providing the given feature and customer feedback. The visualization provided by workflow analysis helps you make the right decision.

Requirements that specifically AFFIRM current or AVOID potential features are those requirements that are all too often overlooked. Use these words to make sure that you don't introduce features that the users won’t find useful while minimizing superfluous features and ideas.

As this course demonstrated, developing and leveling Data Flow Diagrams is a very rewarding experience for all involved. We hope you enjoyed the course and that you will be able to use this phenomenal business analysis technique on future projects.