Data Flow Diagrams (DFD) Explained
We all happen to be in situations when we need to explain something a bit complicated to somebody without challenging the fabric of reality. It takes some time and a whole lot of effort and usually isn’t very helpful.
You try to break things down even more — into digestible bites, you try to elaborate on certain aspects, with extensive use of verbose out-there constructions — but it doesn’t really get anywhere further and adds more confusion instead.
In IT-segment — that is a relatively typical challenge, and there is a thing to deal with it. Data Flow Diagrams is its name.
What is Data Flow Diagram?
Data Flow Diagram is a type of diagram chart that shows the movement of information from one place to another as part of a particular processor in general. In other cases — DFD can show how different departments of the organization cooperate - it makes things clear and coherent.
The entire method was devised back in the 1970s as a mean to streamline documenting and subsequent presentation of the workflow processes.
Dataflow diagram was first described in a book by Ed Yourdon and Larry Constantine, “Structured Design.”
They took “data flow graph” models of computation of David Martin and Gerald Estrin as the foundation.
Other significant sources of inspiration were Object-Oriented Analysis and Design and Structured Systems Analysis and Design Methods.
The method was further perfected by Tom DeMarco, Chris Gane, and Trish Sarson, who devised a practical alphabet of symbols and notations for Data Flow Diagrams.
At this point, DFD is more or less replaced by Business Process Model and Notation aka BPMN and is rarely beyond showing the big picture.
However, Dataflow diagrams is a good entry point for those who starts studying Business Analysis and business process visualization.
DFD shows what goes where and how and explains how exactly something operates and what happens in the process.
Diagrams depict relationships between elements of the system in detail and an easy-to-follow manner.
There is an easy way of explaining what DFD is. It makes things much more explicit and coherent.
In Business Analysis - DFD is used for the assessment of existing and projected systems and its elements. Diagramming provides a useful toolset for exposing possible weaknesses and structural flaws.
In Software Development - DFD is used to explain and visualize the requirements of the projects — from the business perspective and a technical point of view. This feature allows hatching through and through step by step plan for the development of each element.
Data Flow Diagram can be a helpful and easy way for project owners to conceptualize their projects and think through every important detail.
It allows modeling of the processes on a different level and puts them into the perspective of the overall architecture of the project.
DFD is especially helpful in the initial stages of the project when elements of the processes are in the process of validation and settling down into the systems.
Purpose of DFD
Data Flow Diagram is designed to answer the question “how it works?” with a slight tinge of the KISS principle.
Data Flow Diagrams are incredibly useful tools for communication. It helps to provide an accessible insight for uninitiated.
The most common way using DFD is so-called multi-dimensional charting: with a gradual building of charts from the general overview to depictions of particular processes and elements of the system.
The visual component is crucial. Streamlining and transforming into the diagram gives a clear understanding of what is going on with the system.Because of easy to follow notation system, it allows digesting even the most complicated process and breaks them down into comprehensible charts.
That is the reason why it is one of the “weapons of choice” for business analysis. It makes the whole thing easy to chew both for specialized and non-specialized audiences — from developers to CEOs or customers.
How DFD works?
Data Flow Diagrams are built around a simplified system of notation that includes a set of rectangles and circles combined with arrows and sleek abbreviations that signify input, output, storage points, and routes between each destination.
All that aptly depicts “The Flow.”
Let’s break it down. There are four fundamental notation elements of DFD — so-called data items:
Process — represents any transformative process of the incoming flow of information into the outgoing workflow. The process receives input and generates an output;
Data flow — represents the movement of information within the system between external entities, data stores, and processes. Reflects the nature of the data used in the system;
Datastore — represents repositories for data that is not moving at the moment. It may be either a just in case buffer or queue for later use. Most commonly it is either database tables or membership forms;
External entity — represents sources or destination points of information outside the boundaries of the described system. Entities either provide data to the system or receive from the processes. EE usually resides on the edges of the diagram.
The designation of DFD visual elements is not strictly regulated. However, there are two commonly used versions of notation — DeMarco-Yourdon and Gane-Sarson versions. The differences are the following:
One of the most significant advantages of the Data Flow diagram is that it allows building multi-layered intricate depictions of every element of the system.
That, in turn, exposes the weak points in the process and enables them to correct them before development.
The description of the processes is informaly divided into several levels:
Level 0 or Context diagram — a basic overview of the system in general terms. It includes all components of the system. Usually presented to a broad audience — such as customers, analysts, and developers;
Level 1 — slightly more detailed version of Level 0. It can be dedicated to the depiction of specific elements of the system. The difference is in the breaking down of the items into sub-elements.
Level 2 — further detailing of the processes. It can relate to particular functions. Usually supplemented with extensive commentary to clarify individual bits;
Level 3 and beyond is further elaboration. It can be applied to specify a particular process through and through.
It is worth noting that, if necessary, each element can be a subject of its own DFD.
The accuracy of the data flow diagram is depends on the level of detail of the functional specification.
The process of composing