Steps in developing a use case model, given a business or domain model (adapted from The Unified Software Development Process):

1. Define actors and use cases.
1. Find the actors.
2. Find the use cases.
3. Briefly describe each use case.
4. Define an overview of the entire use case model, with a glossary.
2. Prioritize use cases by:
1. Importance.
2. Difficulty.
3. Risk.
4. Necessity.
5. Patron.
3. For each use case, beginning with those of highest priority, describe the essential use case in detail with one or more of:
1. A step-by-step narrative.
2. A "conversational" script.
3. UML state, activity, and/or sequence diagrams.
4. Structure the use case model, capturing:
1. Generalization.
2. Extensions.

Rules of thumb for defining use cases (from the Unified Process and from Craig Larman's Applying UML and Patterns):

• A use case is a description of a process from end to end, not a single step in a process.
• Include only the processes that are within system boundaries. For a software system, the system boundary often lies between the hardware and software on one side and human actors on the other.
• To find use cases, try two tactics:
• Identify actors, and then identify the processes each actor initiates or takes part in.
• Identify the external events to which the system must respond, and determine which actors and use cases handle them.
• When considering candidate use cases, ask who initiates the use case and who benefits from it.
• If there are no obvious beneficiaries, think about excluding it or including it as one step in a larger use case.
• You can often leave out "helper" actors - those who neither initiate nor benefit from a use case - until you get to detailed design.
• Specify informal preconditions and postconditions for each use case.
• Focus in the main body of a use case description on straight-line normal processing. Include alternate paths in addenda.
• Start with "essential" use cases, and work towards "real" use cases only as the system design matures.
• Don't let a use case lock you into a design decision unnecessarily.
• Develop iteratively.
• Don't develop use cases in isolation from other requirements development activities like CRC modeling and analysis class modeling. Let the insights you get from each inform the others.