Artifacts > Business Modeling Artifact Set > Business Use-Case Model... > Business Use-Case Model

Business Use-Case Model
The Business Use-Case Model is a model of the business intended functions. It is used as an essential input to identify roles and deliverables in the organization.
UML representation: Model, stereotyped as «business use-case model»
Role: Business-Process Analyst
Optionality: This model is developed if you need to clarify the business context of the system to be built. Otherwise, it can be excluded.
Sample Reports:
More information:

Input to Activities: Output from Activities:

Purpose To top of page

The following people use the Business Use-Case Model:

  • the customer to agree that you understand the business context before you continue develop the system
  • the software architect to identify architecturally significant behavior that should be automated
  • the system analysts to better understand the context of the system
  • the manager to plan and follow up on the business modeling effort and subsequent software development
  • people outside of the project, but within the organization, such as executives and steering committees, to obtain an insight into what has to be done

Properties To top of page

Property Name

Brief Description

UML Representation

Introduction A textual description that serves as a brief introduction to the model. Tagged value, of type "short text".
Survey Description A textual description that contains information not reflected by the rest of the Business Use-Case Model, including typical sequences in which the business use cases are employed by users and functionality not handled by the Business Use-Case Model. Tagged value, of type "formatted text".
Business Use-Case Packages The packages in the model, representing a hierarchy. Owned via the association "represents", or recursively via the aggregation "owns".
Business Use Cases The business use cases in the model, owned by the packages. Owned recursively via the aggregation "owns".
Business Actors The business actors in the model, owned by the packages. Owned recursively via the aggregation "owns".
Relationships The relationships in the model, owned by the packages. Owned recursively via the aggregation "owns".
Diagrams The diagrams in the model, owned by the packages. Owned recursively via the aggregation "owns".

Timing To top of page

The Business Use-Case Model is created during the Inception and early Elaboration phases.

Responsibility To top of page

A Business-Process Analyst is responsible for the integrity of the Business Use-Case Model, ensuring that:

  • the model, as a whole, is correct, consistent, and readable
  • it covers enough of the business to provide a good basis for building systems

Note that the business-process analyst is not responsible for the business use-case packages, business use cases, business actors, relationships, or the diagrams themselves; instead, these are under the corresponding business designer's responsibilities.

Tailoring To top of page

If the purpose of the business modeling effort is to reengineer the target organization, you should consider maintaining two variants of the Business Use-Case Model: one that shows the business actors and business use cases of the current target organization (sometimes called as-is), and one that shows the envisioned new business actors and business use cases (to-be). 

If you are considering a significant redesign of the way the target organization works (business reengineering), this separation is needed otherwise the redesign will be developed without knowing  what the proposed changes really are at the end, and you will not be able to estimate the costs of those changes. It is like an architect who is asked to draw up plans for changing a townhouse into three flats, without having an as-is blueprint from which to work.

The cost of maintaining two Business Use-Case Models is not insignificant, and you should carefully consider how much effort you put into an as-is model. Typically, you would not do more than identify and briefly describe the business use cases and business actors. You would also briefly outline the business use cases you determine are key to the effort, possibly illustrating this with a simple activity diagram. The level of detail you choose should aim at providing a shared understanding of the target organization. 

You would not need this separation if: 

  • there is no "new" organization (the goal is to document an existing organization)
  • there is no existing organization (business creation)

See also Guidelines: Target-Organization Assessment

Copyright  © 1987 - 2001 Rational Software Corporation

Display Rational Unified Process using frames

Rational Unified Process