Guidelines: Business Use Case

Business Use Case

A business use-case instance is a sequence of actions performed in a business that produces a result of observable value to an individual actor of the business.

A business use case defines a set of business use-case instances. A business use case has a name.

Topics

Explanation

The processes of a business are defined as a number of different business use cases, each of which represents a specific workflow in the business. A business use case defines what should happen in the business when it is performed; it describes the performance of a sequence of actions that produces a valuable result to a particular business actor.

A passenger can either travel individually or with a group. When traveling with a group, a passenger is accompanied by a tour guide.

A business use case describes "a sequence of actions performed in a business that produces a result of observable value to an individual actor of the business". Hence, from an individual actor’s perspective, a business use case defines the complete workflow that produces the desired results. This is similar to what is generally called a "business process", but "a business use case" has a much more precise definition.

The definition of the business use case concept contains a number of keywords, which are essential to understanding what a business use case is:

Business use case instance – Defined above is really a specific business workflow ; that is, an instance. In reality, there are a great number of possible workflows, many of them very similar.

To make the use-case model understandable, similar workflows are grouped together into a business use case—a "class" in terms of the object model. To identify and describe a business use case means to identify and describe the class-like business use case, not the individual use case instances.

An individual actor – The actor is probably the real key to finding the correct business use case. Starting with individual actors—or really instances of actors—helps avoid business use cases that are too large or complex.

When determining suitable actors, first try to name at least two or three different people who could perform as the actor in question, then critically evaluate the support each individual requires. For example, suppose you initially identify an actor called "customer". Later, as you look deeper into the support each individual customer requires, you might find three rather different customers: the normal "user" of the product, the "purchaser" and the "evaluator", who are competent to compare the product with its competitors. Each of these may require a separate business use case, because they represent different roles that can be played toward the business.

A result of observable value – This expression is very important in determining the correct extent of a business use case, which should be neither too small nor too big. Stating that the business use case should give a result of observable value, that is, both perceived and measurable, helps you to find a complete flow, and avoid business use cases that are too small.

A good business use case helps an actor perform a task that has an identifiable value. It may be possible to put a price on a successfully performed business use case. A too-small business use case will have a limited scope, thus also little re-engineering potential.

In a business – The words "actions performed in a business", means both that the business provides the business use case to the actor, and that the business use case only covers what is actually done within the business. Supporting work done elsewhere is not included.
Action – The actions are invoked either on request from an actor to the business or at a certain point in time. Actions include internal activities and decisions, as well as requests to either the invoked actor or other actors.

Business services are described through different business use cases, each with a task of its own. The collected set of business use cases constitute all the possible ways of using the business. See also Guidelines: Business Use-Case Model.

How to Name a Business Use Case

The name of the business use case should express what happens when an instance of the business use case is performed. The form of the name should therefore be active, typically described by the gerund form of the verb (Checking-in) or a verb and a noun together.

The names can either describe the activities in the business use case from an external or an internal viewpoint, for instance placing an order or receiving an order. Although a business use case describes what happens within the business, it is often most natural to name the business use case from its primary actor’s point of view. Once you have made a decision which style is to prefer in your case, you should follow the same rule for all business use cases in the business model.

Business Use Cases vs. Business Use-Case Realizations

In a use-case driven business engineering project, you develop two views of the business.

The business use case itself presents an external view of the business, which defines what is essential to perform for the business to deliver the desired results to the actor. It also defines what interaction the business should have with the actors when the business use case is executed. Such a view must be developed when you are deciding and agreeing on what should be done in each business use case. A collection of business use cases gives an overview of the business that is very useful for informing employees of what different parts of the business are doing, and what results are expected.

A business use-case realization, on the other hand, gives an internal view of the business use case, which defines how the work should be organized and performed in order to achieve the same desired results. A realization encompasses the business workers and business entities that are involved in the execution of a business use case and the relationships between them that are required to do the job. Such views must be developed to decide and agree on how the work in each business use case must be organized to achieve the desired results.

Both views of the business use case are primarily intended for people within the business - the external view for people who work outside the business use case, the internal view for people who work inside the business use case.

Classes and Instances of Business Use Cases

As a business operates, you will find that you can identify an almost unlimited number of separate workflows. A use-case instance is simply a specific workflow, or scenario. It corresponds to the work that a number of collaborating business members perform in their roles defined in the object model, and not to any particular business member or any role that the member is playing.

A business use case is what you normally work with to make the use-case model understandable, and to avoid drowning in details. It represents the union of a number of business use-case instances with workflows that are similar, but normally not identical.

Typically, an employee who is competent to act in a certain role will do this in instances of several different business use cases.

Example:

At the airport check-in counter, the two business use cases, Individual Check-in and Group Check-in both require the same competencies from the employee at the check-in counter, as well as access to the same information about a certain departure. Thus, both use cases can and should be designed using the same Check-in Agent worker and Departure entity.

Structures in Business Use-Case Workflows

Most workflows may be thought of as several subflows, which together yield the total flow. Sometimes several business use cases in the business have a common subflow, or the same subflow appears in different parts of one business use case. If this common behavior has any substantial volume, it should be performed by the same workers.

If a subflow is substantial, common to several business use cases, and also forms an independent and naturally delimited part, the model might be clearer if this behavior is partitioned out to a separate business use case. This new business use case is then either included in the original use case (see Guideline: Include-Relationship in the Business Use-Case Model), an extension to it (see Guidelines: Extend-Relationship in the Business Use-Case Model), or a parent use case to it (see Guidelines: Use-Case-Generalization in the Business Use-Case Model).

Example:

At the airport check-in counter, the two business use cases, Individual Check-in and Group Check-in both use the same procedure to handle an individual passenger’s baggage. Because the subflow is independent of the ticket handling, and is logically connected, it is modeled separately in the business use case, Baggage Handling.

The workflow of a business use case can be visualized using activity diagrams, see Guidelines: Activity Diagram in the Business Use-Case Model.

For more information on structuring and describing the workflow of a business use case, see Guidelines: Use Case, the discussions on Flow of Events.

Extent of a Business Use Case

It is sometimes hard to decide if a service is one, or several business use cases. Apply the definition of a business use case to the airport check-in process. A passenger hands his ticket and baggage to the check-in agent, who finds a seat for the passenger, prints a boarding pass and starts baggage-handling. If the passenger has normal baggage, the check-in agent prints baggage tag and customer claim check, and terminates the business use case by applying the tag to the baggage, and giving the customer claim check, together with the boarding pass, to the passenger. If the baggage has a special shape or special contents so that it cannot be transported normally, the passenger must take it to a special baggage counter. If the baggage is heavy, the passenger must continue on to the airport ticket office to pay for it, because check-in agents do not handle money.

Do you need one business use case at the check-in counter, another at the special baggage counter and a third at the ticket office? Or do you need just a single business use case? Surely, this transaction involves three different types of actions. But the question is, will any of them be of value to a passenger carrying special baggage if he does not do the others? No, it is only the complete procedure—from the moment the passenger approaches the check-in counter until he has paid the extra charge—that has value (and that makes sense to the passenger). Thus, the complete procedure involving the three different counters is a complete case of usage—a business use case.

In addition to this criteria, it is practical to keep descriptions of closely related services together, so that you can review them at the same time, modify them together, test them together, write manuals for them, and in general manage them as a unit.

Notice also that two independent business use cases can have similar beginnings.

Example:

In an insurance company, the business use cases Handle Claim and Handle Request both start when someone (an actor) makes contact with a claim handler. The claim handler and the actor exchange some information to make it clear whether the actor is filing a claim or requesting some information. Then, and only then, is it possible to decide which business use case is performing. Although the two business use cases have similar beginnings, they are not connected.

Extension Points

An extension point opens up the business use case to the possibility of an extension. It has a name, and a list of references to one or more locations within the workflow of the business use case.

Characteristics of a Good Business Use Case

Its name and brief description are clear and easy to understand, even to people outside the business engineering team.
Each business use case is complete from an outside (actor’s) perspective. For example, the business use case Handle Claim in an insurance company starts when a customer files a claim. The Handle Claim business use case is not complete unless it includes a notification about the decision from the insurance company to the customer and (if appropriate) a compensatory payment.
Each business use case normally is involved with at least one actor. Business use cases are initiated by actors, interact with actors to perform the activities, and deliver results.
It is possible, but unusual, for a supporting use case not to interact with an actor. This is true if a business use case is initiated by an internal event and does not have to interact with an actor to perform its activities.

Characteristics of a Good Workflow Description

It must be clear and easy to understand, even for people outside the business engineering team.
It describes the workflow, not just the purpose of the business use case.
It describes only those activities that are inside the business.
It describes all possible activities in the business use case. For example, what happens if a condition is met, as well as what happens if it is not.
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.
It describes only those activities that belong to it, not what is going on in other business use cases that work parallel to it.
It does not mention other business use cases with which it does not have relationships. If the business use case requires that some results exist in the business before it can start, this should be described as a precondition. The precondition should not have any references to the business use cases in which the result was created.
It indicates if the order of any activities described for the business use case is not fixed.
It is structured so that it is easy to read and understand.
The description clearly describes the start and end of the workflow.
Each extends-relationship is described clearly so that it is obvious how and when to insert the business use case.

Characteristics of a Good Abstract Business Use Case

It is substantial. Remember, a concrete business use case must be easy to read, together with its abstract business use cases. Therefore, an abstract business use case should not be too small. If an abstract business use case is not substantial, it should be eliminated and its activities should be described in the affected concrete business use cases.
It contains logically related activities.
It exists for a specific reason. An abstract business use case should contain any of three kinds of activities: those that are common across several business use cases; those that are optional; or those that are important enough that you want to emphasize them in the model.

Rational Unified Process 5.1 (build 43)