Hi Craig, Guy, Tony, & other readers,

First of all, I want to echo Guy's sentiment: Do hammers really help?  Yes!

Hammers are useful if they are used for the right purpose: hammering nails. 

Are there cases when hammers work for other purposes and situations?  Yes again - but only if you do so when it makes sense...

Personally, I used a hammer many times and "knew" it would work.  Why? Because my grand daddy used one, my father used one, and I used one and it worked.  Do I need a "proof" that it works - probably not.

Same goes with Use Cases...

Do use cases really help?  Yes - but only if you use them in the right context and for the right purpose.  This applies to any tool, technique, or method.

Yes - there is lots of bias out there both for and against use cases:

• So many books on uses so they must work,
• It's an OMG standard so it must be good,
• I saw a project using use cases and the project failed,
• I bought a $5.99 use case template and it was really bad,
• etc.

Personally - I've successfully used use cases and they worked very well.  Do I employ use cases on every project?  No - I don't!

Having said that, it would be nice to have a study on the effectiveness of various tools/techniques to find out what works in what context.  Unfortunatelly, it's probably not something easy to setup since there are so many variables which contribute to the success of a project.

I once worked with a high-level executive who, when told that we would utilize use cases, he said: "@%#k use cases'.  We said OK, and the next day we changed every reference of "use cases" with "functional description" while leaving everything else the same: diagrams, naratives, alternate flows, etc.  All the project stakeholders, including our high-level executive, loved how the project team used the "new" technique of "functional descriptions".  The project went on to be a great success.

- Adrian

Adrian:

The author for the article that you  link to  is correct, and it may be the article I previously read.  However, I could have sworn that the article I read was alot longer - like about 12 pages.  Maybe this is a condensed version of it?  The author brings up important  points, such as:

*  Use cases are unsystematic (including lacking any lithmus test of completedness).

*  Use cases are a to-be modeling tool - not a problem definition (i.e., as-is modeling) technique.  (And acutally, often the major part of the to-be comes from the as-is as the as-is is a highly negotitated document.)

In my mind, just the above points reduce use cases to a supplemental diagram.  And the author brings up other limitations of use cases, including, in a round-about-way, the biggest fault of use cases: they employ brute-force partitioninig.

Adrian, positioning use cases as a tool that can help in the correct situation is alot different than what I typically hear and read: that is that use cases are "the industry standard" in functional modeling.   While I can agree with the former, I disagree with the latter.

Tony