Structured analysis
Structured analysis, pioneered by Tom DeMarco (Yourdon Inc.) & Larry Constantine, or Chris Gane & Trish Sarson, and a couple of other methodologists, dates back to the 1970s. Three core techniques of this method are:
- Top down analysis, breaking down a system into smaller parts
- Modeling the data flows between the system parts or with external "entities"
- Maintaining in parallel to the data flow a comprehensive data dictionary. At the end of the analysis, you could just use it to implement your database, if you didn't already use ERD which was also a technique born in the 70s.
Structured analysis was state of the art and helped to make really complex systems methodically. I was myself a big fan, and my first project as an intern was to write a DFD modeling tool. However, it leads mechanically to a big upfront design.
Using DFD independently from SA
As many diagramming technique, you can use the DFD diagramming technique in your own way, as suits your needs. You can certainly use it to sketch easily some quick diagrams to support discussions in an agile team.
However, DFD is build on separating data (the arrows) from the processes (the boxes or circles). This is useful for designing databases. But nowadays we tend to use objects, which are data + behaviours, so the distinction becomes more fuzzy.
On top of that, DFDs are not standardised. There are at least 2 main notations, but many more variants. This can create confusion and ambiguity. Last but not least, the flows in these diagrams are always simple: you can for example not show that data may be dispatched between several processes, or that several processes run in parallel with the same data.
More modern alternatives
If your problem/design is simple enough for being modelled with a few circles and lines with DFDs, chances are that you can as easily model them with a few rounded rectangles and lines in activity diagrams.
Activity diagrams have a higher standardization than DFDs. there is only one notation and it allows a high degree of accuracy when needed. The key features are:
- activities correspond to processes
- flow between actions can be either control flow (without data) or object flows
- datastores correspond To datastores/sources/sink
- there are no "external entities" but these can easily be emulated with swimmlaneg, and sterotypes/symbol on some program activity
- if needed, you can show filtering and conditional routing, timeouts, parallel flows, etc.
There is no top-down incentive. While DFDs often rely on decimal hierarchical numbering of the processes and the diagrams, in UML diagrams are not supposed to be a single complete truth. They are supposed to show only a selected set of elements useful for the discussion.
Another candidates for data flows is BPMN which as process modeling notation is very appropriate for showing flows, including of information. It has the advantage of being standardised as well. A study nevertheless found out that it is more complex to understand for laypersons than equivalent activity diagrams, due to the higher number of symbols required by BPMN.
What is more agile?
We must not confuse the tools with the way the tools are used. It is true that DFDs are closely linked to SA and UML is methodology neutral (just a notational language). Some agilists promoted activity diagrams on the whiteboard in an agile fashion.
But in the end, both tools can be used in an agile context, and in a light and easy way (You don't have to use all the bells and whistles of UML, just the ones that help you). I can only recommend the more standardised technique.
