About UML: Use Cases

Use Cases

In software and systems engineering, the phrase use case is a polyseme with two senses:

1. A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of software may be useful.
2. A potential scenario in which a system receives an external request (such as user input) and responds to it.

This article discusses the latter sense.

A use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modeling Language (UML) as an actor) and a system to achieve a goal. The actor can be a human or other external system. In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in the Systems Modeling Language (SysML) or as contractual statements.

General principle

Use cases are a technique for capturing, modelling and specifying the requirements of a system. A use case corresponds to a set of behaviours that the system may perform in interaction with its actors, and which produces an observable result that contribute to its goals. Actors represent the role that human users or other systems have in the interaction.

In the requirement analysis, at their identification, a use case is named according to the specific user-goal that it represents for its primary actor. The case is further detailed with a textual description or with additional graphical models that explains the general sequence of activities and events, as well as variants such as special conditions, exceptions or error situations.

According to the Software Engineering Body of Knowledge (SWEBOK), use cases belong to the scenario-based requirement elicitation techniques, as well as the model-based analysis techniques. But the use cases also supports narrative-based requirement gathering, incremental requirement acquisition, system documentation, and acceptance testing.

Variations

There are different kinds of use cases and variations in the technique:

• System use cases specify the requirements of a system to be developed. They identify in their detailed description not only the interactions with the actors but also the entities that are involved in the processing. They are the starting point for further analysis models and design activities.
• Business use cases focus on a business organisation instead of a software system. They are used to specify business models and business process requirements in the context of business process reengineering initiatives.
• Essential use cases, also called abstract use cases, describe the potential intents of the actors and how the system addresses these, without defining any sequence or describing a scenario. This practice was developed with the aim of supporting user-centric design and avoiding to induce bias about the user-interface in the early stage of the system specifications.
• Use Case 2.0 adapts the technique for the context of agile development methods. This technique enriches the requirement gathering practice with support for user-story narratives. It also provides use case “slices” to facilitate incremental elicitation of requirements and enable incremental implementation.

Scope

The scope of a use case can be defined by subject and by goals:

• The subject identifies the system, sub-system or component that will provide the interactions.
• The goals can be structured hierarchically, taking into account the organisational level interested in the goal (e.g. company, department, user), and the decomposition of the user’s goal into sub-goals. The decomposition of the goal is performed from the point of view of the users, and independently of the system, which differs from traditional functional decomposition.

Usage

Use cases are known to be applied in the following contexts:

• Object Oriented Software Engineering (OOSE), as driving element;
• Unified Modeling Language (UML), as a behavioral modelling instrument;
• Unified Software Development Process (UP) and its fore-runner, the IBM Rational Unified Process (RUP);
• up-front documentation of software requirements specification (SRS), as alternative structure for the functional requirements;
• deriving the design from the requirements using the entity-control-boundary approach;
• and agile development.