Artifact:  Business Use-Case Model

Business Use-Case Model	The business use-case model is a model of the business intended functions. The business use-case model 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:	Business Use-Case Model Survey
More information:	Guidelines:Business Use-Case Model Guidelines:Actor-Generalization in the Business Use-Case Model Guidelines:Communicate-Association in the Business Use-Case Model Guidelines:Extend-Relationship in the Business Use-Case Model Guidelines:Include-Relationship in the Business Use-Case Model Guidelines:Use-Case-Generalization in the Business Use-Case Model Guidelines:Use-Case Diagram in the Business Use-Case Model Checkpoints:Business Use-Case Model
Purpose Properties Timing Responsibility Tailoring

Input to Activities: Detail a Business Use Case Find Business Workers and Entities Define Automation Requirements Review the Business Use-Case Model Define the Business Architecture Maintain Business Rules Capture a Common Vocabulary Develop Vision Find Actors and Use Cases Structure the Business Use-Case Model

Output from Activities: Find Business Actors and Use Cases Structure the Business Use-Case Model

Purpose

The following people use the business use-case model:

• The customer to approve that you understand the business context before you to continue to system development.
• 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 the business modeling effort and subsequent software development.
• People outside the project but within the organization, executives and steering committees, to obtain an insight into what has been done.

Properties

Timing

The business use-case model is created during inception and early elaboration.

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.
• That 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, and 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 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 in the end what the proposed changes really are, 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 town-house into three flats, without having an as-is blue-print to work from.

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 identifying and briefly describing the business use cases and business actors. You would also briefly outline the business use cases you determine are key to the effort, possibly illustrated 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

Rational Unified Process