Work Product (Artifact): Business Use-Case Realization
A Business Use-Case Realization describes how business systems, business workers, business entities, and business events collaborate to perform a particular business use case.

While a Business Use Case describes what steps must be performed in order to deliver value to a business actor, 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 is structured and 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 Realizations to understand how a software system fits into the organization.

Container Artifact
RolesResponsible: Modified By:
Input ToMandatory: Optional:
  • None
  • None
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.  

Representation OptionsUML Representation: Collaboration, stereotyped as <<business use-case realization>>

In many cases, the focus of this work product is the activity diagram, in which you define what responsibilities belong to which business system or 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 work product 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, for example). 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 for each channel. Business Use-Case Realizations can be used to illustrate channel-specific realization of the business use case.

Recall that Business Use Cases are triggered either by Business Actors or by internal Business Events, through the invocation of one or more services provided by the business - invocation that occurs externally in the case of the Business Actor, and internally in the case of the Business Event. A service comprises one or more business operations (see Artifact: Business Operation), so that a Business Use-Case Realization is the overlay of all required business operation realizations (see Artifact: Business Operation Realization). This can be modeled as a large collaboration (the Business Use-Case Realization) which is built from smaller ones (the business operation realizations). Note though that the Business Use-Case Realization does not 'own' the business operation realizations - they may, and very likely will, show up in other Business Use-Case Realizations.

Note that there is no reason why you should not model some services provided by the business as private - they represent actions the business may ask of itself (when servicing a Business Event, for example) - but which are not available to a Business Actor.

More Information