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 them to:

• Name at least ten activities they think should 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 the business actor, or events that the business use case should react to.

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-collecting activity, you will undoubtedly have ideas as to how the business workers and business entities are organized. You should of course write these ideas down and save them to use later on.

Detail the Workflow of the Business Use Case

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

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

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

Refer to the Glossary as you write the descriptive text. Do not change a term’s definition without discussing with the other members of the project team.

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 the subflows can combine in various ways if 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 in 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 flows. It is recommended that you describe each subflow in a separate supplement to the workflow, and this should be mandatory for the following cases:

• Subflows that occupy a large segment of a given workflow.
• Exceptional workflows. This helps the business use case's main flow to stand out more clearly.
• Any subflow that can be executed at several intervals in the same workflow.

If a subflow involves only a minor part of the complete workflow, it is better to describe it in the body of the text.

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 on 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 should 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

Any piece 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 of the business use case, should be described in the Special Requirements of the business use case.

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. Focus on goals that are relevant from an information-system perspective.

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 describe what the extension points are (see Guidelines: Business Use Case, discussion on extension points).

Evaluate Your Results

A business use case is only complete 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. A walkthrough is a method of evaluation in which 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 situation with specific persons as actors as you walk through the business use case.

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

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process