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 tasks that must belong to the business use case. Brainstorm-accept every suggestion, regardless of the order and size of the task.
• 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 tasks and interactions according to time. Identify the basic workflow, and add new tasks as needed. The resulting order of tasks 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.

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 Guideline: Business Use Case and Guideline: Use Case, the discussion of the flow of events.

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 Guideline: Business Use-Case Model and Task: Identify Business Goals and KPIs.

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 a task diagram. See Guideline: Activity Diagram in the Business Use-Case Model.

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

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

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.

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.

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

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 checklist for business use cases in Task: Review the Business Use-Case Model.