Guidelines: Business Analysis Model

Topics

• Explanation
• Naming Conventions
• Business Objects in Relation to Business Use Cases
• The Business Analysis Model and Information Systems
• Information Systems as Business Actors
• Information Systems Explicitly in the Business Analysis Model
• Characteristics of a Good Business Analysis Model

Explanation

A Business Analysis Model defines the business use cases from the business workers' internal viewpoint. The model defines how people who work in the business, as well as the things they handle and use ("the classes and objects of the business") must relate to one another, both statically and dynamically, to produce the expected results. It places emphasis on roles performed in the business area and their active responsibilities. Together, the objects of the model's classes should be capable of performing all business use cases. 

The key elements of the Business Analysis Model are:

• Business Systems partition large business models into interdependent areas of responsibilities.
• Business Workers show the set of responsibilities a person may carry. 
• Business Entities represent deliverables, resources, and events that are used or produced.  
• Business Events represent important occurrences in the daily operation of the business.  
• Business Use-Case Realizations show how business workers, business entities, and business events collaborate to perform a workflow. The Business Use-Case Realizations are documented with:

• Class diagrams that show participating business workers and business entities.
• Activity diagrams in which swimlanes show responsibilities of 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 workers, 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 similar to how software developers think, 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 system 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 referral to the purpose of the Business System (such as Customer Management or Target Acquisition). See Guidelines: 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 Guidelines: 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 Guidelines: 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 Guidelines: 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" 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 employees will act, whereas Business Entities represent those things that the employees will handle. Using a Business Analysis Model, you define how the employees of the business need to interact to produce the desired results for the business actor. The System Use-Case Model and Design Model, on the other hand, specify the business' information systems.

Business modeling and software modeling address two different problem areas at two different abstraction levels. Therefore, the general rule is that the information systems must have no direct presence in the business models.

On the other hand, the employees acting as business workers use information systems to communicate with each other, and with the actors, and to access information about business entities. Whenever there is a link, association, or attribute, there is also some potential information-system support.

These two modeling contexts have the following relationships:

• 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 employees work with-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.
• Finally, a business actor that directly uses a business' information system also becomes a system actor of the information system.

These relations are essential when identifying requirements of the information systems that support the business. 

See the section on automated business workers in Guidelines: 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 the other business' information system. 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

The general rule is that information systems should not be explicitly modeled in the Business Analysis Model; they are merely tools in the hands of the business workers. We have one exception to this rule, which concerns information systems for businesses that are directly used by their customers. If this interaction forms a major part of the business services, it might be so commercially important that you might want to show it in the Business Analysis Model. Telephone banking services are good examples of this type of information system.

From the business-modeling perspective, the following approach is suggested:

• 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 an 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

This content developed or partially developed by Empulsys BV.

Rational Unified Process