Normal Case Scenarios

Now go back over your sketch for the scenario, looking for unanswered questions and ways to improve this work. Change the language to be technologically neutral, which should help you to see any potential opportunities for an improved automated product.

Assume for the normal case that everything works perfectly.

It helps you to consider the details if you deal with the normal case first. Assume for this case that everything works perfectly. Once you have defined the normal case, you can go back over it and add in the alternatives and exceptions.

1. Get the passenger's ticket, record locator, or identity and flight number.

The ticket and the record locator are both constraints on the work. The ticket comes from outside. That is, the passenger has been carrying it up to this point. The record locator is a constraint imposed by the current computer system; in this case, it cannot be changed. However, the ticket and the record locator are merely means to an endthe real work to be done is to find the passenger's reservation. Let's rewrite step 1 to reflect this understanding:

1. Locate the passenger's reservation.

This step could be completed without either a ticket or a record locator. Writing it this way opens up several possibilities for the new product. Perhaps passengers could swipe a machine-readable passport, use a credit card, or use any of several other ways to identify themselves. It remains to be seen if the constraints can be overcome.

Once identified, the work then connects the passenger to his reservation:

2. Is this the right passenger, flight, and destination?

This step focuses on ensuring that the passenger is who he says he is, and that the reservation matches his expectations for the flight. Let's rewrite step 2 accordingly:

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

Next the scenario checks the passport:

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

This step is slightly more complex and warrants a few words of explanation. We suggest adding the explanation to the step:

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

3.1 The passport must be current.

3.2 The passport must not expire before the end of the complete trip.

3.3 The passport must be valid for travel to the destination country.

3.4 Visas (where needed) must be current.

3.5 There must be no "refused entry" stamps from the destination country.

Alternatively, you might simply leave this as it was and refer to notes to complete the business rules for the step:

3. Check the passport is valid and belongs to the passenger. See procedure guidelines EU175.

The same technique might be employed for later steps in the scenario. Keep working through it until you and your interested stakeholders agree that it is an accurate, but not yet detailed, portrayal of the work.

Business Event: Passenger decides to check in.

Business Use Case Name and Number: Check passenger onto flight.

Trigger: Passenger's 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 correct passenger is connected to the reservation.

3. Check the passport is valid and belongs to the passenger. See procedure guidelines EU175.

4. Attach passenger's frequent-flyer number to the reservation.

5. Allocate a seat.

6. Get correct responses to the security questions.

7. Check the baggage onto the flight.

8. Create 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.

We add an outcome to the scenariothat is, the desired situation at the successful conclusion of the business use case. Think of it as the stakeholder's objectives at the time when he triggers the use case.