Activity:
|
Purpose
|
|
Role: Business-Process Analyst | |
Frequency: As required, typically occurring multiple times in an iteration, and most frequently in early iterations. | |
Steps
|
|
Input Artifacts: | Resulting Artifacts: |
Tool Mentors: | |
More Information: |
Workflow Details: |
A business actor candidate is any individual, group, organization, company, or machine that interacts with the business such as:
If the business you are going to model is part of a large company, these categories may also contain business actors such as:
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 Guidelines: 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 Guidelines: Business Use-Case Model.
It is helpful to study the business actor's lifecycle to determine the answers to questions such as:
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:
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 activities 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 activities that:
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 activity in the existing business. These activities 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 Guidelines: Business Use-Case Model and Guidelines: 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 Guidelines: Business Goals 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 Activity: Detail a Business Use Case.) To determine high-priority business use cases:
Refer to Guidelines: 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 activities 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 Guidelines: 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 Guidelines: Communicates-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:
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 Guidelines: 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:
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 checkpoints for the Business Use-Case Model while you are working on it. The interested parties must determine if:
For more issues to review, see Checkpoints: Business Use-Case Model, Checkpoints: Business Use Cases, Checkpoints: Business Goal, and Checkpoints: Supplementary Business Specifications.
This content developed or partially developed by Empulsys BV. |
Rational Unified Process |