Business Use Cases

For every business event, there is a preplanned response to it, known as a business use case. The business use case is always a collection of identifiable processes, data that is retrieved and/or stored, output generated, messages sent, or some combination of these. In other words, the business use case is a unit of functionality. This unit is the basis for writing the functional and nonfunctional requirements (we will talk about these requirements in more detail in Chapters 7 and 8).

The business use case is the most convenient unit of work to study.

You can readily isolate the work of a business use case, because it has almost no connections to other business use cases. As a consequence, different analysts can investigate different parts of the work without the need for constant communication between them. In fact, the only overlap between business use cases is their stored data. The relative isolation of each business use case means you can identify one or more stakeholders who are expert in that part of the work, and they (with your help) can describe it precisely and in detail. They describe both the normal cases, where everything goes according to plan, and the exceptional cases, where almost nothing goes to plan. You can also observe the business use case. After all, business events are known to the stakeholders, and they can show you how the organization responds to any of them. For example, it would not be hard to find someone in your favorite bookshop who can take you through the process of selling a book, or someone in your insurance company who can show you how they process a claim. We discuss trawling techniques for this kind of investigation in Chapter 5.

You can identify one or more stakeholders who are expert in each business use case.

The processing for a business use case is continuous. That is, once it is triggered, it processes everything until there is nothing left to do that can logically be done at that time. All the functionality has been carried out, all the data to be stored by the business use case has been written to the data stores, and all the adjacent systems have been notified. You can see an example of this processing in Figure 4.5.

Figure 4.5.

The work's response to the business event is to continue processing until all active tasks (the processes) have been completed and all data retrieved or stored. You can think of the response as a chain of processes and their associated stored data. Note that the processes are surrounded by a combination of data stores and adjacent systems.

The requirements for the product you are specifying contribute to the work done by the business use case. Your product does not change the real nature of the work; it just changes the way it is done. But before you can design the optimal product, you must understand the work it supports. Most importantly, you must understand your client's desired outcome of the work. So for the moment, forget the details and technicalities of the business use case, and instead look outside the organization to see what kind of response is needed, or wanted, by the organization's customers and suppliers.

Let's start our look outside the organization by examining the systems that are adjacent to the work that you are studying.