A business actor candidate is any individual, group, organization, company, or machine that interacts with the business such as:

• customers
• partners
• suppliers
• authorities (legal, regulatory, and so forth)
• subsidiaries
• owners and investors (Decide whether the board of directors should be part of the business or modeled as an actor.)
• information systems outside of the business

If the business you are going to model is part of a large company, these categories may also contain business actors such as:

• other parts of the company
• individual roles within other departments

It is very important to consider the scope of business modeling and the boundaries of what you are defining as the "target organization." If you have chosen only a part of the business as the target organization, then the other parts of the same company also will be business actors.

Name each business actor in such a way that its name denotes its role in the business. Define each business actor by writing a brief description that takes into account its responsibility and why it interacts with the business, including the types of added value that the business actor wants from the business. See Guideline: Business Actor.

To find the primary business use cases, consider what value each business actor receives from the business. Ask yourself what services the business actor expects to receive from the business. It might help to start with the core business use cases-those that serve the customer or the equivalent of the customer in cases in which there is no commercial interaction. For more information on categories of business use cases, see Guideline: Business Use-Case Model.

It is helpful to study the business actor's lifecycle to determine the answers to questions such as:

• What was the business actor's first contact with the business? 
• What stages or states does the business actor go through in relation to the business?
• What does the business actor regard as a meaningful interaction with the business?
• When is the business actor satisfied?
• What events does the business actor expect to be notified of?

From a perspective of supporting the business, processes can also be represented as business use cases. Ask yourself what is required in order to deliver products and services to customers. Of course, the scope of business modeling and the defined business modeling objectives will determine the granularity of supporting business use cases, if you are going to consider them at all. Look for the following kinds of processes:

• development and maintenance of the staff
• development and maintenance of the IT within the business
• development and maintenance of the office and facilities
• security
• legal advice
• partner and contract management
• accounting
• logistics
• purchasing
• marketing analysis and research
• product development

From the perspective of managing the business, processes can be represented as business use cases, although they are seldom as interesting from an information-system aspect. To identify management processes, look for tasks associated with managing the business as a whole, as well as ones that normally interact with the owner actors. Consider what the owner actors receive from the business. Search for tasks that:

• Develop and provide information about the business to owners and investors.
• Set up long-term goals.
• Coordinate and prioritize between the other business use cases in the business.
• Create new processes in the business.
• Plan and execute improvements.
• Monitor the processes in the business.

The lifecycle of a process of this kind often spans one fiscal year.

Another way to identify business use cases is to have domain experts describe every task in the existing business. These tasks are then grouped into business use cases, which are named and briefly described.

You also must consider any defined business goals. Investigating these business goals sometimes discloses a business use case that otherwise would have remained undiscovered.

See Guideline: Business Use-Case Model and Guideline: Business Use Case for additional information.

Review any business goals that have already been described, and consider whether they will be supported by business use cases. If you discover that a business use case supports two completely different goals, you might consider splitting it into two. If a business use case supports very different business goals, you will find it difficult to measure or improve its performance. Business use cases that support none of the already-identified business goals may be unnecessary. Further investigation of these business use cases, on the other hand, may reveal undiscovered business goals.

Business goals must also be considered in comparison to the business actors. Do the identified business goals drive the business toward the business actors that they intend to embrace? Are any business actors not addressed by the business goals? New business goals also might be discovered during this analysis. See Guideline: Business Goal for more information.

Once you have identified the business actors and business use cases, you must prioritize those business use cases that are of high interest and therefore must be described in detail. (See Task: Detail a Business Use Case.) To determine high-priority business use cases:

• Determine the business use cases that will be of interest to the intended system if you perform business engineering to find the requirements of information systems.
• Develop a step-by-step description before deciding whether or not to include any business use cases that are not clearly relevant from an information-system perspective.
• Look for the business use cases that support the most important business goals.

Refer to Guideline: Business Architecture Document for more criteria for identifying architecturally significant business use cases.

To understand the purpose of a business use case, you often need a step-by-step outline of the workflow. The person who will later specify the business use case also will require this step-by-step description.

For example, the first draft of a step-by-step workflow description of the business use case "Individual Check-In" might look like this:

• Passenger enters the queue to check-in counter.
• Passenger gives ticket to check-in agent.
• Check-in agent validates ticket.
• Check-in agent registers baggage.
• Check-in agent reserves seat for passenger.
• Boarding card is printed.
• Check-in agent gives passenger boarding card.
• Passenger leaves check-in counter.

Note that this is a first draft, so it may lack tasks that will be discovered later. You may also include alternative flows in this initial set of steps.

The first draft provides a clear picture of what the business use case does, when it starts, when it stops, and what value it provides. You normally will not need more than an hour to define a rough step-by-step outline for a business use case. (Exceptions are outlines for supporting and management business use cases-they are not usually clear-cut.)

Concentrate on the most important business use cases-that is, those that represent the highest improvement potential. Can the business use case's scope be increased so that work originally done by the customer, or by no one, will now be done by the target organization? Can the scope be diminished so that the customer will now work on tasks previously done by the target organization? A business use case is improved if it serves the customer better, which implies that it becomes simpler, produces better products, offers shorter lead times, and so on. "Customers should be able to penetrate right to the heart of the business" [SEY98].

For each business use case, set measurable goals that can be used to verify whether or not you have succeeded. These business goals can later be refined and translated into other business goals, as well as into the business strategy. When the new target organization is established, business goals can be used to continuously measure how the business use cases are functioning and being improved. 

See Guideline: Business Use Case.

Establish those business actors that interact with the business use case by defining a communicates-association between them. If it is important to show who initiated the communication, you can add navigability to the association. If it improves the readability of the model, you can also name the association.

See Guideline: Communicate-Association in the Business Use-Case Model.

If you have many business use cases, you can divide them into packages to make the documentation easier to understand. For example, business actors can be packaged according to type such as Market, Regulatory Bodies, and Partners. Business use cases can be grouped according to purpose, such as Sales and Marketing, Product Development, and Management. Alternatively, they can be grouped according to business actor such as Shareholders and Investors or Direct Customers.

Use-case diagrams illustrate the combination of business actors, business use cases, and their relationships. A diagram may contain any of the following:

• all the business actors within a package
• a business actor and all other business actors that specialize in the first one
• a business actor and all the business use cases with which it interacts
• business use cases that interact with the same business actors
• business use cases that are usually performed in a sequence
• business use cases that belong to the same use-case package
• the most important business use cases

Note that the diagram of the most important business use cases can function as a summary of the complete Business Use-Case Model and thus prove helpful in reviewing it. See Guideline: Use-Case Diagram in the Business Use-Case Model.

The Survey Description (Report: Business Use Case Model Survey) of the Business Use-Case Model needs to convey the following information:

• the purpose of the business being described
• the typical sequences in which the business use cases are employed
• the parts of the business that are not included in the Business Use-Case Model

At this state, be sure to check the Business Use-Case Model to verify that your work is on track. Do not, however, review the model in detail. You must also consider the checklist for the Business Use-Case Model while you are working on it. The interested parties must determine if:

• All necessary business use cases are identified.
• Any unnecessary business use cases are identified.
• The behavior of each business use case is described in the right order.
• Each business use case's workflow is as complete as possible at this stage.
• The Survey Description of the Business Use-Case Model makes it understandable.

For more issues to review, see Checklist: Business Use Case Model, Checklist: Business Use Cases, Checklist: Business Goal, and  Checklist: Supplementary Business Specification.