Learn about Data Flow Diagrams (DFDs), Context-level DFDs, and Rigorous Physical Process Models (RPPM), what they are, why they are important, and who can use them.
Getting from someone's explanations of how they do their job to usable and accurate workflow descriptions can be a daunting proposition. The course uses a concrete business scenario to present a simple, easy-to-learn approach for creating these diagrams from an interview with a Subject Matter Expert (SME). You will learn how to create a Rigorous Physical Process Model, evolve it to a Context-Level Data Flow Diagram, and explode the context-level process(es) and data to reveal the nitty-gritty detail (individual process specifications and detailed data specifications) that developers need.
The course answers the following questions:
Regardless of your job title or role, if you are tasked with communicating a workflow or functional requirements to others, this course will help. It is interactive (includes exercises with instant feedback), instructionally designed (based on modern learning theory), and "intellimated™" (uses animated visuals with an accompanying audio track) to hold your interest and increase retention.
Co-author Tom Hathaway presents an overview including the scope and purpose of the course "Data Flow Diagrams Simply Put!" and introduces the learning objectives. He also explains why he and his co-author Angela Hathaway are uniquely qualified for delivering this content.
A Data Flow Diagram (DFD) is a phenomenal tool for presenting and analyzing business processes 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.
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.
Tom has been in business analysis since long before it was called business analysis. He has over 30 years experience in the fields of information technology, methodologies, and business analysis. In his writings and lectures he strives for enlightening while entertaining. As a facilitator, he achieves results through inclusion and synergistic group-building. He has taught thousands of students business and systems analysis skills since the '80's and has facilitated hundreds of requirements discovery sessions under a variety of acronyms (JAD, ASAP, JADr, JRP, etc).
Angela and Tom Hathaway (previously Hathaway & Associates, Inc. and Requirements Solutions Group, LLC) founded BA-EXPERTS in 2011. As a team, Angela and Tom have trained, consulted, mentored and coached thousands of business analysts around the world for organizations from small businesses to Fortune 100. Hundreds of current and past customers include TIAA-CREF (Financial), Cathay Pacific (Airline), Manitoba Telecom Services (Telecommunications), Starwood Hotels and Resorts (Hospitality), government agencies, and a myriad of organizations spanning all sizes and industries. Our training, consulting, and mentoring efforts have saved our customers around the world millions and can help your organization improve its business analysis practices