Business Use-Case Model		 A business use-case model is a model that describes the processes of a business and their interactions with external parties like customers and partners.
Topics

Explanation To top of page

A primary purpose of the model of business use cases and actors is to describe how the business is used by its customers and partners. Activities that directly concern the customer, or partner, as well as supporting or managerial tasks that indirectly concern the external party can be presented.

The model describes the business in terms of business use cases, which correspond to what are generally called "processes".

Actors and use cases at the check-in counter.

Different Categories of Business Use Cases To top of page

When looking at the activities in a business you will be able to identify at least three categories of work corresponding to three categories of business use cases:

  • First, there are the commercially important activities, often called business processes.
  • Second, there are a lot of activities that are not that commercially important, but have to be performed anyhow to make the business work. Systems administration, cleaning and security are typical examples. The business use cases are of a supporting character.
  • Third, there is management work. Business use cases of management character shows the type of work that affects how the other business use cases are managed and the business’ relationships to its owners.

Typically, a management type of business use case describes in general the relationships between the CEO, and people who work in the business use cases. It also describes how business use cases are developed and "started" (instantiated).

At a restaurant, the core business use cases are marketing and serving dinner, and the supporting business use case is purchasing supplies.

Note that what you regard as a core business use case can sometimes be a supporting business use case in another business. For example, software development is a core business use case in a software development company, while it would be classified as a supporting business use case in a bank or an insurance company.

A Business has Many Business Use Cases To top of page

A business has many business use cases. Instances of several different business use cases, as well as several instances of a single business use case, will normally execute in parallel. There may be an almost unlimited number of paths a use-case instance can follow. These different paths represent the choices open to the use-case instance in the workflow description. Depending on specific events or facts, a use-case instance can proceed along one of several possible paths; for example:

  • Input from an actor.
  • A business rule.

In modeling business use cases, you can assume that use-case instances can be active concurrently without conflicting. At this stage of business development, you should focus on what the business should do. Solve potential resource conflicts during work modeling, at which stage you try to understand how things should work in the business. Or you can solve these problems during the implementation of the new organization by increasing the number of employees who can perform the critical task.

Are Business Use Cases Always Related to Business Actors? To top of page

Every core business use case should have a communicates-relationship to or from a business actor. This rule enforces the goal that businesses be built around the services their users request. If your business use-case model has business use cases that no one requests, this should warn you that something is wrong with the model.

Business use cases can be triggered periodically or they can run for a very long time; a surveillance function is an example of the latter. Even these business use cases have business actors that originally initiated them, and expect different services from them. Otherwise they would not be part of the business. Other business use cases will produce results for a business actor, although they are not explicitly initiated by the business actor. For example, the development of a widely distributed product is seldom initiated by an identifiable customer. Instead, the need for a new product is realized from market studies and the accumulated requests of many users.

Management and supporting business use cases do not necessarily need to connect to a business actor, although they normally have some kind of external contact. A management business use case, for instance, might have the owners of the business, or the board, as its business actor.

Abstract business use cases do not need a business actor, because they are never instantiated ("started") on their own.

Structuring the Business Use-Case Model To top of page

There are three main reasons for structuring the business use-case model:

  • To make the business use cases easier to understand.
  • To reuse parts of workflows that are shared among many business use cases.
  • To make the business use-case model easier to maintain.

To structure the business use cases, we have three kinds of relationships. You will use these relationships to factor out pieces of business use cases that can be reused in other business use cases, or that are specializations or options to the business use case. The business use case that represents the modification we call the addition use case. The business use case that is modified we call the base use case.

  • If there is a part of a base use case that represents a function of which the business use case only depends on the result, not the method used to produce the result, you can factor that part out to an addition  use case. The addition is explicitly included in the base use case, using the include-relationship. See also Guidelines: Include-Relationship in the Business Use-Case Model.
  • If there is a part of a base use case that is optional, or not necessary to understand the primary purpose of the use case, you can factor that part out to an addition use case in order to simplify the structure of the base use case. The addition is implicitly included in the base use case, using the extend-relationship. See also Guidelines: Extend-Relationship in the Business Use-Case Model.
  • If there are business use cases that have commonalities in behavior and structure and that have similarities in purpose, their common parts can be factored out to a base use case (parent) that is inherited by addition use cases (children). The child use cases can insert new behavior and modify existing behavior in the structure they inherit from the parent use case. See also Guidelines: Use-Case-Generalization in the Business Use-Case Model.

Actors and use cases and the check-in counter. Here we also show the inclusion use case Baggage Handling and the extension use case Through Check-In.

You can use actor-generalization to show how actors are specializations of one another. See also Guidelines: Actor-Generalization in the Business Use-Case Model.

See also the discussion on structuring system use cases in Guidelines: Use-Case Model.

Characteristics of a Good Business Use-Case Model To top of page

  • Use cases conform to the business they describe.
  • All use cases are found. Taken together, use cases perform all activities within the business.
  • Every activity within the business should be included in at least one use case.
  • There should be a balance between the number of use cases and the size of the use cases:
  • Few use cases make the model easier to understand.
  • Many use cases may make the model difficult to understand.
  • Large use cases may be complex and difficult to understand.
  • Small use cases are often easy to understand. However, make sure that the use case describes a complete workflow that produces something of value for a customer.
  • Each use case must be unique. If the workflow is the same as or similar to another use case, it will be difficult to keep them synchronized later. Consider merging them into a single use case.
  • The survey of the use-case model should give a good comprehensive picture of the organization.
 

Display Rational Unified Process using frames

 

© Rational Software Corporation 1998 Rational Unified Process 5.1 (build 43)