Explanation

A business use-case model describes a business in terms of business actors and business use cases, corresponding, for example, to customers and business processes. The business use-case model includes workflow descriptions that identify what is done. How the work is performed in each business use case is described in the business analysis model, and, in particular, in business use-case realizations.

The set of business systems and business workers which perform the work of a business use case, together with the business entities they access and manipulate as part of the process, and a description of the interaction, is called the business use-case realization. Instances of the same class (of business system, business worker or business entity) can participate in several different business use-case realizations, reflecting that the same kind of resource from time to time participates in different processes.

The business systems form a containment hierarchy for the business workers and business entities (and conceivably other business systems), so you might expect that interactions by business systems would only occur only with other business systems. In fact you are not prohibited from showing interactions between business systems and business workers, for example, when you want to drill down inside a particular business system and expose its business workers and their interactions with each other and external business systems, when realizing a business use case. However, if you decide that a business system should present a well-defined boundary and interfaces in the business, you would not expose its contents in this way when realizing a business use case. Rather, you would derive subordinate business use cases for that business system (see Concept: Modeling Large Organizations) and describe, at a subordinate level, how these are realized by collaborations of the internal resources of the business system.

Using Activity Diagrams

The first choice to document the realization of a business use case is to draw an activity diagram, where swimlanes (or partitions) represent the participating business systems or business workers. For each business use-case realization, there may be one or more activity diagrams to illustrate the workflow. A common way to organize is to have one overview diagram without swimlanes that cover the whole workflow, and where you show activities that are at a high level. Then, for each such activity there is a more detailed activity diagram that shows the swimlanes and the tasks at the business worker level. For readability reasons, a goal should be that each diagram fit on a page.

See also Technique: Activity Diagram in the Business Analysis Model.

Using Communication and Sequence Diagrams

For each business use-case realization there can be one or more interaction diagrams depicting its participating business systems, business workers and business entities, and their interactions. There are two types of interaction diagrams: Sequence diagrams and communication diagrams. They express similar information, but show it in different ways:

• Sequence diagrams (as their name implies) show an explicit sequence of events and are better than activity diagrams for more complex scenarios.
• Communication diagrams show the communication links and messages between objects and are better for understanding all of the effects on a given object.
• If alternative flows are few, but there are many business entities involved, interaction diagrams are often a better choice than the activity diagram to show the realization of the workflow.

See Technique: Sequence Diagram in the Business Analysis Model and Technique: Communication Diagram in the Business Analysis Model for more information.

Using Class Diagrams

For each business use-case realization there may be one or more component diagrams or class diagrams depicting its participating business systems, business workers and business entities. A diagram of this kind can be a useful help when coordinating all the requirements on a business system, business worker or business entity that participates in several business use-case realizations. See Technique: Class Diagram in the Business Analysis Model.

How to Map Use-Case Relationships

Relationships between business use cases correspond to relationships in the business analysis model. By studying what happens in the business, you can understand how to map the business use-case relationships to links between objects of the business use-case realizations. For more on use-case relationships, see Guideline: Business Use-Case Model.

Suppose a business use case (base) includes another business use case (inclusion). At a given moment, the employees will need to cease following the instructions of the base and switch to following the instructions of the inclusion as described in the documentation of the respective business use-case realizations. The following happens:

• An identifiable state is reached in the execution of a process according to the base use case-a business worker has finished a certain task for example.
• A change in state is noticed by someone who is ready to start working according to the realization of the inclusion. Either the person sees some phenomenon, or is informed by someone in the inclusion.

A business worker in the realization of the base interacts with the business workers in the realization of the inclusion to inform them of what is going on. The most natural modeling approach is:

• A realization of the inclusion has one object for each base it is included by. The objects originating from the base each have a link to the business worker individual that starts the work in the inclusion.

Each business worker in the realization of the base business use cases needs a link to the business worker that starts the work according the inclusion business use case.

• A realization of the base business use case does not have objects representing the inclusion.

In the case of a business use case being extended by an another business use case, you will end up with a similar solution. In the realization of the extension, you will have one object representing the base, that has a link to an object initiating the work described within the extension.

Each business worker in the base business use cases needs a link to the business worker that starts the extension.

For use-case-generalization, the solution is again similar. In the realization of the parent use case, you will see an object representing the child.

There are business workers representing the child use cases in the realization of the parent.

The use-case relationships have different interpretations. When it comes to their representations in the business analysis model, the difference is found in why the work defined in the inclusion, the extension or the parent business use case is initiated and how the business worker interprets the information. How the objects in the business use-case realizations interact follow the same structure in all cases.

Characteristics of Good Business Use-Case Realizations

• The participating business systems, business workers and business entities perform the business use-case workflow, including all alternative and optional subflows.
• Workflow description covers all the tasks described.
• The business systems, business workers and business entities have all the relationships needed to perform the business use-case workflow.
• At least one business system or business worker handling the interaction between the business actors and the business.