Artifact: Business Use-Case Realization
 Business Use-Case Realization |
A business use-case realization describes how a particular business use case is realized within the business object model, in terms of collaborating objects (instances of business workers and business entities). |
| UML representation: | Collaboration, stereotyped as ½business use-case realization╗. |
| Worker: | Business Designer |
| Optionality: | Can be excluded. |
| Templates: | |
| Sample Reports: | Business Use-Case Realization Report |
| More information: | |
|
|
| Input to Activities: | Output from Activities: |
Purpose
The following people use the business use-case realization:
- People who analyze, design, and implement the system to understand the context of the system to be built.
- Business designers to describe how processes are performed in the organization.
- System analysts to derive requirements of the system.
- Managers to better understand the context, purpose, and importance of the system to be built.
Properties
|
Property Name |
Brief Description |
UML Representation |
| Workflow Realization | A textual description of how the business use case is realized in terms of collaborating objects. Its main purpose is to summarize the diagrams connected to the business use case (see below), and to explain how they are related. | Tagged value, of type "formatted text". |
| Activity Diagrams | These diagrams show the structure of the workflow, and how the behavior is distributed onto participating business workers and business entities. | Participants are owned via the aggregation "types" and "relationships" on a collaboration traced to the use case. |
| Interaction Diagrams | The diagrams (sequence and collaboration diagrams) describing how a business use case is realized in terms of collaborating objects. | Participants are owned via aggregation "behaviors". |
| Class Diagrams | The diagrams describing the classes and relationships that participate in the realization of the business use case. | Participants are owned via aggregation "types" and "relationships". |
| Derived Requirements | A textual description that collects all requirements, such as automation requirements, on the business use-case realization that are not considered in the business use-case model, but that need to be taken care of when building the system. | Tagged value, of type "short text". |
| Trace Dependency | A trace dependency to the business use case in the business use-case model that is realized. | Owned by the system via the aggregation "trace". |
Brief Outline
A template is provided for a Business Use-Case Realization Specification, which contains the textual properties of the business use-case realization. This document is used with a requirements management tool, such as Rational RequisitePro, for specifying and marking the requirements within the use-case realization properties.
The diagrams of the business use-case realization can be developed in a visual modeling tool, such as Rational Rose. A use-case realization 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 Using SoDA to Create a Business Use-Case Realization Report. (hyperlinks into HTML template in a new window)
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.4 References
1.5 Overview
2. Workflow Realization
3. Derived Requirements
Timing
Business use-case realizations are mainly created during the inception and elaboration phases.
Responsibility
A business designer is responsible for the integrity of the business use-case realization, ensuring that:
- The workflow description from the business use case is correctly interpreted.
- Relationships between business workers and business entities are consistent with and realize the workflow.
- The diagrams describing the business use-case realization and its relationships are readable and suit their purpose.
Tailoring
The focus of this artifact is in many cases the activity diagram, where you define what responsibilities belong to which business worker by using swimlanes. This is where you make key decisions about what to automate. The use-case realization specification with the textual properties of the artifact can then often be excluded, and any derived requirements can instead go in the Supplementary Business Specification.
