After a long hard look on the web I have been unable to find any convincing argument that use cases should be the default requirements specification tool. Can anyone point me to a good case for the use case?
Hi Craig,
I can't and I doubt that a "good" case for the use case exists - "good" in this context being defined as a set of premises and deductions leading to the inescapable conclusion that use cases should be the default requirements specification tool. Of course there will be loads of UML evangalists who will express opinions and case studies in support of UML in general and/or use cases in particular - just no formal proof.
Its a tool - there is no one tool in my DIY toolbox at home that I use on every job. Of course, to a man with a hammer the whole world looks like a nail...hammers are good for nailsl and lousy for sawing wood. Use cases are good for requirements validation and making the solution more real to users, and lousy for initial requirements analysis.
Of course, that's just my opinion - I have no proof!
Guy
Guy Beauchamp wrote: "Use cases are good for requirements validation and making the solution more real to users, and lousy for initial requiremenat analysis"
Tony Markos responds:
Right on! Of course, the question then becomes: Why are uses cases lousy for initial requirements analysis? A couple of answers (there are others):
* Use cases are based on what data flow diagramers call a brute-force partitioning (i.e., an unnatural partitioning): The analyst documents whatever functions/processes that just so happen to pop into his/her head. There is no built in mechanisim in the technique to prod the analyst to follow the flow of info., which would result in a natural partitioning of a system. An unnatural partitioning results in processes/functions for which it is impossibe to figure out how they interrelate.
* Use Cases have no lithmus test of completedness. Or, as others on this site have asked: How do you know when you are done creating the use cases? (Answer: You don't)
Tony
Thanks Tony,
Most tools and methods have strengths and weaknesses. What I am wonderring is why Use Cases have become so pervasive.
I suspect it's simply another case of marketing of 'best practices' with no foundation. For a community of analytical people I wonderwhy nobody is seeking evidence that Use Cases (to pick just one example) are a better equirements modelling tool than other things.
For example - the readers of this site are all generally smart and motivated popele. I suspect most of them would achive positive results regardless of the modelling tool they pick.
Craig:
There used to be an insightful on-line article that referred to use cases as the "junk food of requirements analysis". Googling his name, the author seemed to be fairly well know in the IT community. I emailed him to express an interest in his writtings. He emailed me back stating that he was sorry that he ever wrote the article. He did not elaborate, but my guess is that the UML police got to him. (And evidently, the article has now been removed.)
Craig, use cases are largely stripped down data flow diagrams. For many the rigor that data flow diagrams prod for is just too much. Use cases were meant to be dfd's for the masses. And that is why they are so pervasive.
Success irregardless of the modeling technique choosen? What I know from experience is that the partitioning that results from dfd's is radically different than from use cases - especially on larger scale efforts. I have seen the results side-by-side more than once. And as I previously stated, any dictionary will tell you that analysis IS partitioning. One of the techniques has got to be very lacking.
Of course, mind you, I have nothing against use cases per say :-)
brought to you by enabling practitioners & organizations to achieve their goals using: