Use cases are used to document the functionality of the system and are based on two commonly used concepts:
- Use case diagrams
- Specifications of use cases
Use case: The use case represents a system function that represents the achievement of a goal in the system. The name of the use case should reflect the goal achieved by the implementation of the use case.
Actor: Actors are located outside the system and represent people and other systems that interact with the modeled system.
System boundary: The system limit is used to separate the use cases, which are part of the modeled system, from its environment (actors, other systems). Optionally, the name of the border can contain the name of the modeled system.
Relationship between actor and use cases: The relationship models the occurrence of interaction between use cases and actors who communicate with the system to implement the use case.
Extended relation: The extension relation models the situation in which the scenario of the implementation of the source use case (A) may extend the scenario of the implementation of the target use case (B). This extension is called after the conditions included in the scenario of the implementation of the target use case are fulfilled.
Include relationship: The inclusion relation models the situation in which the scenario of the target use case (B) is included in the scenario of the implementation of the source use case (A).
Use Case diagrams present the functionality of the system from the perspective of its environment – actors, and the links between these functionalities. These diagrams, apart from the name defining the use case goal, do not document any other information about particular use case, such as the course of interaction between actors and use cases, or the conditions required for the implementation of a given use case.
The purpose of the use case specification is to provide comprehensive documentation of individual use cases. For the use case specification, use the template provided in the design, which will ensure that no required information will be omitted.
Most often, usage case specification templates use tables in which individual rows represent a section regarding a specific type of information about the described use case.
The use case specification could include the following sections:
- Designation: A unique use case identifier
- Name: Unique use case name defining its purpose
- Authors: The names of the authors involved in the use case description
- Priority: Rank assigned to use case
- Criticality: Determines how much damage can be caused by failure to implement the use case
- Source: Identification of the source from which the use case floods (for example stakeholder, document, system)
- Responsible person: Stakeholder who is responsible for a given use case
- Description: Short description of use case
- Triggers: The name of the event that triggers the use case
- Actors: A list of actors who interact with a given use case
- Pre-requisites: List of conditions that must be met for the use case to be able to run
- Final conditions: List of system states that must be achieved after correct execution of the main use case scenario
- Result: A description of the results that are achieved during the implementation of the use case
- Main scenario: Description of the main scenario defining the use case execution path
- Alternative scenarios: Description of alternative scenarios defining and events leading to the transition to the implementation of an alternative scenario
- Exception scenarios: Description of scenarios for exceptions and events causing the transition to the implementation of the exception scenario
- Quality requirements: References to the quality requirements that apply to this use case
An example of a use case description is given below:
|Name||Navigate to the Goal|
|Priority||for the project’s success – high, |
technological risk – average
|Source||Joe Newport (PM)|
|Description||The driver introduces the destination, the system generates the route, and guides the driver during the trip.|
|Triggers||The driver wants to reach the destination with the help of navigation.|
|Actors||Driver, Traffic Information Server|
|Navigation system is switched on|
|End Conditions||Driver reached the destination|
|Result||Navigating the driver to the destination|
|Main Scenario||1. Navigation system asks for the introduction of the destination|
2. The driver introduces route goal,
3. The system displays the route’s destination on the map,
4. The system calculates the route based on the current position and entered route destination,
5. The system displays the calculated route on the map,
6. When the driver reaches the designated destination, the system displays information that the designated destination has been reached.
|Alternative Scenario||4.A Route calculation must include traffic information and avoiding traffic jams: |
4.A.1 The navigation system updates traffic information based on information from the traffic information server,
4.A.2 The system calculates the route based on the current position of the entered route destination and traffic information,
4.A.3 Entry to point 5 of the main scenario
|Exception Scenario||Event: the system cannot read information about the current position, |
Solution: The system displays information about the lack of communication with the GPS.
|Quality Requirements||RQ-10 Route calculation time, |
RQ-24 Comfort of entering the destination of the rout
Of course I use Enterprise Architect, for the specification of use cases.