Activity: Detail a Business Use
Case
Purpose
- To describe the business use case's
workflow in detail.
- To describe the business use case's workflow so that the customer, users, and
stakeholders can understand it.
|
Steps
|
Input Artifacts:
|
Resulting
Artifacts:
|
Worker: Business
Designer |
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.
Brainstormaccept 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.
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 terms
definition without discussing with the other members of the project team.
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.
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-, include-, or generalization-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.
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.
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.
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).
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.
|