What is an Use Case, what types exist and what advantages do Use Cases offer?
Use Case Definition
Use Cases describe the behavior of a system from the user’s point of view. The user is a person, role, organisation or other system. He/she/it interacts as an actor with a system in order to achieve a specific goal in a defined sequence of actions. The target usually gives the name of the Use Case (e.g. “control vehicle speed” or “withdraw money”), so that you can see at a glance which use case is involved.
Use Cases have been used in software development, system creation and product development since the beginning of 1990. Even today they are very popular because they document the functionality of an existing or planned system with simple models. In this way the common understanding of the interaction between actor and system is significantly increased, scenarios can be identified and functional requirements and corresponding test cases can be derived from the objectives of the actors.
Types of Use Cases
There are two types of Use Cases:
- A Black Box Use Case documents what a system should do and not how it should do it. The black box view shows what a system looks like from the outside, including the required and provided interfaces, and the relationship to other systems. However, a black box view does not describe the internal implementation of a system.
- A White Box Use Case, on the other hand, documents which classes, interfaces and other components of a component help to provide the desired functionality.
In practice, Use Cases are usually described as Black Boxes.
Use Cases are also divided into Business Application Cases and System Application Cases. For example, there can be several System Application Cases for the Business Application Case “Reserve Trip” such as “Reserve Telephone Trip” or “Reserve Online Trip”.
Use Case Advantages
The application of Use Cases offers a number of advantages:
- They are easy to understand and relatively easy to create, because both the interaction between actor and system and the relationship between different Use Cases can be easily abstracted.
- They are a good source for identifying requirements arising from these interactions.
- Extensive requirements can be refined by decomposing the interactions between actor and system. This increases the understanding of those involved.
- By combining textual descriptions in specification documents and visualisation via Use Case Diagrams, organisations simultaneously gain useful detailed information and a good overview of the entire system.
Use Cases in Practice
Use Case Concept
Ivar Jacobson presented the concept of Use Cases in 1987. He defined a use case as “a special sequence of transactions, performed by a user and a system in a dialogue”. The concept comprises two approaches that can be used together:
Use Case Specifications contain natural-language information on the systematics of the interactions of an application case (so-called “narratives”). Ideally, this information is captured textually using a template. This template should contain at least the following elements:
- Name of the Use Case and Use Case Number for unambiguous identification
- Brief description
- Description of the essential steps as a standard procedure
- Description of alternative sequences
- Preconditions and postconditions
- Description of the system boundaries
In addition, it is advisable to record references to other Use Cases or documents, the frequency, the priority and, if applicable, invariants as non-modifiable conditions.
Use Case Diagrams visualise Use Cases and actors with their respective relationships. They provide a good overview of the overall system, but in contrast to the Use Case Specifications they do not describe processes, but the relationships between a large number of Use Cases and the actors involved. Use Case Diagrams are thus regarded as graphical representations of Use Cases and the Unified Modeling Language (UML) defines them as behavior diagrams. The most important model elements here are:
- Use Cases
- System boundaries
Specifications and diagrams can be shared to provide a complementary view of the behavior of a system.
Testing with Use Cases
The application of Black Box Use Cases presents companies with challenges when deriving test cases. For example, formal notations such as activity diagrams or state diagrams can be used as a supplement here, because test cases can be derived relatively easily from them. In addition, the pre and post conditions of a Use Case are a good source for test cases. However, since use cases have relationships or parallel processes, it is not sufficient to consider each Use Case separately in order to test an overall system.
Benefits of Use Cases
Companies develop products, software or systems that are intended to generate benefits. Often, tasks are to be performed faster, better, more securely or more simply. The customer should use the product to achieve his goal. But what happens if the goal is unclear and not clearly defined? In the worst case, the customer will not use the product because it offers little or no benefit.
Use Cases show the big picture of a system to be developed. Without this big picture there is often a lack of orientation and as a result decisions about the scope – what is to be developed, what can be developed later or what can even be omitted – are difficult to make. Incomplete or unclear requirements hinder development and market success. Changes must be implemented retrospectively. The later this happens, the more difficult and expensive the development becomes.
Questions for Use Case Creation
There are some questions that help in creating Use Cases:
Questions about the actor
- Who uses the system?
- What is the aim of the actor?
- What other systems interact with the system?
- Who provides the system with information or receives information?
Questions about the pre- and post-conditions
- Which condition must be fulfilled for the Use Case to occur?
- What state is the system in when it occurs?
- How and under what conditions is it closed?
- In what state must the system be so that the use case is closed?
Questions about the processes
- Which actor and which event initiates the sequence of events?
- How does the actor interact with the system and how does the system react?
- Which alternative actions can the actor initiate at each step?
- Which interruptions or errors can occur at each step of the use case?
- What happens if the actor aborts the process?
- At what frequency is the application executed?
- What are the relationships to other applications?
Download the Use Case Whitepaper for free now.
Everything important about Use Cases at a glance.
- What are use cases and how are they created?
- Which components do use case diagrams have?
- How can use cases be used in agile development?
- What are misuse cases and why are they useful?
- What are challenges and what useful tips exist?
Knowledge on 14 pages to take away.
Challenges for Companies
The Application of Use Cases in Different Facets
With Use Cases a system can be well described and understood from the user’s point of view. The first challenge for companies working with Use Cases is to find the topics and contents. The more employees are involved, the more complex this step becomes. At the same time, the results and the resulting requirements become more detailed. When formulating Use Cases, organisations should be careful to create detailed descriptions that are not too complicated. This requires some practice. The use of standard texts to describe the triggers and the pre- and post-conditions is not recommended. Often sequences for implementation can also be derived from the pre- and post-conditions: a Use Case with the post-conditions X can be implemented before a Use Case with the precondition X. Use Case 2.0 with the cutting of Use Cases into slices, which are implemented within a sprint, proves to be very helpful. In practice, the utilization of Misuse Cases also actively contributes to customer satisfaction, especially since they can also be displayed using Use Case Diagrams. Through visualisation, manufacturers can better put themselves in the position of their users and determine specific requirements.