Guidelines for Writing Use Cases

• Capture the user's intention, not the details of a particular UI.
• Each use case should show the user succeeding at a goal. Any type of failure or error should be handled as an alternative.
• If one use case has too many steps or extensions, split it into two use cases. Use the "perform" notation to refer to shared steps.
• If it is not already clear from context, you may want to number the steps of an extension to indicate the point in the main use case steps where the extension starts.
• The actor, frequency, and use case name should fit into this sentence, both logically and grammatically: "An ACTOR will FREQ want to USE-CASE-NAME." If the frequency is "Once", scope the timeframe: e.g., once per user, or once per customer, or once per installation.
• If a use case has more than about 9 steps, you are probably showing too much detail (or the task will be really hard to perform).
• Evaluate the usefulness and usability of your system by evaluating the use cases before going further with design or implementation. See the words of wisdom for links to evaluation techniques.
• One good evaluation technique is the cognitive walkthrough. At each step think of a confident answer to these questions:
  • Would the user realize that they should do that step?
  • Would the user recognize the proper button to press?
  • Would the user be able to provide the needed information?
  • Does the system provide an indication that the user's action succeeded?