Use cases are used to describe how a person or system connects with the solution being modeled to attain a goal.
Use cases describe the relationships between the primary actor, the solution, and any secondary actors that are required to fulfill the primary actor’s goal.
Use cases can be triggered by the primary actor, another system or by an external event or timer.
A use case describes the potential outcome of an effort to fulfill a specific
goal that the solution will support. It features different paths that can be followed by describing primary and alternative flows.
The basic flow depicts the most direct way to fulfill the use case goal. Exceptions that lead in a failure to complete the goal of the use case are documented in alternative flows.
Use cases are written from the point of view of the actor but it does not describe the internal functions of the solution. Use case diagrams are a graphical representation of the relationships between actors and one or more use cases supported by the solution.
A scenario describes a single way in which an actor can fulfill a specific goal. Scenarios are written as a series of steps executed by actors or by the solution that enable an actor to fulfill a goal. A use case describes several scenarios.
Use cases and scenarios have some components, which include:
There is no standard format for use cases, but the following components are
usually captured in a use case description.
1. Use Case diagram: A use case diagram visually represents the range of the solution, by showing the actors who relate with the solution, which use cases they relate with, and any relationships between the use cases.
Relationships: Relationships between actors and use cases are called associations. An association line shows that an actor has access to the functionality represented by the use case. Associations do not show input, output, time, or dependency.
There are two commonly used relationships between use cases and they are:
• Extend: this allows for the introduction of additional actions into a use case. The use case that is being expanded must be independently functional and must not depend on the extending use case for its successful implementation.
This relationship may be used to show that an alternate flow has been added to an existing use case to represent new requirements.
• Include: this allows the use case to make use of functionality which is already present in another use case. The included use case does not need to be a complete use case in its own right, it could be a subset of a use case if it is not directly triggered by an actor.
This relationship is often used when some shared functionality is needed by several use cases.
2 Use Case description
Name: The use case has a unique name. The name usually includes a verb that describes the action taken by the actor and a noun that describes either what is being done or the goal of the action.
Goal: The goal is a brief description of a successful outcome of the use case from the primary actor’s point of view.
Actors: An actor is any person or system which is external to the solution but connects with that solution. Each actor is given a distinctive name that represents the role they play when relating with the solution.
A use case is triggered by an actor, who is the primary actor for that use case. Other actors who take part in the use case in a supporting role are called secondary actors.
Preconditions: A precondition is any event that must be true before the use case can begin. The precondition is not tested in the use case but acts as a constraint on its implementation.
Trigger: A trigger is an event that starts the flow of events for a use case. The most common trigger is an action taken by the primary actor. A temporary event, such as, time can also start a use case.
This is commonly used to trigger a use case that must be implemented based on the time of day or a particular calendar date, such as an end-of-day routine or an end-of-month reconciliation of a system.
Flow of Events: The flow of events are the set of steps carried out by the actor and the solution during the execution of the use case. Most use case descriptions have the primary flow that represents the simplest successful path that fulfills the goal of the actor.
Use cases may also include alternative and exception flows. Alternative flows describe other paths that may be followed to allow the actor to successfully fulfill the goal of the use case.
While exception flows describe the response by the solution when the goal is unattainable and the use case cannot be successfully completed.
Post-conditions : A post-condition is any certainty that must be true when the use case is complete. The post-conditions must be true for all potential flows through the use case, including both the primary and alternative flows.
The use case may describe distinct postconditions that are true for both successful and unsuccessful executions of the use case. These can also be called guarantees; the success guarantee describes the postconditions for success.
Minimal guarantees describes the conditions that are needed to be true, even if the actor’s goal is not fulfilled, and may fix issues such as security requirements or data integrity.
Use cases and scenarios have their strengths and limitations, which include:
Strengths
- Use case diagrams can simplify scope and provide a high-level understanding of requirements.
- Use case descriptions are easily understood by stakeholders due to their narrative flow.
- The addition of a desired goal ensures that the business value of the use case is communicated.
- Use case descriptions express the functional behaviour of a system.
Limitations
- Decisions and the business rules that describe them should not be recorded directly in use cases, but managed separately and linked from the appropriate step.
- The flexible format of use cases may lead to the capture of unnecessary detail while attempting to show every step or interaction.
- Highly detailed use case description format are better captured with other techniques such as user interface interactions, non-functional requirements, and business rules.
- Use cases are not related to the design of the solution, so significant effort may be needed during development to map use case steps to software architecture.