" A Use case us the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stake holders of the system (UML 2) "
- A Use Case is the story of how the business or System and the user interact.
- Use Cases are formal requirements that clearly define the resultant value.
- Use Cases transform "shall" statements into groups that provide observable value and context, organized from a user prospective.
- Use Cases describe both functionality and results.
- A common mistake is to consider requirements with design specifications.
- Diagrams provide a visual reference for the use case.
- People are the most important use case element.
- Establishing a use case style makes writing and reading them faster and easier.
- Use Cases should have a single main flow and multiple alternative flows.
- Alternative flows explain deviation from the main flow.
- Use Cases are not design documents they are requirement documents.
- References define the beginning and the end of an alternative flow.
- References indicate what caused an alternative flow to start and what the system does in response.
- Readability can suffer if there are "if statements" in a flow, because it usually means multiple requirements.
- Selecting a single choice for an actor, and creating alternative flows for other choices, can simplify the main flow.
- A poorly written use case has too many create, read, update and delete activities, reducing clarity.
- Removing CRUD creates a simpler document.
- Sequencing the events in a flow is not always necessary to achieve clarity.
- Don't forget you are writing use cases for the end user.
- Agreement on use cases structure and processes is essential to achieving quality and consistency.
Ref: Tips for writing good use cases by James Heumann