 |
|
|
|
| Robin F. Goldsmith, JD | |
|
|
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
Some people consider use cases the be-all and end-all of software requirements and testing. That's not necessarily so. In fact, the tendency to treat use cases with almost religious zeal is one of their biggest weaknesses, because it can blind one to both the likelihood and actuality of the other weaknesses.
In this tip, I'll shed some light on use cases' strengths and weaknesses and show some examples of narrative and one-column formats, alternative and exception paths, two-column formats and more.
The use case process is a popular requirements documentation format that can aid communication and also can facilitate testing as a by-product benefit. While extremely valuable, use cases do have weaknesses which often are not recognized and thus can lead to risky over-reliance.
Let's get on the same page about what a use case is. defined as "how an actor interacts with the system," a use case usually relates the actor to the user, but the actor could also be another system or a piece of hardware.
A use case is titled in terms of its goal, such as "Place an Order." Some business or temporal event trigger invokes the use case. For example, a business event might be that a customer is looking through items the seller has for sale and decides to purchase one. A temporal event might be that the customer has agreed to renew their order automatically on a given date each year.
The heart of the use case describes the interaction step-by-step from the perspective of the actor: the actor does this, and the system does that in response. Such concrete behavioral descriptions make it easier for the user and developer to have a common understanding of how the system will operate. Consequently, use cases can enable the developer to develop a system that works just the way the user expects!
What a delightful change this can be from the typically too common disappointing situation in which the developer designs dynamically -- i.e., guesses, usually without being aware of guessing -- how the system should function, only to discover afterward that it's not what the user wants. Because of use cases' success in reducing such discrepancies, they have become probably the most widely-used method of documenting requirements.
Narrative and one-column formats
The simplest use case format is a narrative, where each sentence is a separate user behavior or system response. For example, a narrative format use case for placing an order from the perspective of the customer placing the order might be:
Identify the customer in the database by Customer ID. System displays customer's identification information. For each item to be ordered, select the item from a menu of items for sale. For each item to be ordered, system displays the item's ID, description, and unit price. For each item to be ordered, indicate the quantity of the item ordered. For each item to be ordered, system calculates the extended price equals quantity times unit price. Indicate the order is complete. For the entire order, system calculates the total amount due equals sum of extended prices for all items ordered. Pay the total amount due.
Because the narrative format inherently can be hard to understand, use cases most commonly are documented in a "one-column" format, where each step is an individual numbered line. While in practice the amount of verbiage may differ and thereby obscure the one-line-per-step essence, the same use case in a one-column format would be:
- Identify the customer in the database by Customer ID.
- System displays customer's identification information.
- For each item to be ordered, select the item from a menu of items for sale.
- For each item to be ordered, system displays the item's ID, description, and unit price.
- For each item to be ordered, indicate the quantity of the item ordered.
- For each item to be ordered, system calculates the extended price equals quantity times unit price.
- Indicate the order is complete.
- For the entire order, system calculates the total amount due equals sum of extended prices for all items ordered.
- Pay the total amount due.
Since these nine steps would be the normal way the use case is executed, they often are called the "happy path" or "main path." Note, even though these nine steps seem evident and straightforward, it's possible someone else could have described a somewhat different set of happy path steps for this use case. There's not a single one-and-only way to characterize the steps inherent in a situation. I don't think most use case writers realize how significantly the depiction of use case steps can vary from writer to writer.
While these days, use cases' step-by-step descriptions from the user's perspective are assumed to be intuitively desirable for developers, that wasn't always the case. I've used the technique since long before Ivar Jacobson gave it the clumsy "use case" name; and I've got to tell you that back then traditional programmers were not at all comfortable working with specifications from the user's perspective.
Continue to the next section on alternative and exception paths, two-column formats and more.
This was first published in May 2009