Use cases captures the functional requirements of the system.
- They model behavioral requirements of the system and demonstrate what the system should do.
- They describe the interactions between various actors and the system.
It does not reveal any details about the implementation of features.
- When a use case is considered complete, there are no further inputs or outputs.
- The desired functionality has been performed, or an error has occurred.
After a use case has completed, the system is in a state where the use case can be started again, or the system is in an error state.
The most common way to write use cases is to represent a view of the system from outside the system.
In Agile software development, this diagram can represent stories.
- The diagram is useful for uncovering dependencies and deciding which of two otherwise similar stories to implement first.
- All other factors equal, implement the one with the most incoming arrows first.

Elements

Use Case

The features of the system that the actors use.
Some use cases interact with other use cases.
- Their relationship is modeled using dependency arrows.
One popular method to design use cases is to ask yourself if the user can "go to lunch" after completing the use case.
- This means that a reasonably sized goal has been achieved by the initiator.
- E.g., "Add an item to the shopping cart" is probably not the larger goal a user intends.
  - Purchase item is likely a better scope.

Someone or something that has a goal in using the system.
- Actors have a role in the system.
You may use custom icons to clearly distinguish different types of actors.
- For example, you can show an external database system using a database.
Primary Actor: Is the actor who initiates the use case.
Secondary Actor: Those who finalize or complete a process.
- E.g. the management or an external device.