Purpose
  • To define the boundaries of the business to be modeled.
  • To define who and what will interact with the business.
  • To outline the processes in the business.
  • To create diagrams of the business use-case model.
  • To develop a survey of the business use-case model.
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: 

Find Business Actors To top of page

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 Guidelines: Business Actor.

Find Business Use Cases To top of page

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:

  • 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 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:

  • 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 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.

Consider Business GoalsTo top of page

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.

Prioritize Business Use Cases To top of page

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:

  • 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 Guidelines: Business Architecture Document for more criteria for identifying architecturally significant business use cases.

Develop an Outline of the Workflow of Business Use Cases To top of page

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.

Describe How Business Actors and Use Cases Interact To top of page

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.

Package Business Use Cases and Actors To top of page

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.

Present the Business Use-Case Model in Use-Case Diagrams To top of page

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 Guidelines: Use-Case Diagram in the Business Use-Case Model.

Develop a Survey of the Business Use-Case Model To top of page

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

Evaluate Your Results To top of page

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:

  • 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 Checkpoints: Business Use-Case Model, Checkpoints: Business Use Cases, Checkpoints: Business Goal, and  Checkpoints: Supplementary Business Specifications.




This content developed or partially developed by http://www.empulsys.com/rupbm -- This hyperlink in not present in this generated websiteEmpulsys BV.

Rational Unified Process   2003.06.13