For each role (human or system) in the organization, identify a business worker and give it a brief description. Employment positions are a good place to start, but be aware that a person in a specific position is usually required to fulfill more than one role and that various roles are often filled by people in different positions. You can also look at the software systems currently being used. However, you must be aware that-like people-many software systems perform multiple roles within the organization. This integration of sometimes completely different roles is one of the factors that makes software maintenance so difficult and locks a business in to a system.

After you have identified your business workers, walk through each business use case and state which business workers are involved in which steps. This ensures that no business workers have been missed and that the ones that you have listed are all "inside" the part of the business you are modeling.

For more information on business workers, see Guideline: Business Worker.

To find candidate business entities, consider what information each business worker handles. The information that must be queried, validated, created, or communicated is a good starting point. Only significant, persistent information should be considered as a business entity.

To show how business entities need to "know about" one another, use associations (see Guideline: Association in the Business Analysis Model). Give the associations role names for clarification.

If business entities have clear whole-part relationships, show that fact with aggregation-relationships (see Guideline: Aggregation in the Business Analysis Model).

If business entities are specializations or generalizations of one another, use generalization-relationships to show this (see Guideline: Generalization in the Business Analysis Model). It is often wise to wait to establish generalizations until after you have worked on describing the business entities (see Task: Detail a Business Entity).

Document the relationships in class diagrams (see Guideline: Diagrams in the Business Analysis Model - Class Diagrams section).

Walk through the workflow of each business use case to ensure that no business entities have been forgotten. Also, make sure that the ones you have identified are actually participating in a workflow.

For more information on business entities, see Guideline: Business Entity.

Inspect the interactions between business actors, business workers, and business entities. Business actors may initiate a business use case by sending a business event. Business workers may send business events to business actors or to each other. If a message between two business workers has one of the following characteristics, it might be a business event:

• The sender of the message does not need to wait for the receiver to process the message.
• There is a significant lapse of time between when the message is sent and when it is received.
• There is a significant physical distance between sender and receiver.
• The receiver is in another business system. In this case, the business event must be sent to the business system and not directly to the business worker within it. 

Business events may also be used to send signals between business systems and business use cases.

For more information on business events, see Guideline: Business Event.

For each business use case, create a Business Use-Case Realization in the Business Analysis Model. The name of the Business Use-case Realization must be the same as the associated business use case. Furthermore, a realization-relationship should be established from the business use case realization to its associated business use case.

Identify which business workers and business entities participate in the execution of each business use case. They form the business use-case realization of the business use case.

Present the business workers and business entities of the business use-case realization in a sequence diagram (see Guideline: Diagrams in the Business Analysis Model - Sequence Diagrams section). Show only those interactions that are necessary an understanding of how the business workers and entities perform this business use-case realization workflow. There should be at least one interaction (sequence diagram) for every flow described in the business use case.

Instead of using a sequence diagram, you can present the participating business workers and business entities in a communication diagram (see Guideline: Diagrams in the Business Analysis Model). Sequence diagrams are superior for large and complex interactions, while communication diagrams provide a better overview of relationships between participants.

To clarify the meaning of the communication diagrams, you can describe the workflow of each business use-case realization in terms of its elements-the interacting business workers handling business entities. This is optional, and it only adds value for more complex workflows or parts of workflows. To perform this task:

• Describe the normal workflow of the business use-case realization.
• Describe any alternative and optional workflows.
• Define performance goals in terms of cost and lead times for business workers and business entities.

For more information on business use-case realizations, see Guideline: Business Use-Case Realization.

Analyze the lifecycle of each business entity. Each one should be created and removed by someone during the life of a business. Make sure that each business entity is accessed and used by a business worker or another business entity. Do this by creating a matrix or generating a report showing which business workers create and use the business entities.

Reduce the number of workers. As you develop your models, it is likely that you will find one or more too many workers per use-case realization. Make sure that each business worker corresponds to a set of tasks that one person typically would do, even though those tasks are divided among more than one business use case. You can do this by deriving and examining the responsibilities required of the business worker from all business use-case realizations in which the business worker participates.

Each business entity should have an owner-that is, someone who is responsible for it. You can model this with an association from the business worker to the business entities for which the business worker is responsible. Some business entities might be owned by people outside the business. If that is the case, make sure that it is mentioned in the brief description of the business entity.

For very large or complex business models, you can use Work Product: Business System for structuring and partitioning. In this case, you can assign business workers, business entities, and business events to a business system. Make sure that the relationships and responsibilities defined by the business systems support the interactions between the business workers, entities, and events. If necessary, the business systems must be slightly adjusted (in consultation with the business process analyst), or the interactions must be refined.

For guidelines on structuring the Business Analysis Model and naming business workers and business entities, see Checklist: Business Analysis Model.

Evaluate the business use-case realization workflow, along with the text and diagrams documenting it. One way to do this is to conduct a walkthrough. In this method of evaluation, the person responsible for the business use-case realization leads some of the members of the team through the business use-case realization workflow. Another technique is to do Guideline: Role Playing, in which team members act as business actors, business workers, and business entities.

See also checklists for Business Analysis Model and Business Use-Case Realizations in Task: Review the Business Analysis Model.