Nicole:
Especially for enterprise wide efforts, there logically is no alternative to DFDs. For such efforts, in order to handle the complexity, you need to model both at the high level as well as the detail level. If you stay just at the detail level you will drown in an ocean of details.
A key issue is that at higher levels of abstraction, systems are very non-sequential: processes can happen all at the same time or in any order. Therefore, business process modeling techniques are not appropriate as they are based on identifying sequence. For higher level work, you need to follow the flow of data. (There are many other reasons why DFDs are unique for handling more complex efforts, but, I will not go into them here.)
BPMN trys to address this issue by incorporating flow of data as well as sequence/flow of control. However, it shows all these things (and others) all on the same diagram, and the point is soon reached where the diagrams get so complex the analyst can not tell where his/her mistakes are.
Use Cases can, in theory, be used to capture the non-sequential situations. However, they are essentially just poor-man's data flow diagrams, as they lack any serious integration capability.
What I do: Use DFDs for higher level work, and use BPM like diagrams for the detail level.
Nicole, Data Flow Diagrams are very hard to use. Just look at the BABOK 2.0 - not for what it says (it is impossible to understanding systematically what it says), but at how it is organized. The BABOK 2.0 is basically a functional spec on how to create a functional spec. So evaluate it as a functional spec created by the "experts". Notice how it is organized around data input/process/data output diagrams. That is becuase, the procedure that they are tryiing to describe is non-sequential. Unfortunately, the input/process/output diagrams are not integrated input/process/output diagrams - that is data flow diagrams. If the "experts" can not create data flow diagrams for complex specs - well, you now know what you are up against.
Reason DFDs are soo hard to use: They require asking too many questions - that is too much honesty. And analysts (or any one else for that matter) can only stand so much honesty before they completly rebel.
Tony