 |  | |
| | |
| | |
| | |
 | | |
|
|
|
| The Lost Secret of Business Analysis |
|
|
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
|
|
|
|
| |
|
|
| Re: The Lost Secret of Business Analysis |
|
|
ajmarkos wrote
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 Marchis
Modern Analyst Blog - Featured Business Analyst Blog
Business Analyst Community Blog - Post your thoughts! |
|
|
|
| |
|
|
| Re: The Lost Secret of Business Analysis |
|
|
Excellent topic Tony...you've got me thinking!
You've made an interesting comparison, though I think there is a pretty big difference between developing a use case model and data flow diagrams. Data flow diagrams really focus on identifying a process and then decomposing it or drilling down to more granular processes until you can no longer drill down. Why, because our fiirst systems were very data driven, large database centric systems, and identifying the data that flows between different parts of a system was seen to be the number one priority.
On the other hand, one of the major driving principles of use cases is identifying functionality supported by the system that results in value to the user. Additionally, most data has no place in a use case model. On occasion, I agree it may be important to identify architecturally significant data within a use case. But use cases should never include a list of every field on a screen. Why? Well for starters, use cases are not screen specific, they are logical representations of the functionality. Once we begin talking about UI screens or controls we have jumped into the world of the physical system.
Probably the biggest mistake most use case modelers make is they treat a use case diagram like a functional decomposition of the system. This will always result in a model that is disconnected from the true needs of the system users. I find that when I'm creating a use case model, this is what I struggle with the most. To counter this natural pitfall I constantly ask myself, "does this use case which I have identified provide a valued result to the user" or in other words "would the user come to the system for the sole purpose of completing this use case". If I can't answer yes to these questions, then I have identified a functional process that is far too granular. I will not be able to maintain my use casee model in the future when changes are made to the system, and I will lose sight of the true requirements of the system.
Now, don't get me wrong, I think there maybe a better undiscovered process for modeling system requirement than use cases, but I haven't found it yet. Maybe a good discussion at this point would be for this community to identify all of the pros...and cons...to use cases, and see where this takes us.
Chris Adams
Core Member – ModernAnalyst.com
View Chris’ Modern Analyst Profile |
|
|
|
| |
|
|
| Re: The Lost Secret of Business Analysis |
|
|
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.
Regards,
Tony
|
|
|
|
| |
|
|
| Re: The Lost Secret of Business Analysis |
|
|
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 |
|
|
|
| |
| | |
| | |
| | |
|