Data Flow Diagram: A Practical Guide
/ Stephanie FamuyideDATA FLOW DIAGRAM - Includes Free Template
If you have a massive and complex project with many entities, data, data sources, data destinations and processes going on, a data flow diagram is one of the most effective ways of making sense of all that data. The diagram mostly concerns itself with the flow of data through the system.
The DFD focuses on “what” the system will accomplish and not the “how” of it. It does not provide any information on the timing of information flow in the process or the sequence of activities – It is popularly used in Structured Systems Analysis and Design.
There can be as many levels to a DFD as possible – it depends on the level of granularity you’re trying achieve.
Diagram Notations:
- Gane & Sarson
- Yourdon & Coad (Shown below)
PRACTICAL APPLICATION
- List all the external entities that provide inputs to the system or receive outputs from the system
- Identify and list inputs from and outputs to external entities
*These first 2 steps will give you the context diagram*
- Identify all data that passes through the system
- Identify the origin and destination of these data
- Identify the processing that these data go through (processes)
- Identify the means of data storage
- Identify data connections from one process to another
- Identify data connections from processes to the data store(s)
GENERAL RULES
- Don’t let it get too complex; 5 - 7 processes is a good guide
- Number the processes – though the numbering does not necessarily indicate sequence, it’s useful in identifying the processes when discussing with users
- Re-draw as many times as you need to so that it all comes out neat
- All data flows should be appropriately labelled
- Data stores should not be connected to an external entity – because 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
- No two data flows should have the same name
- Data flow arrows should point in the direction of the flow
- A data store must be connected to a process
- There should be a minimum of one data flow in and out of a process
- An external entity must be connected to a process
- Watch out for black holes – a process that has inputs but no outputs
- Watch out for miracles – a process with no inputs but visible output
- Process labels should be verb phrases; data stores are represented by nouns
Context Diagram (Context-Level DFD)
Think of your software system or project as a central entity affected by external agents or external entities. The objective is to show all the entities outside your system that interact with it, either by receiving data from it or transmitting data to it. It reveals nothing on internal processes. An example of a context diagram is shown below for a Supply Chain Management System:
DFD-Level 0
This diagram contains everything in the context diagram but also includes the major processes as well as the data flows in and out of them. The objective is to achieve a higher level of granularity. The processes illustrated here can be decomposed into more primitive/lower level DFDs.
DFD-Level N
This is where you take each process, as necessary, and explode it into a greater level of detail, depending on your preferred level of granularity. For example, DFD-Level 1 could focus on decomposing one of the processes in the Level 0 diagram into its subprocesses. For example, If we take Process 4.0 - Procure Raw Materials, it can be decomposed further into 4.1 - Aggregate Raw Materials, 4.2 - Place Order, 4.3 - Record Shipment Details and so on. If necessary, we can decompose 4.3 further into subprocesses, thereby creating a DFD-Level 2; the resulting processes would be labelled: 4.3.1, 4.3.2, and so on.
Also, see Lucidchart's detailed explanation of what a Data Flow Diagram is.
For more information on how to create a Data Flow Diagram - Download Ed Yourdon's book on DFD which will take you through DFDs from the fundamental aspects to the detailed.
Download the template I used here - It's in Visio XML format and can be imported directly using Microsoft Visio. Systems Analysis & Design in a Changing World also contains an explicit illustration on how to create data flow diagrams. The chapter on DFD is available for free here.
Data mining can be described as the process of improving decision-making by identifying useful patterns and insights from data.
A data dictionary holds data about the fields in a database, such as field definitions, meanings and allowable values that reflect how data is used within a domain or organization.
Are you a business analyst involved in the documentation of business rules and creation of complex decision tables?
A concept model provides a great way of documenting definitions and communicating precise meanings of terms to stakeholders.
Employing the user journey mapping technique involves adopting a user-centric approach to product design, revealing opportunities to delight customers and identifying pain points that can be addressed thereby creating a product with an improved user experience.
Within the context of agile software development, the product backlog is a platform where all the potential work (product backlog items) that need to be delivered are recorded, tracked and prioritized. Though owned by the Product Owner, anyone may suggest items to add to it.
Failure Mode and Effects Analysis (FMEA) is a proactive technique that can be applied to the early detection of failures or defects in products and services. It is a systematic risk assessment process used by analysts looking to reduce the chances of faults by detecting problems and their possible repercussions in time for remediation.
If you are in business, here is a brief overview of how cause and effect analysis helps you find viable business solutions. Guest post by Lucas Cappel.
A roles and permissions matrix, an audit requirement in some organizations, is used to ensure that business activities are covered by identifying the responsibilities and roles linked to them.
Business Process Model and Notation (BPMN) is a global standard for constructing process models, with more organizations using it and schools teaching it as a subject.
The terms “Quality Assurance (QA)" and “Quality Control (QC)” can be confusing or even misunderstood to mean the same thing. In this article, the goal is to clarify the real meaning of the two terms and explain their differences.
Network analysis is defined as the process of “breaking down a complex project’s data into its parts (activities, events, durations, etc.) and plotting them to show their interdependencies and interrelationships.”
The textual representation of a use case shows the interaction between the actors textually and at an appropriate level of detail. There are several set elements that every textual representation of a use case should contain:
Originally released in 2005 by BPM Group, the 8-Omega framework has been adapted and embraced by a large number of organizations around the world for the improvement of business processes.
Requirements scope statements are defined later in the project life cycle and are relatively fluid. As long as they still fall within the boundaries set by project scope statements, they can be updated and modified to reflect the changing needs of the project.
The SCRS approach encourages analysts to present practical and feasible business solutions that flow from the current strategy and are in tune with the business’ overarching vision and goals. Think of SCRS as an action plan for solving business problems.
Process performance metrics generate accurate data, bringing more efficiency and effectiveness to the decision-making process. The data generated by process performance metrics can be aggregated and displayed on a unified dashboard to provide a panoramic overview of the company’s performance.
When deciding between different designs, you want to base your decision on rational arguments instead of subjective preferences. One methodology for establishing a procedure to select the best option from multiple available options is Pugh Matrix, also known as the decision matrix.
Consequently, systems developed using the traditional approaches to software development are rigid and difficult to change. It’s often necessary to modify a large number of parts of the system just to implement a single, small change. The traditional approaches to software development are effective only in situations where requirements are specific and unlikely to change over time.
One increasingly popular method for breaking down a process into smaller and more easily understood parts, which this article will focus on is called ICOR, which stands for Inputs, Outputs, Controls, and Resources.
The essence of VPEC-T analysis is to provide a collection of mental filters and guides. Together, they provide a simplified communication method that prevents loss in translation from business needs to IT solutions.
A control chart can be used to monitor processes for problems and to determine whether a process has become stable enough. As an analysis tool, it can be used to detect when problems occur and propose possible causes and solutions via an extensive root cause analysis exercise.
Some processes, problems, and projects appear complicated, yet their complexity disappears as soon as one takes a closer look and breaks them down into simpler parts. This is the objective of functional decomposition - to clarify how the overall functionality emerges from the interaction between individual components in increasing detail.
The key importance of problem tracking is seldom evident when there are just two or three problems to overcome at the same time; it doesn’t take much to stay organized in such situations. It gets much more complicated, however, when the number of problems increases, especially in the early phases of software development projects.
In a perfect world, our plans would always go according to our expectations, and nobody would ever make a wrong decision. Sadly, we don’t live in a perfect world, and things don’t always go according to plan. Knowing that mistakes are inevitable, the question is how to improve our practice or reduce those mistakes the next time we get an opportunity.
There are some major tell-tale signs to look out for when improving processes. These trouble spots exist to varying extents in most poorly-performing business processes. The objective of any improvement effort is therefore to minimize these as much as possible to ensure that affected processes perform as efficiently as possible and deliver value to the business.
The most obvious benefit of gathering stakeholders with different backgrounds in a single room is the increased chance of spotting defects in requirements before development or implementation begins. Structured walkthrough sessions also raise awareness about the different development or maintenance methodologies.
State diagrams typically describe the states of an object, the transitions between the different states and the events that trigger those transitions. Thinking through objects in a system and their respective states can also help to identify missing requirements.
A problem statement defines the problem being faced by a business and also identifies what the solution would look like.
It can be seen as the starting point for coming up with a product vision. In defining the problem statement, be sure to include these elements:
This technique is also known as “Item tracking” or “Issue Tracking" and it covers the supervision of defects, assumptions, actions and issues until they are resolved. It provides an opportunity for stakeholders to rank the importance of issues affecting them.
User story maps are an interesting and collaborative way of eliciting user requirements. One of the reasons why I find it so powerful is because it provides a unique approach for aligning discussions relating to the user, their goals, the process that supports the accomplishment of their predefined goals; and the requirements that need to be addressed to solve business problems.