- Project tools
- How do I...
|Over 500 more tools...
- Default Aspects of All Use Cases
- Individual Use Case Template
Advice from ReadySET Users
To add your own words of wisdom, please send an email to the dev mailing
- BODY OF ADVICE
Guidelines for Writing Use Cases
- Capture the user's intention, not the details of a particular
- 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
- 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