What is an Use Case?
Table of Contents: Definition – Concept – Procedure – Advantages – Questions – Download – Notes
Smartpedia: A use case describes the behavior of a system from the user’s point of view, including all scenarios with which an actor tries to achieve a goal.
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.
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.
- In this way the common understanding of the interaction between actor and system is significantly increased,
- scenarios can be identified and
- functional requirements as well as corresponding test cases can be derived from the objectives of the actors.
Two approaches in the 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 and complement each other:
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
In general, the following different relationships or relationship types can be used in a diagram:
- association relationship,
- include relationship and extend relationship as well as
- generalisation.
The procedure for creating Use Cases
Use Cases are a good way of describing and understanding a system from the user’s perspective. The first challenge for companies when using the system 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 resulting requirements become more detailed. When formulating them, organisations should take care to create detailed descriptions that are not too complicated. Some practice is required here.
There are a few questions that help with the creation of 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?
Remark: 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.
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.¹
Questions in the context of Use Cases
Here you will find some questions and answers from the practical application:
What types of Use Cases exist?
- 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.
What is Use Case 2.0?
Use Cases are often too extensive to be realised within a Sprint in Scrum, for example. So the question is: How can companies plan agilely with Use Cases?
Ivar Jacobsen, Ian Spence and Kurt Bittner provided the answer in December 2011 with the book “USE-CASE 2.0 – The Guide to Succeeding with Use Cases”. It reads: A use case is cut into slices along its processes, each of which can be realised within a sprint. The procedure is called slicing, and the result is use case slices.
here you can find more information about Use Case 2.0.
'What are Misuse Cases?
A Misuse Case is an improper use case. It describes an interaction that a system should not allow and even prevent.
The approach was first described in 2001 by Guttorm Sindre and Andreas Lothe Opdahl in “Capturing Security Requirements through Misuse Cases”. Misuse Cases add a valuable perspective to conventional Use Cases. This perspective can be used to think about operating and security aspects and to identify corresponding requirements.
Here you can find more information on Misuse Cases.
What is the difference between a Use Case and a User Story?
User Stories are very popular in agile product development. A User Story is a simple description of a function of a system from the perspective of a user that offers them a benefit. In contrast to a Use Case, however, it does not offer any contextual information and does not provide a sufficient mechanism for identifying possible hazards of work that has not yet been completed. Use Cases therefore address a larger context.
Use Case 2.0 offers an approach for cutting use cases into smaller parts – known as slices – that can be realised in Sprints. A User Story would therefore describe a specific scenario, while the Use Case comprises several of these scenarios.
Who offers software for creating Use Cases?
There is a whole range of providers that offer support in the creation of Use Cases. Here is a small selection:
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?
- What is Use Case 2.0 and what are Misuse Cases and why are they useful?
- What are challenges and what useful tips exist?
Knowledge on 14 pages to take away.
Impulse to discuss:
How do you handle exceptional situations or unforeseen user behaviour in the context of a Use Case?
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] Business Use Cases – Da ist noch jede Menge Musik drin
[2] 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:
Which elements does a Use Case Diagram contain?
How does slicing work in Use Case 2.0?
How can Misuse Cases be visualised?