Step Six: Evaluate Use Cases

An important goal of any requirements specification is to support validation of the requirements. There are two main ways to evaluate use cases:

• Potential customers and users can read the use cases and provide feedback.
• Software designers can review the use cases to find potential problems long before the system is implemented.

To make customer or user validation more effective, it is important to keep the steps simple, concrete, and at the right level of detail. As recommended above, you should avoid using programming constructs, in part, because users may not be familiar with them. Also, users have a bad habit of providing feedback on anything that is part of the use case, even if that is not the type of feedback you need. For example, if you had included unneeded UI details such as "Scroll and control-click the name of each desired country in the list", then you are likely to get feedback on the way that standard list widgets work rather than insights into the actual task at hand. Phrasing the user intention as "Select desired counties" forces everyone to focus on the relevant issues, e.g., will the user even know which countries are desired at this point in the interaction?

When reviewing use cases, you should start by checking for too many steps or especially difficult steps. A step may be difficult for a user if it requires knowledge that the user does not have in mind at that time, e.g., what are the zip codes of your last three residences? User often have difficulty remembering to perform "post-completion" steps that do not seem relevant to their immediate goal, e.g., children often do not remember to put away toys because their goal was simply to play with them.

Another very simple way to evaluate use cases is to try performing them yourself. A rough mockup of the system can simply list the contents of each screen, without getting into details of screen layout or particular UI widget selections. Pretending to use the mockup to work through the use case can point out some use case problems. For example, you may have specified a particular system response for a step, but then find that there is no good way for the system to present that response on the current screen.

You can perform a more careful evaluation of your use cases and UI mockups with cognitive walk-throughs. In the cognitive walk-through method, you ask yourself these questions for each step:

• Will the user realize that he/she should have the intention listed in this step?
• Will the user notice the relevant UI affordance?
• Will the user associate the intention with the affordance?
• Does the system response clearly indicate that progress is being made toward the use case goal?