Modeling a business process as a system use case.
Keywords: Business process, large use case, level of abstraction, long use case, multiple initiating actors, pause in use case.
In some cases, business use cases might be hidden in a system use-case model without making their presence noticeable in diagrams; it is only in the description of these use cases the mistake can be detected. However, the name of such a use case typically starts with Handle, Manage, or Perform, followed by the name of a concept in the business domain. Furthermore, it is not uncommon that more than one actor is involved in use cases of this kind. Obviously, these are both very weak indications since both situations may well occur in a correct model.
To verify that this modeling mistake has not been made in a model, it is necessary to check the descriptions of suspected use cases. When a use case consists of two or more parts that are disconnected in the sense that they are performed at different points in time, it describes how the business acts and not how the system is used; therefore, it should be split.
Use cases are normally used for modeling how a system is used. However, the same technique is applicable when modeling how an organization is used by its environment. In this case, the use cases will model different processes starting from someone outside the organization, such as a customer, and model what actions are performed inside the organization as a response to the interaction from the entity outside the organization. We call the use cases modeling an organization rather than a software system business use cases. Fragments of the business use cases can be realized by the software systems supporting the organization; that is, they can be traced to traditional system use cases.
When a business flow should be more or less completely implemented in a supporting software system, it is sometimes not obvious whether the flow should be represented by a single use case in the system's use-case model or if it should be split into several use cases.
An example of a business use case that will be supported to a high degree by a software system is Manage Order in a warehouse business. The flow comprises among other things the registration of an order, the generation of a pick-list for the assembly of the shipment, the generation of an invoice when the order has been shipped, and finally the registration of the payment from the customer. It should also comprise the possibility to change or to delete a registered order.
Why not capture this as a single use case in the system use-case model? The problem is that this use case does not model one usage of the software; it models one usage of the business. The flow consists of several subflows that will be performed at different points in time, at irregular time intervals, and possibly initiated by different persons. Furthermore, each of these subflows provides a value to someone inside the warehouse. Hence, every subflow constitutes a use case in the software; that is, they are complete usages of the software. If we change focus and study the entire warehouse, however, none of them constitutes a use case on its own; they are only fragments in the usage of the warehouse business. The key here is the subject of the model: Is it the software system or is it the business?
One problem of including business use cases in the use-case model of the software system is that their purposes and stakeholders are different from those of the system. Furthermore, business use cases are normally described at a higher level of abstraction. If they were to be described at a suitable level for a model of a software system, they would become very long and complex.
In general, if a use case requires an actor to do something at some point during its performance, such as provide additional input or to acknowledge the reception of information, this implies an interrupt in the execution of the use case. If the required input is most likely to arrive at a significant later moment in time, it is no longer a continuation of the current use case. We are not even sure that this input will ever happen. Therefore, we say that the use case will end here and another use case will be initiated when the input arrives.
In situations where the input from the actor is expected to normally arrive more or less immediately, such as a confirmation from another system to which our use case sends information, it is usually best to model the complete flow in one use case. The situation where the input does not arrive as expected can then be handled in an alternative flow by introducing a timeout interrupt.
Note that it is possible for a business use case to be a suitable use case in the system use-case model as well, so a one-to-one mapping from the business model to the system model is not wrong per se. Again, the key is to keep in mind what the subject of the model is—it models a supporting software and not the business.
A somewhat related situation is when the performance of a use case includes a scheduled pause. A typical example is the telephone exchange system supporting a hotel, where one important service to the customers is to offer automatic wake-up calls. From the business perspective, the complete flow starts when a customer requests a wake-up call at some future point in time and ends when the wake-up call has been performed the next morning.
It is tempting to model this flow as one use case, but this is not the best way to do it. First, there is a long period of time during this process when nothing happens, and it is generally considered bad practice to model use cases whose execution largely consists of doing nothing. Second, it may be the case that the wake-up call is never performed at all (for example, if the customer cancels the request or decides to check out before the wake-up time). In this case, the use case has been waiting for a long time for nothing (see also Chapter 28, “Future Task”).
When a business use case, which is not also a suitable system use case, is detected in the use-case model, the model is corrected by splitting the use case. For each separate task in the original use case to be performed in the system at hand and with a specific business value, a new use case should be defined. The corresponding part of the original use case's flow is extracted into the new use case, where it probably will be described more thoroughly. Like this, the original use case should eventually be empty; that is, it will not contain any system behavior not captured by the new use cases, and it can be removed from the model.
One criterion on when to introduce a new use case is when there is an actor sending an input to the system without being requested by the system to do so. In such a case, there is no ongoing usage of the system waiting for an input from the actor. Therefore, a new use case should be initiated.
Another criterion is that each situation in the flow where there will be a major delay (for example, because of the necessity to wait for input that will be supplied at another occasion), a new use case should be prepared having that actor as the initiator and comprising what happens as a result of the input.
Because the original use case was actually a business use case, it was probably described in less detail than software use cases need to be. This implies that after copying the relevant part of the original use-case description into each new use case, more detail must probably be added to the description.
The fact that the use cases have to be performed in a certain order, as required by the business flow, can be captured by defining preconditions in each of the new use cases (except of course the first one in the sequence; see Chapter 26, “Use-Case Sequence”).
The same solution is applicable to use cases with a more or less lengthy pause in their execution (see Chapter 28).