Amitesh:

Data flow diagrams are technology independent: batch processing, web middle-tier, whatever.   Whenever the system needs to be conceptually viewed as as series of input-process-outputs, then Data Flow Diagrams are what you want to use.   This is especially true for larger scale efforts.    As data inputs and outputs define a process, I really don't see the applicability of  process definition techniques that don't focus on data flows.

Problem with DFD's:  There construction often requires the very strong negotiating skills and a very "thick skin" (i.e., high tolerance for personal rejection).

Tony

Craig:

Properly used, data flow diagrams get to the essential "as-is" very quickly.   Problems in doing such (that necessitate the need for a thick skin):

1.)  Knowledge of essential procedure is often turf, and people will defend their turf to the death.   As I am currently using dfd's for business process re-engineering that will result in alot of outsourcing, I see this often.   The issue also exists in "regular" software projects.

2.)   Many times, the those who are charged with knowing the essential "as-is" in their scope of responsibility really don't  have anywheres near the comprehensive, integrated understanding that they need to.   Anything, such as dfds, that can highlight  these problems is going to be resisted.

3.)  Creating and verifying an as-is is negotiating with all concered largely the way things will be.  Again, turf considerations come into play.

4.)  Don't discount that, properly using dfds requires an often radical approach to requirements elicitation that others, including management do not understand.    Often, for example, management does not understand the concept of delaying consideration of implementation detail until the appropriate time, becase they have never been such focused themselves.  There are books written about the problems of introducing significant change in an organization.  

Tony