Hi all!
I agree with Steve, and give me a chance to convince you why I've found use cases to be so useful, and why I consider the technique to be one the greatest contributions on systems analysis, design and construction.
1. Use cases try to depict a sequence a events (either "as is" or "projected system") that produces a useful product or service. So, first of all, you are identifying the "useful product or service" as your project's real objective. During the project, I have to keep repeating to myself: "Listen, burrito, it's the useful service or product that you're after, not the technology or the nice tools you're using".
2. They present the sequence events from the point of view of the user. This is of high value, because they directly point to the need of a good user interface, and good user-friendly design. "Listen... this is for the customer/user, not for the programmer...."
3. They bring the nice and clear side of object reuse to the fore, because they help break-up your system (current or projected) into meaningful sequences. Many of these sequences can be reused by other use cases via <<include>>, <<extend>> or generalization/inheritance relationships. (There are postings on this in the General EA forum: search for "extend".) You can save lots and lots of time by taking advantage of this.
4. They help in project planning, by assigning resources to the different use cases; for instance, "Developer 1, who's strong on user interface, should take care of the portal opening..; Developer 2, who's a real ace in RDBMS, should take care of the transactional use cases", and so forth...
5. The use case model is the best way I know of delineating project scope and helping you break-up a big project into stages.
6. Use cases are the way I've found to drive the next stage of your modeling, because they can be directly mapped to sequence diagrams; and these sequence diagrams are a sure-shot way of detecting the classes for your first-cut class model (which will evolve into both your user interface model and your static class or database model).
7. They are great aides for your technical architecture alternatives discussions. The first-cut answer to the question "Should I use a package or custom development?" can be answered by mapping the proposed package components to use case events.
8. Use cases can easily be derived into test scripts.
And there are many more reasons, but I hope these suffice for the moment.
ComputerWorld Mexico published in 1998 a somewhat long article I wrote on use cases, and I'll gladly submit a more updated version of it as a contribution to the cook-book (it is my intelectual property, so no problem with copyrights). It develops, step by step, a simple use case model. The only problem is that it is in Spanish, but I'll EMail it to anybody who volunteers to translate it.
Also, I would have no gripes if the article is torn apart and re-made (or whatever) into the core of the cook-book.
Finally, having praised use cases, let me now make a criticism: the user case model is not user-friendly, and you will not communicate your ideas to senior management with a use case model. To communicate with users and senior management, you should use a process model (see EA's document on process modeling).
Jaime
