Explanation

A Business Analysis Model defines the realization of the business use cases, from the internal viewpoint of the business systems and business workers. The model defines how people and systems working in the business, and the things they handle and use (business entities), must relate to one another, both statically and dynamically, to produce the desired results. It places emphasis on roles performed in the business areas, and their active responsibilities. The model will show all collaborations needed to realize all business use cases, and all classes from which objects will be instantiated to bind (fulfill) those roles.

The key elements of the Business Analysis Model are:

• Business Systems partition large business models into interdependent areas of responsibilities. Business Systems encapsulate their resources, and provide services through well-defined interfaces, to other parts of the business.
• Business Workers are the active units of a business - in the Business Analysis Model they represent an abstraction of a human or software, or even a system containing humans, hardware and software (which, unlike a business system, will not be further decomposed within the Business Analysis or Business Design Models). Their responsibilities are defined in the Business Analysis Model. 
• Business Entities represent deliverables, resources, and significant pieces of information that are used or produced.  
• Business Events represent important occurrences in the daily operation of the business that potentially trigger other business processes.
• Business Rules, declarations of policies or conditions that must be satisfied during the execution of business processes.
• Business Use-Case Realizations show how business systems, business workers, business entities, and business events collaborate to perform a business use case. The Business Use-Case Realizations are documented with:

• Class diagrams that show participating business systems, business workers and business entities.
• Activity diagrams in which swimlanes show responsibilities of business systems or business workers, and object flows show how business entities are used in the workflow. 
• Sequence diagrams that depict the details of the interaction among business systems, business workers and business actors, and how business entities are accessed, during the performance of a business use case. 

The Business Analysis Model brings the notions of structure and behavior together. Business Use-Case Realizations map the descriptions of process (Business Use Cases), which specify desired behavior, to structural elements within the organization (see the figure that appears after the bullets).

The following are some characteristics of the Business Analysis Model:

• It is a bridging artifact that articulates business concerns in a way that is familiar to software developers, while still retaining a purely business content. It is a consolidation of what we know about the area of business concern expressed in terms of objects, attributes, and responsibilities. 
• It explores the essence of business area knowledge in a way that provides a transition from thinking about business issues to thinking about software applications. 
• It is a way of firming up requirements to be enabled or supported by information systems that will be built. 
• The process of agreeing to business object definitions, relationships between objects, and the names for the objects and relationships between objects, permits business area knowledge to be represented in a precise manner that can be understood and validated by business-area experts.

Naming Conventions

In general, Business Systems, Business Workers, Business Entities, and Business Events should have short, descriptive names that are unique and are not similar to other names. Sometimes it may be necessary to use more than one word to describe the purpose of the model element and ensure that it is unique and recognizable, especially when considering a broader context (which may become important in the future).

A Business System provides a collection of related responsibilities with a specific purpose, and should be named in a way that reflects this purpose. It may be tempting to use generic names or catch phrases for names (such as Client Services), but make sure that the term is really applicable and descriptive. Generally, a gerund form of a verb is useful (such as Shipping, Invoicing, or Selling) as is a reference to the purpose of the Business System (such as Customer Management or Target Acquisition). See Guideline: Business System for more information.

Business Workers should be named in a way that expresses their responsibilities. Do not describe the function (in case of a human business worker), but the role played by the business worker in the use-case realization. This role is reflected by the purpose with which the business worker is involved in the business use-case realization. See Guideline: Business Worker for more information.

For example, imagine a process in which data is typed into a system by one business worker and held until a second business worker has verified or approved the data before processing (such as in loan applications at a bank). The business worker who inputs the data could be named Data Typist or Data Entry Clerk, whereas the second business worker could be named Verifier, Authorizer, or Releaser. Data Entry Clerk has the disadvantage of sounding human, while the last three may have to be further qualified at some stage (for example, Mortgage Authorizer if the bank is also going to start brokering insurance policies).

Business Entities should be named in a way that reflects the information they represent. Business entities must always be defined in the Business Glossary, since there is usually much difference of opinion regarding definitions and relationships. Do not include the state or properties of the Business Entity in its name. Business Entity names should be singular, not plural. See Guideline: Business Entity for more information.

Business Events should be named in a way that indicates the occurrence or state changed that it represents. Do not describe the trigger of the event or the reaction to the event in the name. The specification of the event is independent of its triggers. See Guideline: Business Event for more information.

Business Objects in Relation to Business Use Cases

As you study the business workers and business entities that participate in your business' different use cases, you may find several that are so similar that they are really one class. Even when different business use cases do not have identical demands, the classes may be similar enough to be considered one and the same phenomenon. If this is the case, merge the similar classes into one. This results in a business worker or business entity that has sufficient relationships, attributes, and operations to meet all the demands of the different business use cases. The diagram at the end of the section titled "Explanation" (above) shows how business workers and business entities participate in different business use-case realizations.

Several business use cases may, therefore, have quite different demands on one and the same class. In the case of business workers, if you have employees capable of acting in the described set of roles, you will also have flexible employees who can work in several positions. This gives you a more flexible business.

The Business Analysis Model and Information Systems

In the Business Analysis Model, Business Workers represent the roles that the active units of the business will play, whereas Business Entities represent those things that the active units will handle. Using a Business Analysis Model, you define how the Business Workers (and at a higher level, the Business Systems) need to interact to produce the desired results for the business actor. We said above that a Business Worker may represent an abstraction of a software system; when you move out of the business modeling context, you will use a System Use-Case Model and Design Model to specify that software system.

Business modeling and software modeling address different problem domains at two different abstraction levels. Therefore, as a general rule you should respect this difference, and not allow software modeling details to intrude into the business models, but focus on the business purpose of the Business Workers. 

When you examine the interactions and characteristics of business workers in the 'as-is' model (particularly those roles played by human workers), the occurrence and consumption of business events, and the operations performed on business entities, certain relationship heuristics between the business modeling and the system modeling contexts may be useful, as you look for automation opportunities. Links, associations and attributes in the business model may suggest possible automation:

• An employee acting as a certain business worker corresponds to a system actor of the information system. He or she is probably best supported if the information systems are structured so that his or her entire work in a business use case is supported by one system use case.
• Alternatively, if the business use case is large, long-lived, or combines work from several independent areas, an information-system use case can support one operation of the business worker instead.
• The things the business workers manipulate - modeled as business entities - often have representations in the information systems. In the object model of an information system, these business entities occur as entity classes.
• Business events are often implemented as messages in service-oriented architecture software systems or as tasks in workflow automation systems.
• Associations and aggregations between business entities often give rise to corresponding association and aggregations between entity classes in the Design Model.
• Therefore, an information system use case accesses and manipulates entity classes in the design model that represent the business entities accessed by the supported business use case.
• A business actor that directly uses a business information system also becomes a system actor of the information system in the system modeling context.

These relationships are useful when identifying requirements for the information systems to support the business. 

See the section on automated business workers in Guideline: Going from Business Models to Systems. 

Information Systems as Business Actors

Sometimes the employees of one business contact the employees of another business through the use of an information system in the first business. From the perspective of the modeled business, that information system is a business actor.

Example:

A software developer tries to understand a problem in the product for which he is responsible. To understand if the problem originates from the programming tool he is using, he contacts the supplier's World Wide Web server and studies the list of known problems in the current release of the programming tool. In this way, the business worker Software Developer interacts with the business actor Supplier WWW Server.

Information Systems Explicitly in the Business Analysis Model

As you model manipulations of business entities by business workers, it is evident that many of the operations on the business entities would be performed with the assistance of some tool - perhaps computer-based. Whether you choose to model this explicitly as an information or other system (and therefore represent it by a business worker) depends on its significance in the business. For example, you would probably not model a simple desktop system that has word processing and spreadsheet capabilities as a business worker in its own right. On the other hand, when you encounter an information system in a business that is directly used by customers, and this interaction forms a major part of the business services, it might be so commercially important that you want to show it in the Business Analysis Model. Telephone banking services are good examples of this type of information system.

In this case you could proceed as follows:

• Regard the information system as a fully automated business worker that interacts with an actor.
• If the information system relates to any of the other business workers or business entities, consider illustrating this relationship with a link or an association. Perhaps the system informs a business worker of its progress or uses information concerning a business entity.
• Briefly describe the business worker, as well as a list of services that represents the information system in the Business Analysis Model.
• Model all details and characteristics of the information system and its environment in a subordinate Information System Model.
• Introduce a naming convention so that a fully automated business worker is easily identified among the business workers; for example, a prefix or a suffix, like "automated <business worker name>" or "system: <business worker name>". You may even define a stereotype with a particular icon.

Characteristics of a Good Business Analysis Model

Taken together, the business systems, business workers, business entities, and business events perform all tasks described in the business use cases - no more and no less. The Business Analysis Model gives a good, comprehensive picture of the organization at an appropriate level of abstraction.

Transition to Business Design Model

The Business Design Model is the evolution of the Business Analysis Model with choices (and associated rationale) for the realization, and perhaps refactoring, of Business Workers in humans, software or systems (themselves composed of some or all of humans, software and hardware). The Business Design Model does not decompose these further - that is the task of subsequent system or software development efforts.