Requirements Documentation Based on Use Cases

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

Objects

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.

Relations

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).

Example of use case diagram

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:

SectionContent
DesignationPU-COR-37
NameNavigate to the Goal
AuthorsMichael Smith
Priorityfor the project’s success – high,
technological risk – average
Criticalhigh
SourceJoe Newport (PM)
ResponsibilityMichael Smith
DescriptionThe driver introduces the destination, the system generates the route, and guides the driver during the trip.
TriggersThe driver wants to reach the destination with the help of navigation.
ActorsDriver, Traffic Information Server
Prerequisites
(Start Conditions)
Navigation system is switched on
End ConditionsDriver reached the destination
ResultNavigating the driver to the destination
Main Scenario1. 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 Scenario4.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 ScenarioEvent: the system cannot read information about the current position,
Solution: The system displays information about the lack of communication with the GPS.
Quality RequirementsRQ-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.

More from my site

  • The TAO Principle in the Software Development Process In larger companies or on the occasion of large ventures called projects, analysts are not one or two people but a group of people who develops requirements, business processes, specifies […]
  • Tracking of Relationship Between Requirements An important aspect of requirements management is the ability to trace the relationships between requirements and other artifacts (including other requirements). The ability to track […]
  • Kanban Reports Process management is a midway to success. The second midway is process monitoring and drawing conclusions. In Kanban, there are indicators, which enable process monitoring. They […]
  • System Architecture On walls, boards and other surfaces, you do not see squares and rectangles connected with each other by lines. Next to them is the information of what these "squares are doing with each […]
  • Partially Done Work In the previous posts, I discussed the tasks and the board in Kanban. In order to be productive, you must focus on one task at a time. Kanban facilitates this process and defines the term […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top