Tony,
I have read your previous posts about control versus data flow. My first reaction these days after many discussions on methods is that, if your method is working for you, go for it.
Given that, I can tell you where my experience has led me. "In the beginning", (1980 for me) there was Structured Analysis and Design, which was all about Data Flow Diagrams. Those diagrams had data stores on them, where data would flow to be stored until it was needed, probably because of a time delay between a sending and receiving activity.
Next up for me was data modeling which, among other things, considered flow-driven data stores to be bad examples of data duplication and data silos. When I combined the two, I drew DFDs with one big datastore in the middle, where activities would send data to store it and would go to get data they needed. A seprate Data Modle would descibe the details of this one datastore. The flows between activities started to wither away for me.
Then for me came Information Engineering, which had Data Models (like above) and Functional Models. The latter included Functional Dependency Diagrams, showing the rational order of activities based on states, e.g. create Customer had to come before Modify Customer.
Then came Business Process Modeling, which showed the timing and resource view of activities, and showed how functions would be used to respond to an event.
Then came UML and Use Cases, where I essentially swapped IE Functions out for Use Cases.
That's still simplyfying a few things, but it has led over time to me distrusting Data Flow Diagrams as I first learned them. I have not seen anything lately to make me change my mind, and so would not recommend them myself to anyone else.
So, I guess this creates a challenge of a minor sort. What more can you tell me that might change my view? The first question I have, is do you use data modeling as well as DFDs?