• To understand the structure and dynamics of the organization.

• To ensure that customers, end users and developers have a common understanding of the organization.

• To derive requirements on systems to support the organization.

To achieve these goals, a business use-case model and a business object model are developed. Complementary to these models, the following artifacts are developed:

• Supplementary Business Specification
• Glossary

Artifacts

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.

Supplementary Business Specification

A document present any necessary definitions of the business not included in the business use-case model or the business objects model.

Business Object Model

The business object model is an object model describing the realization of business use cases.

• The Requirements workflow uses business models as an important input to understanding requirements on the system.

• The Analysis & Design workflow uses business entities as an input to identifying entity classes in the design model.

• The Environment workflow develops and maintains the supporting artifacts, such as the Use-Case-Modeling Guidelines, that are used during use-case modeling.

• Concepts

The approach to business modeling represents a concise and straightforward way to generate requirements on supporting information systems. A good understanding of business processes is important to be able to build the right systems. Even more value is added if you also use people's roles and responsibilities, as well as definitions of what "things" are handled by the business as a basis for building the system. It is from this more internal view of the business (captured in a business object model) that you can see the tightest link to what the models of the system should look like.

The business models would give input to the use-case view, and the logical view as presented in the analysis model. You would also be able to find essential mechanism at the analysis level (analysis mechanisms).

The following should be considered:

• For each business use case that is to be supported by the system, identify a subsystem in the analysis model. This subsystem is in the application layer and is to be considered a first prototype iteration. For example, if you have an Order process and a Billing process in your business use-case model, you would identify an Order subsystem and a Billing subsystem in the application layer of your analysis model. However, you may argue, to me Order and Billing are separate systems. Well, that is a matter of scope. If you were considering all your information-system support as one system with several applications that share architecture, Order and Billing would be application subsystems. If your scope is to build an Order Management application only, then Order Management would be your system, and the recommendation above would not make sense. Therefore, the recommendation given above only makes sense if your scope is such that you consider all information-system support in the organization as one system.

• For each business worker that is to be supported by the system, identify use cases that represent what is to be automated.

• For each business entity that is to be supported by the system, identify entity classes in the analysis model. Some of these are candidates of being considered essential mechanisms ("component entities") in the system.

• For "clusters" of business entities (a group of business entities that are used solely within one business use case, or a group of otherwise closely related business entities), create a subsystem in the business specific layer.

You perform business modeling to help find requirements on one specific application, to be built from scratch. There are other applications supporting the business that we need to be aware of (legacy systems). Decisions need to be made on whether the new application should replace some functionality in the old legacy systems, or whether it should complement the legacy systems.

• You perform business modeling to help find requirements for improving an already existing application.

• You perform business modeling to help find requirements on information systems in a completely new line of business. The goal of the work is not necessarily to build new applications, but to determine if existing applications in other lines of business can be used (with or without modifications) in the new line of business.

What all these "typical situations" have in common is that the goal is to define a subset of the requirements on automation, not all requirements. This means that before you can define which business workers become system actors to the application you are building, you need to identify what situation you are trying to resolve, and also obtain information on any already existing applications that will co-exist with the one you are building.

Scope of Business Modeling

A business-modeling effort can have different scopes depending on context and need. Some examples are listed below:

• You may want to build a simple map of the organization and its processes so that you get a better understanding of what the requirements are on the application you are building. In this case, business modeling is a part of the software-engineering project, primarily performed during the inception phase.

• If you are building applications with the primary purpose of managing and presenting information (such as an order management system or a banking system), you may choose to build a model of that information at a business level, without considering the workflows of the business. This is referred to as domain modeling.
• Domain modeling is typically part of the software-engineering project, and performed during the inception and elaboration phases of the project.

• If you are building a "large" system, or a family of applications, you may have one business-modeling effort that will serve as input to several software-engineering projects. The business models will help you find functional requirements, as well as serve as input to building the architecture of the application family. The business-modeling effort is, in this case, often treated as a project on its own.

• If you are building an application that will be used by several organizations (for example, a sales support application or a billing application), it can be useful to go through a business-modeling effort to align the organizations in how they do their business to avoid requirements that are too complex for the system. Or, if aligning the organizations is not an option, a business-modeling effort can help you understand and manage differences in how the organizations will use the application, and make it easier to determine which application functionality should be prioritized.

• If an organization has decided to start a completely new line of business, and build information systems to support it, a business-modeling effort needs to be performed. In this case, the purpose of business modeling is not only to find requirements on systems, but also to determine the feasibility of the new line of business. The business-modeling effort is, in this case, often treated as a project on its own.

• If an organization has decided to completely revamp their way of doing business (business-process reengineering), business modeling is often one or several projects in its own right. Business-process reengineering is typically done in several stages: envision the new business, reverse-engineer the existing business, forward-engineer the new business, and install the new business.