Use case

from Wikipedia, the free encyclopedia
Example of a use case diagram in the Unified Modeling Language . The two use cases SMS verschickenand Fotomessage verschickenone Mobilfunkbetreibersare specified.
Cockburn style hierarchy of use cases

An application (Engl. Use case ) brings together all the possible scenarios that can occur when a player tried using the system under consideration for a specific professional goal (Engl. Business goal ) to achieve. It describes what can happen in terms of content when trying to achieve the goal and abstracts from concrete technical solutions. The outcome of the use case can be a success or a failure / cancellation.

General

Use cases are typically named as the goals are called from the point of view of the stakeholders: register a member , withdraw money , return a car .

The granularity of use cases can differ greatly: At a very high level, a use case only describes what happens very roughly and abstractly. However, the use case writing technique can be refined down to the IT process level so that the behavior of an application is described in detail. This contradicts the original intention of use cases, but is sometimes useful.

Use cases and business processes are often imprecisely delimited from one another. The reference to systems theory shows, however, that use cases and business processes each describe a different view of the system to be modeled:

  • Use cases describe what the environment expects from the system.
  • A business process describes a sequence of individual activities that are carried out step by step in order to achieve a business or operational goal.

This delimitation applies equally to companies and software regardless of the type of system to be modeled. Nor is it to be equated with the distinction between white box and black box modeling .

The terms business use case and system use case, on the other hand, describe the scope of the system under consideration:

  • In the case of a system application, the scope of the content is set by the system to be developed.
  • In a business use case, the scope of the content is set by an organizational unit, for example a company or department.

Business use cases are usually used to embed the system use cases in a common context and to uncover additional requirements.

Use cases were used before the UML was established . Related use cases can be shown in a use case diagram. This is often used to create a system context diagram.

Structure of a use case

The content structure of a use case is usually based on a template to be defined, which must be worked out depending on the context of the later use of the use case. Mostly, differently formalized templates are used for different analysis phases, from the purely prosaic short description to a complete, elaborated application.

As an example, a template after Cockburn is presented here:

Name and identification number
Use cases have a name and are numbered according to functional groups, e. B. UC 2.01.
Description ( description )
Here is a brief description of what happens in the application. Briefly means that there are two or three lines, rarely more.
Actors involved ( actors )
Actors are involved persons or systems outside (!) The described system. E.g. user, registered user, customer, system, billing process. The actors are presented in a separate section beforehand. Jacobson distinguishes two types of actors: Primary actors are the actual users of the system. In addition to these, there are also secondary actors (also: “supporting actors”) who monitor and maintain the system and support the primary actor in achieving its goals.
status
The status indicates how far the work on the use case has progressed. Examples are in progress, ready for review, in review, rejected and accepted.
Use cases used ( includes )
If the use case uses other use cases, these cases are listed here. Name and identification number must be listed.
Trigger ( rational or trigger )
The technical reason (s) that this use case is being carried out.
Preconditions ( preconditions )
All conditions that must be met for this use case to work. If there are no preconditions, it says "none".
Invariants
All conditions that must not be changed within and by the application, i.e. that must still be guaranteed even in a failure or error scenario.
Postconditions / result ( postconditions )
The state that is expected after the use case has run successfully.
Standard flow ( normal flow )
Here is the typical scenario that is easy to understand or the most common one. At the end there is the achievement of the primary actor's goals. The process steps are numbered and usually described in structured language. However, schedules can also be used when appropriate. Using the UML , these process steps can be represented in activity diagrams or use case-oriented sequence diagrams .
Alternative process steps ( alternative flow )
These are scenarios that can occur outside of the standard process when the use case (attempted) to achieve its goals. They are mostly shown as conditional branches of the normal process steps. At the end there is failure, the achievement of goals by the primary actor or a return to the standard process.
Hints
Brief explanations for a better understanding, notes on side effects, quantity structures where necessary and everything else that cannot be described above.
Change History ( use case history )
Versioning, name of the author, date

Methodological notes

This article or section needs to be revised. Details should be given on the talk page. Please help to improve it , and then remove this flag.

A use case describes the interactions between the user and the system that are necessary to achieve a technical goal of the user. The processes described must not become too complex. The coffee break test described by Alistair Cockburn can serve as a guide : The application is too complex if “the user would take a coffee break during the interactions”.

Differentiation from the user story

In agile software development, originally specifically in Extreme Programming (XP) , use cases are written in an even tighter form due to the organizational peculiarities. Due to this even more concise form of presentation, they are not called use cases, but are referred to as user stories . A user story in XP is more like a short description of a classic use case.

Use case 2.0

In December 2011, Ivar Jacobson, Ian Spence and Kurt Bittner published the Use Case 2.0 concept. It describes a scalable, agile technique for developing requirements with which the incremental system development can be controlled. The principles of the new concept are:

  • Describe things simply - with stories ("stories")
  • Understand the "big picture"
  • Focus on benefit
  • Build the system "in slices"
  • Deliver the system in increments
  • Adapt to the needs of the team

The problem solution for agile project planning with use cases is provided by the technique of "slicing" - the cutting of a use case into smaller units, which can then be implemented within a sprint .

Further topics

  • With the robustness analysis, special properties of the use cases can be examined.

literature

Web links

Individual evidence

  1. ^ Ivar Jacobson et al. a .: Actors . In: Object-Oriented Software Engineering . Addison-Wesley, Wokingham UK 1993, ISBN 0-201-54435-0 , pp. 157-159 .
  2. ↑ Cockburn: Creating Use Cases effectively . mitp, Bonn 2003, p. 231.