An esteemed colleague and friend of mine (hello Sylvain :-) recently asked me what I think about use cases. He has read the books, followed the instructions and experimented with various approaches. Tried as he may to convince himself and others on the merits of use cases, he never could make them "work as they are supposed to". He really became suspicious, though, when he realized that he could not find anyone who could show him a real-life use case model that actually added value to a project. Even Google searches for "use case" and "case study" or "roi" provided surprisingly little evidence (here's one notable exception, although the author at one point report "No added value came from the <snipped> tool. ").
First a few definitions:
Use Cases specify a sequence of actions, including variants, which an entity can perform, interacting with actors of the entity. They are primarily used to define the behavior of an
entity, like a system or a subsystem, without specifying its internal structure. (Adapted from OMG UML specification version 1.5).
A Scenario, also known as a Use Case Instance, is the performance of a sequence of actions specified in a use case. (Idem)
User Stories are written by the customers as things that the system needs to do for them. (Adapted from the eXtreme Programming Web Site)
Now here's my response to Sylvain:
I believe that Use Cases, as they are defined in the UML specifications, are an attempt by engineers to formalize the intrinsically informal needs and desires of their users and customers. They have their usefulness as a higher-level abstraction but, contrary to popular beliefs, they are not intended for end users. They are tools created BY and FOR engineers. End users don't care about whether what they want makes 1 or 3 or 13 use cases, they don't care too much either about having to learn yet another expression that makes them feel like they know nothing about computers and software, and they certainly don't care whether or not a case can be made for the use of use cases.
Personally, I've always found that concrete, actual Scenarios were more useful than the use cases themselves when interacting with a customer. I actually like better the XP expression of "User Stories" for it conveys the idea that many different "plots" are possible (there should be at least two "storylines", one for the current way the work is being done and one ore many others for how things could happen with the new system we are going to implement).
At the Process Academy, we do use use cases extensively, but strictly for internal activities such as planning work, defining builds content and organizing our technical documentation. For us, they are a means of grouping together a bunch of modules and related functionalities.
Anyone having thoughts or opinions on this subject, I'd be glad to here from you. And if you have a real-life, significant and value-adding use case model you'd be willing to share, let me know and I'll pass the information to my friend.
The official UML specifications can be downloaded from here.
The eXtreme Programming's User Stories.
Edward Kenworthy has publish this nice article highlighting a well rounded recipe for creating good quality use cases, complete with a description of the majors "do's"... and "don'ts"!