A Business Process starts with a triggering event and ends with desired outcome. Start with the trigger and ask what do you do first, then what do you do next, and so on until the outcome is reached. If the business says "it depends", you have variation, and capture all the steps for that and all variations. Follow this approach and you document all the steps in the process, and each step that does something with information, that's a Use Case. If you do that, you will have a complete list of Use Cases for the scope of the business process you are analyzing, and you will know what are all the manual steps that happen in between. This is the approach we (IAG)  use for all our client engagements, works very well.

Tony,

I have not used a classic DFD in at least 25 years. While they were the core of original Structured Analysis and Design, they fell into disfavour because of their use of Files that data was stored in, which led to bad data design. The multiple files were replaced by data models, capturing all the data needed in the scope of analysis.  In that case, data does not flow from step to step but from step to data model and back as needed. The ordering of steps in a process then becomes that of functional dependency, A must occur before B can occur and so on.

Anyway, that's where I stand on DFDs. If you can offer examples of how they help you as you have described, I would like to see them...David W