Determining What the Product Should Be

This section applies to all projects. Unfortunately, many projects start with a preconception of what the product should be without understanding the work that it is to become a part of. Here we look at things you can do to find the optimal product.

The unspoken, but nevertheless significant task of requirements analysis is to determine what the work should be in the future and how the product can best contribute to that work. The product is the part of the work you choose to change in some wayusually by automating it. The objective is to find the optimal business use case. As business use cases are usually responses to requests from the outside world for the work's service, the optimal response is to provide the most valuable service (from the customer's point of view) at the lowest cost in terms of time, materials, or effort (from your organization's point of view).

Your task is to find the best business use casethat is, to find the best way to achieve the desired outcome for the business use case. The best business use case is always the one closest to the essence of the work. Sometimes it incorporates some invention. Once you have achieved an intimate understanding of the work of the business use case, you decide how much of this work will be done by your product.

It is only by first understanding the work, and then automating part of it, that we achieve a seamless fit between our automated product and the work.

Let's look at an example of how we determine how much of the work is to become the product.

Consider the situation depicted in Figure 5.12. In this typical business use case, we see a customer (an adjacent system) ordering groceries over the telephone. Now, what is the best place to put the product boundary? Or, thinking of it another way, what makes the best product?

Figure 5.12.

Once you understand the complete business use case, you establish how much of it will be done by the product. The heavy dotted lines in the figure represent alternative product boundaries. The automation is to be whatever is to the right of the dotted line.

What about the product that would result from boundary number 1? An operator enters the checked order and the product records the order once the credit card company has authorized it. This approach does not yield a very good product, as it forces the operator to do most of the work.

Getting the right product scope is crucial to getting the right requirements.

What about boundary number 2? The userin this case, the telephone representativetakes the order over the telephone and enters it into the product, which then does the credit card check and records the order. Not bad, but perhaps we could do better.

Boundary number 3 automates order taking. Customers make a telephone call to a product capable of voice recognition or recognizing commands from the telephone keypad. Provided there are no questions or serious responses needed, customers get the advantage of calling 24 hours a day. Alternatively, customers could log on to the grocery company's Web site and enter their own orders online.

Solution number 3 might be convenient for the grocery company, but what about the customer? What does she really want? What service should the grocery company provide to keep her loyalty?

The True Origin of the Business Event

In Chapter 4, when we discussed business events, we suggested you look for the real origin of the event. Almost certainly, the origin does not lie within the operator. The operator is, after all, part of the response to the business event. So the business event does not occur when the operator sits down at a computer to enter some data. Rather, it originates outside the work when the adjacent system does something. In the case illustrated in Figure 5.12, the true origin of the business event is when the customer became short of groceries. When the customer became aware of this problem, she probably went around the kitchen counting groceries and determining what she needed to order. Thus the origin of the business event occurred some 30 minutes before she picked up the phone.

From the customer's point of view, the most useful product would count the groceries for her. If the grocery company knew the quantities of grocery items the customer already had and knew her consumption rates, then the customer would not need to make the telephone call. Instead, the company could call the customer, inform her of what she needed, and arrange a suitable delivery time. This scenario extends the product scope until it gets into the brain of the adjacent system, and produces a betterfrom the service and convenience points of viewproduct.

We extend the product scope until it gets into the brain of the adjacent system.

Examine your business events, particularly those that are initiated by humans. By this, we do not mean the human operator or user, but rather the human adjacent system. What is the adjacent system doing at the time of the event? Can you extend your product scope to include that activity, whatever it is? For an example of extending the product scope, consider the check-in procedure for passengers flying in Virgin Atlantic's Upper Class. Upper Class (Virgin's first class) passengers are given a limousine ride to the airport (a welcome piece of innovation). Instead of the limo driver dumping the passengers at the terminal and letting them lug their bags to the check-in desk, passengers check in while they are still in the car. The driver phones ahead to the drive-through check-ins that Virgin has installed at some airports and gives the number of bags to be checked. When the car arrives at the drive-through check-in, passengers are handed boarding passes and baggage-claim checks, and then taken to the terminal. All that remains is to walk to the Upper Class Lounge. From this example, we learn that Virgin Atlantic considers the business use case to be triggered when passengers leave home, not when they reach the check-in desk.

Find the true origin of the business use case.

Think about your own business use cases. Do they really begin at the boundary of your work, or do they start well before they reach your organization?