Artifact: Business Use Case
|
A Business Use Case (class) defines a set of business use-case instances in which each instance is a sequence of actions that a business performs that yields an observable result of value to a particular business actor. |
|---|---|
| Other Relationships: |
Part Of Business Use Case Model
|
| Role: | Business Designer |
| Optionality/Occurrence: | Can be excluded. Business Use Cases should be used when business processes need to be understood or changed. |
| Templates and Reports: | |
| Examples: | |
| UML Representation: | Use case, stereotyped as <<business use case>> |
| More Information: |
| Input to Activities: | Output from Activities: |
Purpose
A Business Use Case describes a business process from an external, value-added point of view. Business Use Cases are business processes that cut across organization boundaries, possibly including partners and suppliers, in order to provide value to a stakeholder of the business.
Business Use Cases are useful for anybody who wants to know what value the business provides and how it interacts with its environment. Stakeholders, business-process analysts, and business designers use Business Use Cases to describe business processes and to understand the effect of any proposed changes (for example, a merger or a first CRM implementation) on the way the business works. Business Use Cases are also used by system analysts and software architects to understand the way a software system fits into the organization. Test managers use Business Use Cases to provide context for developing test scenarios for software systems. Project managers use Business Use Cases for planning the content of business-modeling iterations and tracking progress.
Properties
Property Name |
Brief Description |
UML Representation |
|---|---|---|
| Name | The name of the Business Use Case. | The attribute "Name" on model element. |
| Brief Description | A brief description of the role and purpose of the Business Use Case. | Tagged value, of type "short text". |
| Performance Goals | A specification of the metrics relevant to the Business Use Case, and a definition of the goals of using these metrics. | Tagged value, of type "formatted text". |
| Workflow | A textual description of the workflow that the Business Use Case represents. The flow should describe what the business does to deliver value to a business actor, not how the business solves its problems. The description should be understandable by anyone within the business. | Tagged value, of type "formatted text". |
| Category | Whether the Business Use Case is of the category "core," "'supporting," or "management." | Tagged
value, of type "short text".
Optionally, you may choose to use stereotypes with special icons to separate categories of use cases. |
| Risk | A specification of the risks of executing or implementing the Business Use Case. Risk is defined in terms of the potential difference between added value as expected versus added value as provided. | Tagged value, of type "formatted text". |
| Possibilities | A description of the estimated improvement potential of the Business Use Case. | Tagged value, of type "formatted text". |
| Process Owner | A definition of the owner of the business process, that is, the person who manages the changes and plans for changes. | Tagged value, of type "formatted text". |
| Special Requirements | The Business Use-Case characteristics and quantifiers that are not covered by the workflow as it has been described. | Tagged value, of type "short text". |
| Extension points | A list of locations within the flow of events of the Business Use Case at which additional behaviors can be inserted using the extend-relationship. | Tagged value, of type "short text". |
| Supported Business Goals | Stereotyped dependencies indicating the Business Goals supported by the Business Use Case. | Dependency. |
| Relationships | The relationships, such as communicates-associations, include-and extend-relationships, in which the Business Use Case participates. | Owned by an enclosing package, via the aggregation "owns". |
| Activity Diagrams | These diagrams show the structure of the workflow. | Participants are owned via the aggregation "types" and "relationships" on a collaboration traced to the use case. |
| Use-Case Diagrams | These diagrams show the relationships involving the Business Use Case. | Participants are owned via the aggregation "types" and "relationships" on a collaboration traced to the use case. |
| Illustrations of the Workflow | Hand-drawn sketches or the results of storyboarding sessions. | Tagged value, of uninterpreted type. |
Brief
Outline
A template is provided for a Business Use Case Specification, which contains the textual properties of the Business Use Case. This document is used with a requirements management tool, such as Rational RequisitePro, for specifying and marking the requirements within the Business Use-Case properties.
The diagrams of the Business Use Case can be developed in a visual modeling tool, such as Rational Rose. A Business Use-Case report (with all properties) may be generated with Rational SoDA.
For more information, see tool mentors: Managing Use Cases with Rational Rose and Rational RequisitePro and Creating a Use-Case Report Using Rational SoDA.
Timing
Business Use Cases are identified and possibly briefly outlined early in the Inception phase, to help define the scope of the project. If business modeling is being done as part of a business (re-) engineering project, then the architecturally significant Business Use Cases will be detailed during the Elaboration phase and the rest during the Construction phase. If business modeling is being done as part of developing a software system, the Business Use Cases applicable to the software system are then described in more detail during the Elaboration phase.
Responsibility
A business-process analyst is responsible for the integrity of the Business Use Case, ensuring that:
- It correctly describes how the organization does its business.
- The workflow description is readable and suits its purpose.
- The include- and extend-relationships originating from the Business Use Case are justified and kept consistent.
- The role of the Business Use Case where it is involved in communicates-associations is clear and intuitive.
- The diagrams describing the Business Use Case and its relationships are readable and suit their purpose.
- The Special Requirements are readable and suit their purpose.
- The pre-conditions are readable and suit their purpose.
- The post-conditions are readable and suit their purpose.
We recommend that the person responsible for a Business Use Case is also responsible for its enclosing Business Use-Case package. For more information, refer to Guidelines: Business Use-Case Model.
Tailoring
If you perform business modeling merely to chart an existing target organization, with no intention of changing it, you could exclude the following sections from the outline of the Business Use-Case Specification:
- Performance Goals
- Risks
- Possibilities
- Process Owner
|
This content developed or partially developed by  Empulsys BV.
|
