Why Business Events and Business Use Cases Are a Good Idea

We may seem to be going to a lot of trouble to describe something that may, at first glance, seem fairly obvious. But this care with the subject is certainly warranted: Our experience has amply demonstrated the value of having an objective way of partitioning the work, and the value of understanding the work itself, before plunging into the solution. The result is that we discover the real requirements, and we discover them more quickly.

By looking not at the inside, but from the outside, we get a far clearer idea of the most functional way of partitioning the work.

You can partition your work in a nonsubjective way by identifying responses to outside stimuli. After all, that is how your customers see your business. The internal partitions, whatever they may be, hold no interest for outsiders. Similarly, the current partitioning of any system is based on technological and political decisions taken at the time the system was built. Those decisions may no longer be validat the very least, you should question them and avoid perpetuating them just because they are there. By looking not at the inside, but from the outside, we get a far clearer idea of the most functional way of partitioning the work.

A business event points out which things belong together, and as a result, delivers cohesive partitions with minimal interfaces between the pieces. This partitioning, in turn, leads to chunks of work that act as vehicles for the detailed requirements investigation. The fewer the dependencies that exist between the pieces, the more the analysts can investigate the details about one piece without needing to know anything about the others.

The product-centric way of looking at the problem means that you miss opportunities for improving your product by branching into other parts of the work. It also discourages the analyst from asking, "But why is this like it is?" This failure, in turn, leads to "technological fossils" being carried from one generation of a product to the next.

But perhaps the overriding reason for using business use cases is to further the investigation of what is happening at the time of the business event. In many of the texts available today, the existence of a "system" is assumed. That is, the author assumes the boundary of the automated system and begins the use case investigation by looking at the actor and the interaction with the automated system, completely ignoring the work surrounding this interaction.

To do so is dangerous and wrong. This product-centric way of looking at the problem means that you miss seeing opportunities for improving your product by branching into other parts of the work. It also discourages analysts from asking, "But why is this like it is?" This failure, in turn, leads to "technological fossils" being carried from one generation of a product to the next.

Consider this example: "An insurance clerk receives a claim from a policy holder and then enters the claim into the automated system." This view encourages the requirements analyst to study the work of the clerk entering the details of the claim. However, if you spend a few moments looking at the real business being done here, you will see that the claim is simply the insurance company's implementationit is the accident that initiates this piece of business. Why is this understanding important? If you start your business investigation at the real origin of the problem, you build a better product. For example, perhaps it would be feasible to build a product that processes the claim in real time at the scene of the accident. Think of the originator of the business event. In this case, it is the driver or owner of the vehicle. What are his aspirations or goals here? He wants to have the vehicle repaired as quickly and effortlessly as possible. His goal is not to fill in claim forms and wait for them to be approved.

The requirements analyst must look past the obvious, which means understanding the true nature of the work.

Another example: "A caller contacts the help desk. The help desk person initiates the use case by asking the caller for details of the problem and logging the call." The use case is the logging, and the actor is the help desk person. Again, this product-centric view misses the real business eventthe happening that started it all. In this case it is the initiation of the call to the help desk. Why is viewing this way important? If you think of making the call as the business event, the correct response is to log the call, use caller ID to identify the caller's equipment, retrieve information on the equipment, and provide it for the help desk person. You might also decide that the real business event is the malfunctioning of the caller's equipment. If you think of it this way, you also think of the equipment making the call for help itself. Or perhaps a better understanding of the reasons underlying the malfunction might result in your new product giving the help desk operator historical information that will facilitate him in answering the call. People often don't ask for these sorts of requirements because they are thinking only of the supposed product. It is the duty of the requirements analyst to look beyond that, which means understanding the intentions of the adjacent system when it initiates the business event.

A security system this time: "The actor receives the shipment and logs it in." Nope. The real business event is the dispatch of the shipment. The business use case should log the shipment from its inception and monitor its transit and arrival.

If you become too immersed in the current technology and the way the business works at the moment, it is sometimes harder to see the business events. To overcome this difficulty, we suggest an informal process for discovering them.