Hi:

I have had IT managers with graduate degrees in IT tell me that they don't understand DFDs and that, therefore, they can not see how anyone else can.  But I always remember the time when I was DFDing recieving operations at a factory.    I approached a receiving dock worker  who wore torn blue jeans and a T shirt with holes in it and transmission fluid stains.   When I tried walking through a DFD with him, he interrupted me and said "Thats not things are done here, let me show you how."   He then grabbed my DFD and with a red pen made major revisions to it.  My thought:  So much for graduate degrees in IT.

Properly drawn, (i.e., no more that 5 to 7 bubbles per diagram, each having no more that 5 inputs/outputs total) data flow diagrams are easy for an end-user to  understand.  The real issue is often that DFDs require much more work on the analysts part and such "raising of the performance bar" is often resisted.   Solution:  A strong, fervent, lead-by-example champion.

Tony

Roy,

Greetings!

Users do handle UML Activity Diagrams very well.

DFDs do not translate well into Use cases and vice versa. Case in point: The DFD decomposes into a Function that can no longer be decomposed. Some make this "primitive" function a Use Case. Martin Fowler wrote and article about this once ( cant find it now)

Here is another. Borrowing from Arlow and Neustadt (2005) “UML2 and the unified process”, the reasons for not using DFDs and Use Cases are:
• Rather than focusing on the “goals” of the actors, we structure the items in an artificial way.
• The model describes the system as a set of nested functions (which is what DFDs are).
• Only the lowest levels of use cases are “primitive” enough for interesting specifications.

Getting the IT dept to switch to SSADM will be challenging. Many of the graduates that I have trained have never used DFDs; and you can be assured that some of your IT Gurus have never encountered a DFD diagram.

DFDs still have a lot of traction out there and users do find the concepts "intuitive". All the best!

warm regards,

K

Roy:

DFDs require a much more fervent analyst than do use cases.   Really, use cases are essentially DFD's without the data flows  (use case "extends" and such to the side, as they are implementation oriented).   And ask any DFDr about the utility of a DFD without the data flows and answer is not pretty.  

Are use cases easy to walk through with end users?   Try explaining the interrelationships on a use case to a typical end user.   I have walked through data flow diagrams with all kinds of non-IT people.

Problem:  I doubt if a large group will buy into DFDs.

Tony