Use case

A use case ( use case engl. ) bundles all possible scenarios that can occur when a player tried using the system under consideration a specific professional goal (german business goal ) to reach. He describes what content can happen when trying to target achievement and abstracts from concrete technical solutions. The result of the use case can be a success or failure / crash.

General

Use cases are classically named so as the destinations are from the perspective of the actors: Member sign, withdraw money, return the car.

The granularity of use cases can vary greatly: On a very high level describes an application of only very coarse and abstract what happens. The technique of use case writing, however, can be refined to the level of IT processes, so that the behavior of an application is described in detail. This contradicts the original intention of use cases, but is sometimes useful.

Application and business process are often separated from each other inaccurate. The reference to systems theory, however, shows that applications and business processes, each describing a different view on the system to be modeled:

• Describe use cases, what awaits the environment by the system.
• A business process describes a sequence of individual activities that are performed step by step to achieve a business or occupational goal.

This definition applies irrespective of the type of system to be modeled for companies and software alike. It is not to be equated with the distinction between white-box and black-box modeling.

The terms business use case (german business use case ) and system application (English system use case ), however, describe the substantive scope of the system under consideration:

• In a system application, the substantive scope of which is set by the system to be developed.
• In a business application, the substantive scope is set by an organizational unit, such as a company or department.

Usually, the business use cases are used for embedding the system use cases in a common context and uncover additional requirements.

Applications have already been used before establishment of the UML. Related applications can be displayed on a use case diagram. Often a system context diagram is created with this.

Construction of a use case

The content is structured a use case usually follows a definable template that must be worked out depending on the context of the later use of the use case. Most also vary greatly formalized templates for various analysis phases used by the purely prosaic Short description up to a full, elaborate application.

An example is a template to Cockburn be presented here:

Methodological notes

A use case describes the interactions between the user and the system which are necessary in order to achieve a professional target of the user. The processes described may not be too complex. A clue can serve the one described by Alistair Cockburn coffee breaks test: The use case is too complex, if it were " the user take a coffee break during the interactions ."

Demarcation from the user story

In agile software development, originally designed in the Extreme Programming (XP), use cases are written in an even more concise form the basis of organizational characteristics. Due to this even more rarified form of representation they do not carry the name of the use case, but are referred to as user story. A user story in XP is more similar to the short description of a classic use case.

Advanced Topics

• With the robustness analysis of specific characteristics of the use cases can be examined.