A Use case is a cool thing.  A little too cool.  The term has been occasionally misused, and in some respects, that misuse diminishes the value of a use case.  To succeed, we have to know what a use case is.   When you are done reading this post , you will still know what a use case is... but you will also know what a use case isn't.

What a use case is

The following section is a direct excerpt from “Writing Effective Use Cases” by Alistair Cockburn.

“A use case captures a contract between stakeholders of a system about its behavior. The use case describes the system’s behavior under various conditions as the system responds to a request from one of the stakeholders, called the primary actor. The primary actor initiates an interaction with the system to accomplish some goal. The system responds, protecting the interests of all the stakeholders. Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and the conditions surrounding the request. The use case gathers those different scenarios together.” (Cockburn, 2001)

With all due respect to Cockburn, his discussion doesn't so much define a use case as describe one.  There are very few formal definitions available in the public domain or in reference works.  Here is my attempt at a more formal definition:

A use case is a formal description of an interaction between an actor (usually a person) and a system for a specific purpose or goal.

Many of the discussions of use cases in the literature go into great detail about the requisite parts of this formal description.  Most include the concept of 'actors', 'use case scenarios,' 'preconditions,' 'postconditions,' and a stated 'goal.' 

Things to notice

1. In a use case, there are always at least two actors, and one of them is a system.  The use case is a description of system level interaction... in rich detail. "Enter name and address and click the 'enter' button."  There is very little about a use case that is abstract or high level.
    
2. The amount of formality is not part of the definition.  In fact, Cockburn specifies that you should create a use case in a fairly informal way at first, when the system is still being understood.  Only in a later iteration of the requirements, when the project is funded and the scope is reasonably well understood, should the specifics of the use case be added.

What a use case is not

As I mentioned before, the term "use case" has been used in many ways, and it has been applied in some pretty unusual things.  To be effective, we should recognize that a use case is a tool that is tailored to one purpose, and using it for a different purpose may not be optimal. 

1. A use case is not a description of a business process.  The use case describes the interaction between a single actor and a system.  At best, that interaction can be considered a single (atomic) activity in a business process.  A business process is much more than that, including many activities from inputs to outputs in support of a goal.  Let's not pretend that use cases describe business processes.  One activity, perhaps two... that I will buy.  Rarely, if ever, anything more.
    
2. A use case is not decomposable into other use cases.  It is the atom.  Break it down and you have parts that are not atoms.  Combine use cases and you have composites (molecules) that are not atoms.  A use case is the description of an interaction between person and machine.  That is all.
    
3. A use case is an inappropriate tool to describe system to system interaction.  Certainly you CAN use a use case this way, just as you CAN drive a screw into wood with a hammer.  But it is not optimal to do so.  A much better set of tools include UML Interaction diagrams, protocol descriptions, standard identifier formats, and WSDL.   
    
4. A use case is used to elicit requirements but it is not the requirement itself.  Requirements need to be collected and called out as statements.  A couple of noted authors have weighed in on the skills needed to describe and understand requirement statements.  Both analysts and developers should learn these skills.  
    
5. It is optional to use the use case approach.  While I'm a fan of use cases, I'm also in a role where we have to draw clear distinctions between the work that someone must do and the work that someone should do.  The requirements must be collected.  Use cases should be used.  If you can collect requirements in a different way, that is not wrong.  That said, I'm fairly comfortable stating that the use case approach is a 'best practice' for describing requirements to software developers.
    
6. For traceability and requirements validation, use cases are not the source of requirements.  Requirements come from the business needs, and most of the business needs are fairly easy to connect to specific stages of the business processes (with some fascinating exceptions).  As I pointed out in my prior post, I view the source of most business requirements to be the business processes and customer experience scenarios that software must support.  
   
   Therefore, if you want to determine if a requirement is needed, or provides value, or has been completely met, it is better to trace the requirement back to the business process.  The use case is an abstraction along the way.  (This is my opinion, of course, and your mileage may vary).
   
   (note to contributors: the distinction between functional and non-functional requirements is too vague to clearly delineate the requirements that are not easily traced back to business process or user experience scenarios.  There's another blog post in there somewhere.)

In short, a use case is an essential and valuable tool in the Business Analysts' toolkit.  Let's use it wisely.