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.
David:
What you are saying is exactly the way a data flow diagram would be created - if it was created without labeling the data flows between the functions. But the data flows are the lithmus test of completedness. Without the data flows, it is very easy to miss alot, and therefore not know if analysis is completed.
Tony
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
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: