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
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:
-
The actor <<does something>>
-
The business <<does something in response>>
-
The actor <<does something else>>
-
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
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.
The brief description of the use case must reflect its purpose.
Flow of Events
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.
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.
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.
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.
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.
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.
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.
|