The Data Flow Diagram, along with the Data Dictionary, were key components of projects in the 80's. With the advent of client/server, object-oriented analysis and design, and UML, they fell a bit out of favor. And with today's webapps and agile methods -- where the focus is taken off up-front planning -- they are often skipped. However, there are applications today that could benefit greatly from Data Flow Diagrams, specifically, Data-as-a-Service with its emphasis on back-end processing and data transformation.
I've found the Data Flow Diagram (DFD) to be very useful in these types of projects because they are easily understandable by all of the project stakeholder, technical and non-technical alike.
What is a DFD?
A DFD is a diagram of processes that work with data in datastores. Processes will sometimes interact with external systems. Processes can interact with each other. The symbols involved with a DFD are simple and listed below.
For more complete instruction on DFDs, read Tom DeMarco's 1979, "Structured Analysis and System Specification".
- Circle. A process
- Square. An external interface
- A line or arc with arrow termination. A data flow
- A top line and bottom line. A datastore
The simple symbology of a DFD makes it shareable among all of a project's stakeholders. And this is not documentation simply for posterity. It's ease of communication makes it ideal in all of the supporting activities in a software project like project management, configuration management, and systems design.
Look for a following post for a DFD example.
This post is replicated from http://my.opera.com/walkerca/blog/2010/12/12/documenting-daas-bring-back-the-dfd.