When we use the term "Use Cases" on this site, we are probably referring to type of Use Case described by Allistar Cockburn ("co-burn") in his book Writing Effective Use Cases.

In general,

• Use cases are a stylized narrative that tell us how the system is suppose to behave.
• Use cases capture contracts between the various stakeholders of a system.
• Use cases describe how actors achieve goals.
• Use cases are requirements, but not all of the requirements.

Examples

Use Case Development Lifecycle

1. Define Actors and Goals
2. Write Use Case Briefs (stories)
3. Assign Priorities
4. Write a Usage Narrative
5. Describe the Main Success Scenario
6. Define Failure Conditions
7. Describe Failure Handling

Use Case Guidelines

• Use simple grammar.
• Show clearly "who has the ball".
• Write from the bird's eye view.
• Show the process moving forward.
• Show the Actor's intent, not the movements.
• Include a "reasonable" set of actions
• "Validate", don't "Check whether".
• Optionally, mention the timing.
• Idiom: "User has System A kick System B".
• Idiom: "Do Steps x-y until condition."

Defaults

• If an extension simply returns to the next step, then "Return to MSS" can be omitted.
• Extensions can be nested one level deep.
• Extension steps can be numbered using the newer "dot" convention.
• The "System Under Design" can be referred to in the third person.
• If System is going to display the expected screen as the next step, and there are no extensions, a "System presents (expected) screen" step can be omitted.

Supplemental material

Vision Statement

• A brief one or two sentence description of what the system is trying to accomplish.
• A Vision Statement gives the use cases a "place to stand."

Design Scope UML Drawing

• Defining the design scope of a system is vital.
• A high-level UML drawing of the scope of the system under design can help keep the team on task.

Design Scope Topics (In/Out)

• In any team effort, it's always challenging to keep everyone on topic.
• Keeping a topic board can help keep a group on task.
• Before discussing a topic, the team first needs to decide if the topic is In or Out.
• Before discussing an "Out" topic, the team has to decide to move it to the "In" column.

Topic	In	Out
Vetting water samples
Event driven architecture
Tracking reports
Assembling documents
Active Directory authorization

References

• Structuring Use Cases with Goals (online article)
• Writing Effective Use Cases (printed book)