The Good, the Bad, and the Ugly

A lot of details fall out by going through a story on what we call the happy path. This is the path where all inputs are correct, nothing goes wrong, the moon is in the seventh house, and Jupiter aligns with Mars. Do this first and fill in all the details you can. A lot of this will be obvious stuff you don't need to ask anyone about.

Next, you need to get off this happy path and dig into the requirements for handling errors, unexpected paths through the system, and unusual or unexpected data. We call this the sad path. If a report has an input of a date range, ask yourself what should happen if the "end" date is earlier than the "from" date. Ask what the customer wants to see if the user types special characters into text fields in a GUI form and clicks the Submit button. Ask what should happen if it's a Web application and the user clicks the browser Back and Forward buttons. This is likely to raise cases where you can identify several alternatives, one of which is superior, and you can ask for confirmation.

Then think about serious failures and worst-case scenarios, the bad path. What should or will happen when the log fills up? When you run out of database sessions? What happens if someone reboots the system during a critical transaction? Sets the system date incorrectly? How about malicious use by a disgruntled employee? An attack by hackers? How about alien hackers?

Okay, the alien hackers scenario is probably a bit much. But it doesn't hurt to think outside the box here some, as long as you're not thinking out loud. Go ahead and imagine some wacky scenarios, and pay attention if the outcome could be catastrophic. Consider even a highly improbable event if the negative outcome is severe enough.

This is an area in which you really need to exercise professional judgment. On occasion, you may come across something that, though unlikely, would be so bad that you need to encourage the customer to consider it. Be careful, because if the system ends up with an alien hacker denial subsystem just because you spooked the customer, neither she nor the programmers may ever forgive you.

As you go through the stories along these three paths, examine your mental model of the customer's view of the system and the likely behavior of the system from more than one viewpoint. By all means, think about what sequence of things a user could do. Then think about the content and relationships among data items, both inputs and outputs. When you're stuck on one and can't think of anything new, switch to the other view. When you feel you've exhausted the possibilities of these two, consider external events, such as interacting systems, key dates (month-end, year-end, and so on), changes in underlying and supporting systems and technologies (e.g., new versions of browsers, Java runtime).

By driving down these happy, sad, and bad (or the good, the bad and the ugly) paths and looking through the various windows on the requirements, you can flush out the details you need pretty quickly.

Here's an example of how we would employ these techniques on the directory-search application we've used in previous examples:

Example 7

Story: Create a screen that will allow the user to search on the Web for businesses by category of business and location.

First, we'll stroll down the happy path. Here are some simple user scenarios:

1. Enter a search, get results, see the desired business info, done

2. Enter a search, get no results, search again

3. Enter search, get page or less of results, don't see desired info, search again

4. Enter search, get more than one page of results, don't see desired info, go to next page of results, see info, done

5. Enter search get more than one page of results, don't see desired info, go to next page and some or all remaining, never find desired info, search again

Still on the happy path, here are various conditions in data we thought of:

1. Category/location combinations that retrieve a page or less of results

2. Category/location combinations that retrieve more than one page of results

3. Category/location combinations that retrieve no results

We couldn't think of any external events to deal with on the happy path. It's common for this view to become more useful on the sad and bad paths.

Now for the sad path. Here are some unexpected and unusual user activities:

1. Search with a misspelled category, get notice suggesting correct spelling, search again with correct spelling

2. Search with misspelled location, get notice suggesting correct spelling, search again with correct spelling

3. Search with misspelled category and location, get notice suggesting correct spellings, search again with correct spellings

Here are some error conditions in the data:

1. Category names misspelled by one and two letters

2. Location names misspelled by one and two letters

3. Pairs of misspelled category and location names for which the correct spellings retrieve one or more businesses

4. Pairs of misspelled category and location names for which the correct spellings retrieve no businesses

And an external event that could arise:

1. Changes to database records included in the search while search is in progress

Finally, the bad path. Here's what a user could do that might really mess things up:

1. Enter a search consisting only of special characters

2. Enter the maximum number of characters in each form field

3. Click for a search without selecting a category or city

4. Start a search, click the Stop button in the browser, start another search

5. Perform a search, click the Back button from the results screen, perform another search

Likewise, data conditions that would be disastrous:

1. Maximum number of database sessions reached

2. Database goes down during session

And external events:

1. Volume of concurrent searches exceeds server capacity

2. Server runs out of memory

3. Power to servers goes out