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?
Conclusion
This white paper presented six simple steps to writing
effective use cases. The keys to using use cases to effectively
specify software requirements are to:
Take a breadth-first approach that maps out a fairly complete set
of possible user interactions and provides full details on those use
cases that are likely to give the best return on your
efforts.
Write use cases at the right level of abstraction, focusing
on user intent and avoiding unneeded UI details.
Evaluate use cases to help validate the system requirements
before moving on to design and implementation.
ReadySET Pro provides valuable help for writing effective use
cases by giving you templates that include reusable content and
set good examples for you to follow. Both of these advantages
give you a big head start on your own software requirements
specification. ReadySET Pro users typically save at least three
hours by using the use case suite and use case templates alone.
To estimate how these savings, and the savings from other
templates, add up to days or weeks of project time, see the ROI Calculator.