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?

Step Five: Write Steps for Selected Use Cases

Now it is time for the main event: actually writing the use case steps. This is a task that you can expect to take ten to forty-five minutes for each use case. That might average out to only about ten use cases in a typical work day. Again, you must be selective to get the most value in return for your limited available time.

Focus on use cases that seem most likely to affect the success of the project. For example, select use cases that:

• Enable users to achieve the key benefits claimed for your product
• Determine a user's first impression of the product
• Challenge the user's knowledge or abilities
• Affect workflows that involve multiple users
• Explain the usage of novel or difficult-to-use features

Each use case should show a straightforward example of the user succeeding at a goal. The steps in a use case are almost always a linear sequence. You should not use programming constructs such as if-statements or loops, if at all possible. Rather than use conditional statements, use an extension point to describe any type of failure or error condition.

Each use case step has two parts: a user intention and system response:

User Intention

The user intention is a phrase describing what the user intends to do in that step. Typical steps involve accessing information, providing input, or initiating commands. Usually the user intent clearly implies a UI action. For example, if I intend to save a file, then I could probably press Control-S. However, "press Control-S" is not written in use cases. In general, you should try not to mention specific UI details: they are too low-level and may change later.

System Response

The system response is a phrase describing the user-visible part of the system's reaction to the user's action. As above, it is best not to mention specific details that may change later. For example, the system's response to the user saving a file might be "Report filename that was saved". The system response should not describe an internal action. For example, it may be true that the system will "Update database record", but unless that is something that the user can immediately see, it is not relevant to the use case.

Use case steps can be written in either two-column or one-column format. The two-column format forces every step to include an explicit user intention and system response. The one-column format gives you more flexibility to skip system responses that are obvious, and to handle multiple actors interacting with the system in one use case.

Recall that one of the advantages of writing use cases is that it forces you to clearly think through the details of the system. Capture your insights by writing notes and questions as you go. If a use case step reminds you of a specific requirement in a system feature, make a note of it in the corresponding feature specification.

Step Six: Evaluate Use Cases

Step Four: Write Some Use Case Descriptions

In step three, you may have generated ten to fifty use case names on your first pass. That number will grow as you continue to formalize the software requirements specification. That level completeness of the specification is very desirable because it gives more guidance in design and implementation planning, it can lead to more realistic schedules and release scoping decisions, and it can reduce requirements changes later.

The downside to mapping out the big picture is simply that it is too big. It could take a long time to fully specify every use case that you have mapped out. And, the resulting document could become too large, making it harder to validate and maintain.

The solution is to be selective before moving to the next level of detail. For example, if there are clearly too many use cases for one release, reschedule some of them for later releases. Also, it's a good idea to just write descriptions rather than get into detailed steps for each use case. Going deep into the details of just a few use cases is enough to shake out uncertainties and identify areas for improvement. The bulk of the use cases can be done later, it needed at all.

Write one to three sentence descriptions of each use case that you plan to implement in this release. The description should provide a little more information on the user's goal and briefly outline the strategy that the user will follow. Sometimes there will be two or more ways to accomplish the same goal. If there are significant differences in strategy, it is a good idea to split the use case into two distinct use cases.

Step Five: Write Steps for Selected Use Cases