Product Use Case Scenarios

In this chapter, we have discussed writing scenarios for business use cases as a way of understanding, verifying, and questioning the business rules. In Chapter 4, Event-Driven Use Cases, and Chapter 5, Trawling for Requirements, we discussed techniques for deriving the product use cases from the business use cases. In other words, at some stage, you reach a point where you understand enough about the work and its constraints to be able to decide which parts of the work will be carried out by the product. At that point you can write a product use case scenario. Recall that the product use case is that part of the business use case for which you decide to build a product.

The product use case sets out the functionality of the product.

Chapter 4, Event-Driven Use Cases.

What does a product use case scenario look like? Not surprisingly, you can use the same form as you do for a business use case. The difference is that the business use case contains all of the business rules that respond to a business event, whereas the corresponding product use case contains only those business rules to be implemented in the product. Figure 6.3 is a reminder of the connection between the business use case and the product use case. Let's take a look at how we got to the product use case so that we can point the way from there to the atomic requirements.

Figure 6.3.

This functional model depicts the processes that respond to a business event. The business use case scenario shows the processing steps that respond to the business event. The product use case scenario shows the steps that will be part of the product.

Determine how much of the business use case is to be implemented as the product. The result is the product use case, which you can describe using a product use case scenario.

To begin, first identify a business event. Then trawl to discover the response to that eventthat is, the business use case. You can assess whether you have done sufficient trawling by attempting to write a business use case scenario. As discussed earlier in this chapter, writing the business use case scenario raises many business questions and leads you to formalize the business rules for that business use case. Once you are confident you know enough about the business use case, your next task is to determine how much of the business use case will be implemented as the product. The result of this determination is the product use case. Naturally, we suggest you describe it using a product use case scenario.

Earlier in this chapter we introduced this business use case scenario:

Business Event Name: Passenger decides to check in.

Business Use Case Name: Check passenger onto flight.

Trigger: Ticket, record locator, or identity and flight.

Preconditions: The passenger must have a reservation.

Interested Stakeholders: Check-in agent, marketing, baggage handling, reservations, flight manifest system, work flow, security, destination country's immigration.

Active Stakeholders: Passenger (trigger), check-in agent.

1. Locate the passenger's reservation.

2. Ensure the passenger is correctly identified and connected to the right reservation.

3. Check the passport is valid and belongs to the passenger.

   See procedure guidelines EU175.

4. Attach the frequent-flyer number to the reservation.

5. Allocate a seat.

6. Get correct responses to security questions.

7. Check the baggage onto the flight.

8. Print and convey to the passenger the boarding pass and bag tags.

9. Wish the passenger a pleasant flight.

Outcome: The passenger is recorded as checked onto the flight, the bags are assigned to the flight, a seat is allocated, and the passenger is in possession of a boarding pass and bag claim stubs.

To make decisions about the product boundary for this business use case, we need to define the constraints. We also need input from the stakeholders who understand the technical and business implications and the possibilities for the product boundary along with the business goals for the project.

Let's suppose that you have that information. That is, you and the stakeholders have decided what product to build. The product use case scenario shows what the product is to do:

Product Use Case Name: Check passenger onto flight.

Trigger: Passenger's name + passenger's passport number.

Preconditions: The passenger must have a reservation.

Interested Stakeholders: Check-in agent, marketing, baggage handling, reservations, flight manifest system, work flow, security, destination country's immigra tion.

Actor: Check-in agent.

1. Locate the passenger's reservation.

4. Attach the frequent-flyer number to the reservation.

5. Allocate a seat.

6. Check the baggage onto the flight.

7. Print the boarding pass and bag tags.

Outcome: The passenger is recorded as checked onto the flight, the bags are assigned to the flight, a seat is allocated, and the passenger's boarding pass and bag claim stubs are printed.

Note the differences between the business use case scenario and its corresponding product use case scenario. For example, the appropriate stakeholders decided that ensuring the correct passenger is attached to the reservation (step 2) is outside the scope of the product. Thus step 2 does not show up on the product use case scenario. Similarly, steps 3 and 6 are defined as being outside the product scope, so they are also omitted from the product use case scenario. (We have retained the same step numbers so that you can compare the business use case and the product use case. In practice, you would renumber the steps of the product use case so they consecutive.)

Note also that, instead of a list of active stakeholders, we identified the check-in agent as an actor. An actor is a person or system that has a direct interface with the product. In other words, the check-in agent will be the hands-on user for this product use case.

Bear in mind that our example product use case scenario reflects a particular set of decisions about the product scope. If the stakeholders had decided on a different product, then naturally the product use case scenario would be different.

As you will see in the next chapters, the product use case is the basis for writing the functional and nonfunctional requirements.