Each way to use a System is called a Use Case (one of many ways to use a system or a task with a business value that Actors need to perform with the help of a system). This is a summary of all the ways that all types of users will interact with the system. This will help document requirements. In this way, you can model requirements from a human perspective.
- Defines the interactions between systems and actors focusing on interactions not activities.
- You specify Actors, main success scenarios, alternative flows…
- There is a contract between stakeholders and developers
- These enable testing
Warning
Not to be confused with Scenarios (a sequence of interaction steps).
These are very user-centric.
You use UML to describe use-cases.
Types
<<include>> (required)
- A sub-use case used in other use cases
- You have a piece of behaviour that is similar across many use cases (can be factored out) <<extend>> (optional)
- A sub-case that extends or replaces the end of an existing use case
- A use case is similar to another but does a bit more
Generalization means that one option is required (multiple use cases pointing towards a use case)
Description Template
Use cases are described in a table format:
- ID
- Name: usually verb + noun
- Actors and interests: the actors involved and each one’s goals
- Trigger: an event that starts the use case
- Preconditions: system conditions for the use case to normally start
- Postconditions: system conditions after use case is finished
- Main Scenario: success path
- Extensions: alt flows and exceptions
- Special requirements: related non-functional requirements
Note
- Try to avoid having too many use cases or highly complex use cases
- Don’t include a design in the use case
- Don’t include data definitions in a use case
- Use cases that users do not understand should be simplified or removed since the use cases should be written from a user perspective