Data flow diagrams where invented to counter the overwhelming urge that BA's have to FIRST draw boxes (or ovals or circle) and THEN try to interconnect them. DFDer's call such an appraoch a "forced, artificial partitioning". Basically, such a "connect the boxes" approach involves putting down on paper our limited understanding, and then trying to foce fit reality to that understanding. The discovery process in derailed big time.
So, data flow diagrams are now out and use cases are in. What is the first step in creating a graphical use case? - draw the ovals. The secret of effective functional modeling has been disregarded. The analysts community has forgotten about forced, artificial partitioning to such an extent that heads of IT at prestigious universities do not even know what it is. Do we ever learn?
Tony
Hi Tony,
I'll be the first to admit that I have not heard the term "forced, artificial partitioning". But I can guess what it means. One of the biggest challenges with use cases modeling is determining how many use cases. And because the use case diagram comes first, the business analyst needs to make up front decisions on the fictional breakdown of the features into use cases. Most often, this results in less than optimal use cases or in the need to re-work them later.
In a number of projects I have had this dilemma of needing to have the functional breakdown before creating the use case model. One thing that worked was a combination of DFDs (mostly high level) and events. That is we took at look at the data that flows between processes and then tried to figure what were the triggers (events) that caused that data to flow.
From there we began to identify user's intent which helped us determine the granularity and breakdown of use cases.
Regards,
- Adrian
Adrian:
You stated "One of the biggest challenges with use cases modeling is determining how many use cases."
That is basically what I am talking about.: Use cases, because they utilize a "draw the ovals first" approach derail the discovery process. Analysis is discovery of the As-Is - not pre-design. Use cases, because they derail the discovery process are a poor analysis tool. Additionally, use cases, as they are most generally used, focus on the To-Be implementation. This makes them a pre-design technique.
Hi guys
Another perspective is that a DFD may also be called a context diagram. In this mode the focus is less on data and more on particpants and actors in a process - just like use cases. The difference is that context diagrams are system centric while use cases are actor centric.
I couldn't imagine trying to put together a comprehensive series of use cases wuthout first decomposing the business process using a context diagram.
Cheers,
Craig
brought to you by enabling practitioners & organizations to achieve their goals using: