- Introduction
- Involve Testing and Quality Assurance Before Thinking About Design
- Identifying the Ways in Which a Use Case Can Fail
- Documenting the Extension Handling Steps
- Creating the Acceptance Test Cases
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Documenting the Extension Handling Steps
How the application is supposed to respond to the various failure conditions is something that you, as a developer, need the users to tell you. Yes, the users may need some guidance as to what's possible, but usually the goal is to make the application easy to use and productive for the users. Sometimes we can get away with doing whatever is easiest to code, but that's the path to really abysmal, difficult-to-use software.
When faced with the following extensions, the application could simply stop, but that would probably not be very friendly to the users:
4c Mail server reports that email address is invalid.
4d Selected member does not have an email address.
Involving users in designing the extension handling steps means that they're in charge of the requirements for the application. Once the users have designed the requirements, you can then proceed to design an application that satisfies their requirements.
Documenting the extension handling steps is relatively simple. Inside the extensions section of the use case, write down the steps necessary to recover from the failure.
Extensions:
...
4d Selected member does not have an email address.
.1 Membership System: Display list of members without an email address.
.1a Club Secretary: Cancel print option.
.2 Membership System: Print event details with email-challenged members' names and phone numbers.
.2a Printer not available.
.2b Member does not have a contact phone number.
.2b1 Membership System: Print ".........." where phone number should be.
...
Now we start to see the full complexity of the use case, since every subfunction goal inside the extension handling steps could also fail. It also explains why you want testers involved in eliciting the requirements, since they're so good at finding things that can go wrong.
On the other hand, for many applications it's perfectly valid to just ignore some errors and leave them for the users to handle manually. The failure condition 4d2b Member does not have a contact phone number probably falls into this category—as the step of printing ".........." suggests.
Once you have specified the extension handling steps for every extension, you have a fully elaborated use case. You also have spent a considerable amount of time and effort working with your users and testers to understand just this one small part of the application. With the knowledge you've gained, you're probably ready to start working on the design, although you might want to wait until you have a few more use cases fully elaborated. But don't make the mistake of waiting until you have all of your use cases fully elaborated; that's the slow waterfall process—you want to capture requirements incrementally so that you can deliver incrementally.