Artifact: Business
Use-Case Realization
|
A Business Use-Case Realization describes how business workers, business entities, and business events collaborate to perform a particular business use case. |
|---|---|
| Other Relationships: |
Part Of Business Analysis Model
|
| Role: | Business Designer |
| Optionality/Occurrence: | Can be excluded. Business Use-Case Realizations should be modeled if organizational workflow is important or if potential changes may affect the way the business operates. |
| Templates and Reports: | |
| Examples: | |
| UML Representation: | Collaboration, stereotyped as <<business use-case realization>> |
| More Information: |
| Input to Activities: | Output from Activities: |
Purpose
While a Business Use Case describes what steps must be performed in order to deliver value to a business stakeholder, a Business Use-Case Realization describes how these steps are performed within the organization. Business Use Cases are described from an external perspective, while Business Use-Case Realizations are described from an internal perspective.
Business Use-Case Realizations are used by stakeholders to verify that the project team (or other parties) understand how the business operates. Stakeholders also use them when identifying and prioritizing improvement to the organization. Business-process analysts and business designers use Business Use-Case Realizations to define the roles, responsibilities, and information required within the organization in order to realize business use cases. The effects of changes to the organization, such as business process automation or business process outsourcing, might be considered when using Business Use-Case realizations. Systems analysts and software architects use Business-Use Case realization to understand how a software system fits into the organization.
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 Artifact: 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 using the aggregation "types" and "relationships" on a collaboration traced to the use case. |
| Interaction Diagrams | These diagrams (sequence and communication diagrams) describe how a business use case is realized in terms of collaborating objects. | Participants are owned via aggregation "behaviors". |
| Class Diagrams | These diagrams describe 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, in 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". |
| Realization Relationship | A realization relationship to the business use case in the Business Use-Case Model that is realized. | Realization relationship. |
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 Business 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 Business Use-Case Realization report (containing all diagrams and properties) can be generated with Rational SoDA.
For more information, see tool mentors: Managing Use Cases with Rational Rose and Rational RequisitePro and Creating a Business Use-Case Realization Report Using Rational SoDA.
Timing
Business Use-Case Realizations are identified and prioritized during the Inception phase. The critical or high-priority Business Use-Case Realization should be detailed during late Inception/early Elaboration phases, in order to stabilize the business architecture. In a business (re-) engineering project, the rest of the Business Use-Case Realizations can be detailed during the Construction phase. When business modeling is being done as part of a software development/deployment project, all Business Use-Case Realizations that are relevant to the software system should be detailed during the Elaboration phase.
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.
- The relationships between business workers, business entities, and business events 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
In many cases, the focus of this artifact is the activity diagram, in which you define what responsibilities belong to which business worker by using swimlanes. This is where you make key decisions about what to automate. Often, the Business Use-Case Realization Specification with the textual properties of the artifact can then be excluded, and any derived requirements can go in the Supplementary Business Specification instead. Activity diagrams can also indicate the sending and receiving of business events between business workers.
If the Business Use Cases themselves will not be modified, but instead the realization of the Business Use Cases will change, the Business Use-Case Realizations can be used to compare current (as-is) process descriptions with target (to-be) process descriptions. For example, imagine that an existing software system is going to be replaced by a standard software product that will be administered by an external partner. In such a case, Business Use-Case Realizations can be used to assess the impact of this change on the organization.
Because Business Use-Case Realizations are generally more detailed and specific than Business Use Cases, they can also be used to illustrate differences between different contexts of a more abstract Business Use Case. For example, consider the case in which customers must be serviced using different communication channels (Internet, call center, mail, or electronic messaging). The steps performed during a business use-case Request Quotation or Accept Proposal will remain unchanged, but the ways in which this business use case is performed will differ per channel. Business Use-Case Realizations can be used to illustrate channel-specific realization of the business use case.
|
This content developed or partially developed by  Empulsys BV.
|
