Tom Hathaway - Data Flow Diagramming by Example: Process Modeling Techniques for Requirements Elicitation

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.