Artifact: Business Use Case Model

	The Business Use Case Model is a model of the business goals and intended functions. It is used as an essential input to identify roles and deliverables in the organization.
Other Relationships:	Contains Business Actor Business Use Case rup_business_goal_bucm
Role:	No Responsible Role
Optionality/Occurrence:	Can be excluded. This model is developed if you need to understand or change the business processes, or rethink the way the business provides value to its customers.
Templates and Reports:	Template: Business Use-Case Specification Report: Business Actor Report - Report: Business Use Case Report: Business Use Case Model Survey
Examples:
UML Representation:	Model, stereotyped as <<business use-case model>>
More Information:	Guideline: Actor-Generalization in the Business Use-Case Model Checklist: Business Use Case Model Guideline: Business Use-Case Model Report: Business Use Case Model Survey Guideline: Communicate-Association in the Business Use-Case Model Guideline: Extend-Relationship in the Business Use-Case Model Guideline: Include-Relationship in the Business Use-Case Model Guideline: Use-Case Diagram in the Business Use-Case Model Guideline: Use-Case-Generalization in the Business Use-Case Model

Purpose Properties Timing Responsibility Tailoring

Input to Activities:

Output from Activities:

Purpose

The Business Use Case Model describes the direction and intent of the business. Direction is provided in the form of business goals, which are derived from business strategy, while intent is expressed as the added value and means of interaction with the stakeholders of the business.

The Business Use Case Model is used by stakeholders, business-process analysts and business designers to understand and improve the way the business interacts with its environment, and by systems analysts and software architects to provide context for software development. The project manager uses the Business Use Case Model to plan the content of iterations during business modeling and track progress.

Properties

Timing

The Business Use Case Model is outlined and partly detailed during the Inception phase and fully detailed and adjusted during the Elaboration phase.

Responsibility

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

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 organization (sometimes called "as-is"), and one that shows the target organization with 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 a current 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. 

Rational Unified Process