What is an Use Case?

Use Case – describing the behavior of a system from the user’s point of view

Use Cases describe the behavior of a system, especially the interaction between the system and its users. The user is a person, a role, an organisation or another system. He or she interacts with the system as an actor in order to achieve a certain 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.

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.

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:

• Specifications
• Diagrams

Use Case Specification

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
• Actors
• Triggers
• 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 Diagram

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:

• Actors
• Use Cases
• Relationships
• System boundaries

Specifications and diagrams can be shared to provide a complementary view of the behavior of a system.

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. And they 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”.

Remark: The use of black-box use cases presents companies with challenges when deriving test cases. Formal notations such as activity diagrams or state diagrams can help here as a supplement, 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 they have relationships or parallel processes among themselves, a separate consideration is not sufficient for a test of the overall system.

Tips when working with Use Cases

Use cases are a good way to describe and understand a system from the user’s point of view. The first challenge for companies when using them is finding the topics and content. The more employees are involved, the more time-consuming this step becomes. At the same time, the results and the requirements derived from them become more detailed. When formulating, organisations should take care to create detailed descriptions that are not too complicated. Some practice is needed here.

The use of standard texts when describing triggers and 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 post-condition X can be implemented before another with pre-condition X.

Cutting use cases into slices that are realised within a sprint proves to be very useful during implementation. In practice, the use of misuse cases also actively contributes to customer satisfaction, especially since they can also be visualised by diagram. Through visualisation, manufacturers can better put themselves in the shoes of their users and identify specific requirements.

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?

Other questions

• At what frequency is the application executed?
• What are the relationships to other applications?

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.
• They can be used at different levels of abstraction, e.g. at the level of software and systems or the business level as business use cases.

Impulse to discuss:

There is a wide range of tools for defining and visualising use cases (e.g. Enterprise Architect, Visual Paradigm or Case Complete). When does it make sense to use professional tools in practice?

Notes:

Ivar Jacobson explains the success of the use-case concept as follows: “The reason for the success of the use-case approach is not just that it is a very practical technique to capture requirements from a usage perspective or to design practical user experiences, but it impacts the whole development lifecycle.”¹

[1] Use-Case 2.0 – The Hub of Software Development

A recommendation for the practical handling of use cases in backlogs can be found in the article: Boost your backlog.

Here you can download a use case template for free.

Here you will find additional information from our Smartpedia section:

What does t2informatik actually do? One click and you'll know.