Data Flow Diagrams Alone?

That’s like cake without the ice cream, it’s just not right!

So the question has been asked “What are the weaknesses of using data flow diagrams as a modeling tool?” and my response to that question is an avalanche of probing questions.

• What constitutes a weakness?
• From what perspective are we viewing the item in question?
• Is that item really intended to be used in the manner we are trying to use it?
• Is the item’s intended use even applicable to what we are doing at the moment?

I find questions of weakness extremely interesting because the definition of weakness is always tied to the perspective of the one pointing out the supposed weaknesses. In addition, the perspective of that individual is always affected by whether or not they actually understand the intended use of the item they are calling weak. Even if the individual has a full understanding of the item and its use, have they actually stopped to consider whether or not the item and its associated use are even appropriate for the situation in which they are trying to use it?

Most of the time when I find myself defining something as weak it is because I either, do not understand fully its intended use, I am trying to use it for an unintended use, or I have not stopped to consider if I am even using the right tool for the job at hand. Rarely do we find a truly multipurpose tool in our belt, we usually need a toolbox to get the job done. We get the job done by using each tool as it was intended.

This brings us to data flow diagrams and their intended use. Simply put they are designed to allow us to visually represent all of the data inputs and data outputs of the various processes within our systems and at various levels of granularity (processes, sub-processes, etc…). Thats it, that’s all they are designed to do and when looking at them from their intended use (that perspective) I really cannot identify any weaknesses nor any real need for a replacement.

Now if I looked at them as though they were the only diagrams I was allowed to create for my new systems, from a perspective that they were the one defining system document, can I find some weaknesses? You bet!  They are as follows.

DFDs do not provide:

• implementation details
• distinction between manual or automated processes
• chronological order of process execution
• timing of processes
• flow of control
• specifics linking the inputs to the outputs of the processes
• non-functional requirements
• user interface requirements
• business rules
• data relationships and the business constraints on that data

In programming we have a mantra which every good developer instinctively follows “Each method must do one thing and do that one thing well and thats all it should do.” The beauty of this statement is that it applies to pretty much everything in life, including analysis and design.

Data flow diagrams do the job of identifying the data input and data outputs of our system’s processes and they do it well, as they should. In that light each of the “weaknesses” identified above has its own modeling/diagramming methodology which effectively captures and records the information needed within its context.

In systems design we cannot rely on a single modeling approach to capture everything a system is or will be. This is because our systems are complex, layered, and partitioned into various complex pieces each of which belong to different disciplines guided by different methodologies.

What makes things difficult is the fact that all the pieces of our systems overlap and intertwine which, of course, causes the modeling methodologies to mix. As analysts I have found we attempt to force a single methodology to be the one glove fits all solution for modeling these extremely complex systems. This simply will not do.

I do not design my code utilizing the same modeling paradigms as a data modeler designs a database nor does the UX designer design her user interfaces using the same modeling paradigms as I. But through our joint efforts and the combination of our modeling methodologies, we build complex, amazing systems.

Sources/References

1. Kendall, K.E. (2011). Systems Analysis and Design.
Pearson Education, Inc., publishing as Prentice Hall