Step 1. Identify the "who" is going to be using the system directly - e.g. hitting keys on the keyboard. These are the Actors.

Step 2. Pick one of those Actors.

Step 3. Define what that Actor wants to do with the system. Each of these things that the actor wants to do with the system become a Use Case.

Step 4. For each of those Use Cases decide on the most usual course when that Actor is using the system. What normally happens. This is the basic course.

Step 5. Describe that basic course in the description for the use case.

Describe it as "Actor does something, system does something. Actor does something, system does something." but keep it at a high level. Do not mention any GUI specifics for example. Also you only describe things that the system does that the actor would be aware of and conversely you only describe what the actor does that the system would be aware of.

Step 6. Once you're happy with the basic course now consider the alternates and add those as extending use cases.

Step 7. Review each Use Case descriptions against the descriptions of the other Use Cases. Notice any glaring commonality ? Extract those out as your common course (used) Use Cases. Note that this is the only valid way of finding "used" Use Cases.

The used, common course, Use Cases are actually the least important of the Use Cases to find. You would have a complete Use Case model even if you did no analysis of the Uses Cases to find these common courses. This is important to remember. Of course if you did not extract these common courses then you would not identify any commonality.

Step 8. Repeat steps 2 - 7 for each Actor.

Ok so this cook book recipe is a good way of getting started with Use Case modelling. Once you've got started and are comfortable with this process the next step is to begin to understand the trade-offs that can be made. Simplicity versus "completeness" for example. The first thing we'll cover is, perhaps surprisingly, what not to put in. The reason that's being covered next is because putting too much in is the most common mistake. Very rarely - if ever - have I seen too little modelled in a Use Case model.

Whilst developing the use case model you my have some more formal or detailed information that you need to capture. Do not put it into the Use Cases ! Instead do a bit of the appropriate type of modelling. If you need to capture a particular relationship between objects, for example the fact that a Sales Order contains one or more Sales Order Lines or that a Customer has an address or that a Customer has a name then capture that on a class diagram. If you need to capture the fact that the Actor selects an address from a list on a GUI dialog then capture that either in an Object Sequence Diagram or in some GUI prototypes or both if appropriate. Do not try to capture this in the Use Cases - there are better ways and you'll have to model it that way anyway so why repeat yourself.

Also be careful about how far you decompose the Use Case model into "used" and "extending" Use Cases. Only decompose as far as is useful in achieving the aims of Use Case modelling: capturing the high-level user functional requirements for the purpose of scoping the project and serving as the basic unit of estimation and deliverable. If you're decomposing down to the nth degree then you're probably just decomposing for its own sake - and that is not good.

The main trade off in Use Case modelling is between greater completeness (in terms of expression of alternate and common courses) and a simpler model that doesn't express these alternate or common courses.

You may choose during the initial development of the use case model to hold off on the extraction of common and alternate courses because you decide that that is the appropriate level for you to go to in producing a first cut scoping and estimate for the project.

The rule to, carefully, apply is "if it's not useful to model it then don't". This is not an excuse to skimp on modelling. The partner to this rule is "if it is useful then you must model it." But remember you do not model everything in the Use Case model - there are other modelling techniques !