Data Flow Diagramming by Example. Process Modeling Techniques for Requirements Elicitation (2015)
Introduction to Data Flow Diagrams (DFDs) for the Business
Questions answered in this chapter:
§ What is a Data Flow Diagram (DFD)?
§ When do I need one?
Business Processes, Data Flows, and Value Chains
A picture really is worth a thousand words, especially in the world of Business Analysis for IT projects. Try to describe workflows or business processes in natural language and the chances that IT will deliver the solution you want are very small indeed. The challenge is what picture do you need to draw?
There are several techniques for drawing process models or diagrams at various levels of detail and each has a specific focus. Data Flow Diagrams (DFDs) represent the workflow or steps within a process with a focus on the flow and transformation of data. You can create DFDs at the business level (as in this example) representing business processes and business data or at the system level depicting IT applications, databases, and files. Since we are talking about business analysis, our focus will be creating and using data flow diagrams at the business level.
Every business process is a more-or-less complex sequence of steps that changes something coming in to create something new. As such, the process needs some form of input, which could be information or any other resource. By definition, a data flow diagram is a picture of how the depicted processes create, consume, transport, and store data. A DFD is the right choice for business process modeling if you need to understand the creation and use of data within the individual business processes. Those processes can be manual or automated; it does not matter as far as the diagram is concerned.
Processes use input to create output, whether the output is something altogether new or simply an altered version of the original input. Since the process adds some measurable value to the input, we often refer to the “value chain” of the organization.
Fundamentally, any diagram is simply a picture with constraints. In the case of the DFD, the constraints are which symbols you can use and what each symbol means. There are really only two widely used conventions for drawing DFDs and the differences are minimal. Both allow only four basic symbols.
A rounded rectangle (or a circle depending on which convention you follow) represents a process at some level of detail. The name of the process tells us what the process does (i.e., what its primary function is) in common business terms. Since functions are actions, the name consists of an active verb (what is done) and a direct object (what is it done to — e.g., PROCESS CREDIT CARD, SELL PRODUCT, CHECK ITEM PRICE).
As you can see from the examples, the named process can be at any level of detail, from the very high-level (SELL PRODUCT) to the very low-level (CHECK ITEM PRICE).
Processes Interact with Data
An arrow represents a data flow, meaning information coming from somewhere and going somewhere else. Because the data is moving from somewhere to somewhere, the arrow points in the direction of movement. Every data flow has to have a name. Because it represents data and data is a thing, the name has to be a noun with or without appropriate modifiers (i.e., Credit Card Authorization, Invoice, Item Number). As with the process, the named data flow can be at any level of detail.
A data store is simply data at rest. It is not going anywhere so it cannot be a data flow; it is waiting to be consumed by a process. A data store is not necessarily a file although a file is a data store (like a square is a rectangle but a rectangle is not necessarily a square). A special symbol consisting of a small square with the top and bottom lines extending outward to the right (or simply two parallel lines, again depending on convention) represents a data store.
A DFD Makes Scope Visible
A simple square (with or without an optional shadow) represents an external entity. In the world of data flow diagramming, an external entity represents a person, organization, or application that is out of scope for the project from the perspective of the DFD. Specifically, it implies that the represented object is not going to be analyzed or impacted by any project using this diagram although data flows to and from the external entity have to be analyzed.
Why Create a Data Flow Diagram?
A DFD serves multiple purposes. You might create one to be able to analyze the current situation with the goal of identifying roadblocks and improving efficiency. You might also create one to present and discuss the process with others. You could create a DFD of a proposed business process before you develop detailed processes and supporting IT applications to identify potential issues before they occur. Its principle use is presumably to identify, document, and communicate stakeholder requirements for an IT project.
Fundamentally, there are two good reasons why you need a diagram. First off, people can point to the diagram to discuss a process or flow instead of using words to describe what they mean. The diagram represents a visual mode of communication, which all studies show is much more effective than mere words. Pointing power proves that it works. Secondly, studying the diagram generates questions that might indicate missing steps or external entities. If the diagram piques your curiosity, it is well worth your while to investigate the situation to find an answer.