Concept: Business Use Case
A sequence of actions performed in a business that produces a result of observable value to an actor (customer, stakeholder, etc) of the business. From an individual actor's perspective, a business use case defines the complete workflow or interaction that produces the desired results.
Relationships
Main Description

Overview

A business use case describes the interactions between one of more Actors and the business in order to provide an observable result of value for the initiating actor.

The functionality of a business is defined by different business use cases, each of which represents a specific goal (to obtain the observable result of value) for a particular actor.

In an automated teller machine shown in Figure 1, the Bank Customer can withdraw cash from an account, transfer funds between accounts, or deposit funds to an account. These correspond to specific goals that the actor has in using the business. 


Figure 1: ATM Use-Case Example

Figure 1: ATM Use-Case Example

Each business use case is associated with a goal of one of the actors. The collection of use cases constitutes all the possible ways of using the business. You must be able to determine the goal of a business use case simply by observing its name.

A business use case describes the interactions between the actor(s) and the business in the form of a dialog between the actor(s) and the business, structured as follows:

  1. The actor <<does something>>
  2. The business <<does something in response>>
  3. The actor <<does something else>>
  4. The business ...

Each dialog of this form is called a "Flow of Events".

Because there are many flows of events possible for achieving the goal (for example, the flow can differ depending upon specific input from the actor), and there are situations in which the goal cannot be achieved (for example, a required business resource is currently unavailable), each use case will contain several flows, including one "Basic Flow of Events" and several "Alternative Flows".

The Basic Flow of Events specifies the interactions between the actor(s) and the business for the ideal case, where everything goes as planned, and the actor's goal (the observable result of value) is met. The basic flow represents the main capability provided by the business for this use case.

As the name implies, Alternative Flows specify alternative interactions associated with the same goal.

Closely related to business use cases is the concept of a scenario. A scenario is a specific flow of events, for a specific set of inputs to the business, states of the business, and states of the business's environment.

Properties of Business Use Cases

Name

Each business use case must have a name that indicates what is achieved by its interaction with the actors. The name can use several words to be understood. Note: No two use cases can have the same name.

Brief Description

The brief description of the use case must reflect its purpose.

Flow of Events

Flow of Events - Contents

The flow of events must describe the use case's flow of events clearly enough for an outsider to easily understand. Remember, the flow of events represents what the business does, not how the business is design to perform the required behavior.

Follow these guidelines for the contents of the flow of events:

  • Describe how the use case starts and ends.
  • Describe what data is exchanged between the actor and the business.
  • Describe the flow of events, not only the functionality. To enforce this, start every action with "When the actor ... ".
  • Describe only the events that belong to the business use case, and not what happens in other business use cases or outside of the scope of the business being described.
  • Avoid vague terminology.
  • Detail the flow of events. Specify what happens when, for each action. 
  • It does not mention actors who do not communicate with it. If it did mention other actors, it would make the description difficult to understand and maintain.

If you have used certain terms in other business use cases, be sure to use the exact same terms in this business use case, and that the meaning of the terms is consistent. To manage common terms, put them in a glossary.

Flow of Events - Structure

The two main parts of the flow of events are basic flow of events and alternative flows of events. The basic flow of events covers what "normally" happens when the business use case is performed. The alternative flows of events cover behavior of optional or exceptional character in relation to the normal behavior, and also variations of the normal behavior. You can think of the alternative flows of events as detours from the basic flow of events, some of which will return to the basic flow of events and some of which will end the execution of the use case.

The straight arrow in Figure 2 represents the basic flow of events, and the curves represent alternative paths in relation to the normal. Some alternative paths return to the basic flow of events, whereas others end the use case.

Diagram described in caption. 

Figure 2: Typical structure of a business use case flow of events

Both the basic and alternative flows can be further structured into steps or sub-flows. In doing this, your main goal is readability of the text. A guideline is that a sub-flow can be a segment of behavior within the business use case that has a clear purpose, and is "atomic" in the sense that you do either all or none of the actions described.

Special Requirements

In the Special Requirements of a use case, you describe all the requirements associated with the business use case that are not covered by the flow of events. These are non-functional requirements that will influence the business design. See also the discussion on non-functional requirements in Concept: Requirements.

Preconditions and Post-conditions

A precondition is the state of the business and its environment that is required before the use case can be started. Post-Conditions are the states the business can be in after the use case has ended. It can be helpful to use the concepts of precondition and post-condition to clarify how the flow of events starts and ends. However, only use them only if the audience for the description of the use case agrees that it is helpful. Figure 3 shows an example.

Diagram described in caption.



Figure 3: Illustration of preconditions and resulting post-conditions

Examples

A precondition for the use case Cash Withdrawal in the ATM machine: The customer has a personally issued card that fits in the card reader, has been issued a PIN number, and is registered with the banking system.

A post-condition for the use case Cash Withdrawal in the ATM machine: At the end of the use case, all account and transaction logs are balanced, communication with the bank is reinitialized and the card is returned to the customer.

Performance Goals

Some common metrics to describe how the business operates: 

  • Time - an approximation of the time it takes to perform the workflow, or part of the workflow. 
  • Cost - an approximation of the cost of executing the workflow, or part of the workflow.
  • Quality - for example, "no more than 2% of products are defective when they come off the production line".

A major challenge is to understand what scenarios are relevant to measure. Criteria to use are frequency of the scenario, or business relevance of the scenario. If you can determine that a particular part of the workflow has importance, you can save yourself some effort by only measuring the cost or time of that subflow. 

Performance goals can be entered in the Special Requirements section of the business use case.


More Information