Business Use Case Workshops

We have found business use case workshops to be useful on most projects. These workshops allow you to work with a smaller number of specialized stakeholders at a time.

In Chapter 4, Event-Driven Use Cases, we discussed what business events are and how they trigger a response by the work, which we called a business use case. We hope that by devoting an entire chapter to this subject, we have unequivocally signaled the importance of partitioning the work according to how it responds to the world outside it.

Of course, having partitioned the work, we need to do something with the pieces. That is the role of the business use case workshop. The workshop is a human activity where the interested stakeholders describe or reenact the work done, or desired to be done, by the business use case. Your task is to record these actions and then use them to derive the requirements for the product that will best help with the work.

Refer to Chapter 4, Event-Driven Use Cases, for a complete explanation of business events and business use cases.

But let's start at the beginning.

Each business use case has one or more interested stakeholderspeople who are experts on that part of the work, and who have a particular interest in the outcome of the business use case. The workshop transfers knowledge of the business use case from its interested stakeholders to the requirements analyst. These individuals lock themselves away in a JAD (joint application development)style workshop and construct scenarios to show the actions necessary to make the correct response to the business event. (See Figure 5.7.)

Figure 5.7.

The business use case workshop records the proposed functionality using scenarios and lowfidelity prototypes. Ideally, the interested stakeholders can communicate effectively and express their understanding, ask questions, and give their aspirations for the work.

Gottesdiener, Ellen. Requirements by Collaboration: Workshops for Defining Needs. Addison-Wesley, 2002. Gottesdiener's book covers in detail how to plan and conduct requirements workshops.

In Chapter 6, Scenarios and Requirements, we talk about scenarios, which involve telling the story of the business use case in a fairly structured way. We propose that you use the business use case scenario as a talking point during discussions with your stakeholders. Feel free to peek into Chapter 6, but for the moment it will suffice if you think of a scenario as a breakdown of the business use case's functionality into a reasonable number of steps.

See Chapter 3, Project Blastoff, for more on how to discover the relevant interested stakeholders.

Using scenarios as a communication device, the analyst and stakeholders work together to acquire the knowledge of the business use case:

• The desired outcome for the business use case

• Scenarios describing the work done by the business use case

• Exception scenarios describing what things can go wrong and what the work does to correct them

• Alternative scenarios showing allowable variations to the work

• The business rules applicable to the business use case

• The product use casehow much of the business use case is to be done by the product

• Characteristics of likely users of a product built for this business use case

• Low-Fidelity prototypes used to help stakeholders visualize the business use casethese throwaway prototypes are not intended to be kept beyond the requirements phase

Outcome

Think of outcomes, not outputs.

The outcome is what the organization hopes to achieve whenever the business use case occurs. You should think of this result in terms of outcomes, not outputs. For example, suppose the business use case is "Rent a car to a customer." The desired outcome is that the customer drives away in the car of his choice, the rate selected is equitable, the details are recorded, and the transaction is completed with minimal inconvenience to the customer at minimal cost. The outputs of the same business event are the rental document and some recorded data.

Note that the outcome is a business objective, not a way of achieving something. Outcomes are usually expressed from the point of view of the organization or of the organization's customer. The outcome is what you are trying to achieve, which is why it is important. This outcome gives your business use case its reason for existing.

You should be able to write the outcome of the business use case in one sentence: When this business use case happens, what should be achieved when the work for the business use case has finished?

Scenarios

Scenarios describe the work being done by the business use case as a seriesusually between three and tensteps. The scenario is a stakeholder-friendly document used as the focal point of the workshop. The steps are not very detailed, because the intention is not to capture every small part of the business use case, but rather to have a broad-brush picture of the work.

The normal-case scenario shows the actions of the business use case if all goes well and no mistakes are made, wrong actions taken, or any other untoward happening occurs. The intention is for you and your stakeholders to reach consensus on what should happen. Other scenarios focus on the exception caseswhen unwanted things go wrongand alternative scenarios when the people involved in the business use case decide to take some allowable alternative actions.

Chapter 6, Scenarios and Requirements, is a full treatise on scenarios.

The collection of scenarios represents the interested stakeholders' consensus on what the work should do in response to the business event. We stress again the importance of understanding the work, and not just the product. Armed with this understanding, the analyst and the interested stakeholders decide on the optimal product for the business use case. The right product to build usually becomes apparent as the discussion of the work progresses. Once it has been decided, the requirements analyst writes the requirements for the product. We will talk about this task in Chapter 7, Functional Requirements.

Business Rules

The business rules are management prescriptions that transcend and guide the day-to-day business decisions. Naturally, any product you build must conform to the business rules. These rules come to the surface as the stakeholders discuss the work for each business event. Later they are used to guide the functional requirements and to help to discover the meaning of stored data.

There is no set form for the business rules. For most projects you will be able to find, with the help of the interested stakeholders, existing documents that spell out these rules. The business rules eventually become incorporated into the business use case scenarios and the requirements.