Activity: Detail a Business Use Case

Collect Information about the Business Use Case

The draft step-by-step description of the workflow will serve as a basis for describing the detailed workflow. However, before you begin describing, you must collect information about the business use case. Form a group that includes members of the project team and people from the business that work in the process. Present a business use case to the group and ask the members to:

• Identify the owner of the business use case. The owner is the role or person responsible for making decisions regarding the performance of and improvements to the business use case. Questions regarding the current way of working must be directed towards the business use case owner.
• Identify at least ten activities that must belong to the business use case. Brainstorm-accept every suggestion, regardless of the order and size of the activity.
• Name at least five interactions with business actors, such as requests from a business actor and events to which the business use case must react.

Organize the activities and interactions according to time. Identify the basic workflow, and add new activities as needed. The resulting order of activities and interactions will serve as the basis for describing the business use case.

During this information-gathering phase, you undoubtedly will have ideas regarding how the business workers and business entities are organized. Be sure to write these ideas down and save them for later use.

Detail the Workflow of the Business Use Case

When you feel you have collected enough background information and arranged it in chronological order, it is time to describe the workflow of the business use case in detail.

Start by describing the normal workflow of the business use case. Look at the business actors and the business use case concurrently, and specify the interactions between them. When the normal workflow is described and relatively stable, start describing the alternative workflows.

Follow the agreed-upon standards regarding the appearance of a business use-case workflow. For more on style, see Guidelines: Business Use Case and Guidelines: Use Case, the discussion of the flow of events.

Identify Business Goals Supported by the Business Use Case

Business use cases must support business goals. If it is difficult to identify the one or more business goals supported by a business use case, it may be a sign that the use case is too abstract, or that the goals are not yet adequately concrete. Consider all identified business goals, because the business use case may support more than one of them. Try to reverse your thinking as well-for example, ask what (as yet unidentified) business goals could the business use case support, given its purpose and workflow? This approach may help you discover business goals or refine existing ones. For more information, see Guidelines: Business Use-Case Model and Activity: Identify Business Goals.

Structure the Workflow of the Business Use Case

A business use case's workflow can be divided into several subflows. When the business use case is activated, its subflows can combine in various ways if one of the following holds true:

• The business use case can proceed from one of several possible paths, depending on the input from a given business actor or the values of some attribute or object. For example, the workflow may take different paths, depending on what happens during the interaction with the business actor.
• The business use case can perform some subflows in optional sequences.
• The business use case can perform several subflows at the same time.

You must describe all these optional or alternative subflows. It is recommended that each subflow be described in a separate supplement to the workflow. In fact, this is mandatory for the following types of subflows:

• Subflows that occupy a large segment of a given workflow.
• Exceptional subflows. Describing these helps the business use case's main workflow stand out more clearly.
• Subflows that can be executed at several intervals in the same workflow.

If a subflow involves only a minor part of the complete workflow, describe it in the body of the text instead of in a separate supplement.

You can illustrate the structure of the workflow with an activity diagram. See Guidelines: Activity Diagram in the Business Use-Case Model.

For more information on structure of a workflow, see Guidelines: Use Case, the discussion of structure of the flow of events.

Illustrate Relationships with Business Actors and Other Business Use Cases

Create use-case diagrams showing the business use case and its relationships to business actors and other business use cases. A diagram of this type functions as a local diagram of the business use case and must be related to it. Note that this kind of local use-case diagram typically is of little value, unless the business use case has extend- or include-relationships that need to be explained, or if there is an unusual complexity among the business actors involved. See also Guidelines: Use-Case Diagram in the Business Use-Case Model.

Describe the Special Requirements of the Business Use Case

Describe any items of information that can be related to the business use case but that are not taken into consideration in the workflow or the performance goals.

Describe Performance Goals of the Business Use Case

Identify the performance goals that currently are relevant in relation to what should be produced for a business actor. If you are going to develop or deploy a business system, focus on goals that are relevant from an information-system perspective. These performance goals may help measure the business case after deployment.

Describe Extension Points

If the business use case is to be extended by another use case (see Guidelines: Extend-Relationship in the Business Use-Case Model), you need to identify and describe the extension points (see Guidelines: Business Use Case, discussion on extension points).

Evaluate Your Results

A business use case is complete only when it describes everything the business performs. Before you finish, make sure the business use case exhibits the characteristic properties of a good use case.

Evaluate each business use case and its workflow. A specific way to evaluate a business use-case workflow is to conduct a walkthrough. In this method of evaluation, the person responsible for the business use case leads one or two members of the project team through the business use-case workflow. Use a scenario: imagine a real-life situation with specific people as actors when you walk through the business use case.

See checkpoints for business use cases in Activity: Review Business Use-Case Model.

This content developed or partially developed by Empulsys BV.

Rational Unified Process