Artifact: Business Analysis Model

	The Business Analysis Model describes the realization of business use cases by interacting business workers and business entities. It serves as an abstraction of how business workers and business entities need to be related and how they need to collaborate in order to perform the business use cases.
Other Relationships:	Contains rup_business_rule_bam Business Event Business Use-Case Realization Business Worker Business Entity Business System
Role:	Business-Process Analyst
Optionality/Occurrence:	Can be excluded. This model should be used when considering changes to the business processes or the organization (structure, roles and responsibilities).
Templates and Reports:	Template: Business Use-Case Realization Specification Report: Business Use-Case Realization Report: Business Worker Report: Business Entity Report: Business Analysis Model Survey
Examples:
UML Representation:	Model, stereotyped as <<business analysis>>.
More Information:	Guideline: Aggregation in the Business Analysis Model Guideline: Association in the Business Analysis Model Checklist: Business Analysis Model Guideline: Business Analysis Model Report: Business Analysis Model Survey Guideline: Diagrams in the Business Analysis Model Guideline: Generalization in the Business Analysis Model Guideline: Going from Business Models to Systems

Purpose Properties Timing Responsibility Tailoring

Input to Activities:  Capture a Common Vocabulary Define Automation Requirements Define the Business Architecture Detail a Business Entity Detail a Business Worker Develop Vision Find Actors and Use Cases Maintain Business Rules Review the Business Analysis Model

Output from Activities:  Find Business Workers and Entities

Purpose

The purpose of the Business Analysis Model is to describe how business use cases are performed. The Business Use-Case Model describes what happens between business actors and the business, and makes no assumptions about the structure of the business or how business use cases are realized. The Business Analysis Model on the other hand, defines the internal business workers and the information they use (the business entities), describes their structural organization into independent units (business systems), and defines how they interact to realize the behavior described in the business use cases.

The Business Analysis Model is used by stakeholders and business-process analysts to understand how the business currently works, and to analyze the effect of changes to the business. The business-process analyst is responsible for the structure and integrity of the model, while business designers are responsible for detailing elements within the model. The model is also used by systems analysts for deriving software requirements based on how the software system will be used as part of business processes. Software architects use the model to define a software architecture that fits the organization seamlessly and to identify classes in software analysis and design models.

Properties

Timing

A Business Analysis Model is created during Inception and finalized during the Elaboration phase.

Responsibility

A business-process analyst is responsible for the integrity of the Business Analysis Model, ensuring that it forms a complete and consistent whole. The business designers are responsible for detailing specific elements within the Business Analysis Model (Business Systems, Business Workers, Business Entities, and Business Use-Case Realizations).

Tailoring

The Business Analysis Model is a way of expressing the business processes in terms of responsibilities, deliverables, and collaborative behavior. When a new software system is to be developed or deployed, creating a Business Analysis Model is mandatory in order to assess the impact of the system on the way the business works. Organizational changes resulting from deploying new software are often overlooked and excluded from the Business Use Case, resulting in a working software system that cannot be used.

Failure to produce a Business Analysis Model means you run the risk that software developers will give only superficial attention to the way business is done. They will do what they know best, which is to design and create software in absence of business-process knowledge.  The result can be that the software systems that are built do not support the needs of the business. 

We have identified three main variants for tailoring the Business Analysis Model: 

• Build an "incomplete" Business Analysis Model, including only the domain entities.
• Build two versions of the Business Analysis Model, the current (as-is) and the target (to-be) model.
• Exclude the Business Analysis Model.

See also Guidelines: Target-Organization Assessment. 

Domain Modeling

You can choose to develop an "incomplete" Business Analysis Model, focusing on explaining "things" and products important to the business domain. Such a model does not include the responsibilities people will carry; it only describes the information content of the organization. This is often referred to as a domain model. In such a case, you would stereotype the model as <<domain model>> instead of <<business analysis>>. A domain model is very useful for providing a common basis with which concepts can be clarified and defined.

As-Is and To-Be Models

If the purpose of the business modeling effort is to do business (re-) engineering, you should consider building two variants of the Business Analysis Model: one that shows the current situation and one that shows the envisioned new processes (target situation). 

The current version of the Business Analysis Model is simply an inventory of the Business Use-Case Realizations. The elements of the Business Analysis Model are not described in any detail. Typically, brief descriptions are sufficient. The Business Use-case Realizations can be documented with simple activity diagrams, where swimlanes correspond to elements of the Business Analysis Model.  The target version of the Business Analysis Model requires most of the work. The current processes and structures need to be reconsidered and aligned with the business strategy and goals.

Exclude the Business Analysis Model

If the business analysis is well understood by all stakeholders and the project team, the benefits of developing a Business Analysis Model are significantly diminished. Where this occurs, the Business Analysis Model may be omitted entirely. However, it is usually a good idea to develop at least a minimal Business Analysis Model to improve understanding of the way the business works between stakeholders.

This content developed or partially developed by Empulsys BV.

Rational Unified Process