Contents

• Use Case Templates
• : About
• : Advice
• : Start with a meaningful name
• : Brief Format
• : Casual Format
• : Fully Dressed
• : Tools
• : See Also

Use Case Templates

About

This is a quick summary of how to write use cases.

Advice



1. The name should start with a strong verb.
2. A use case is a set of scenarios. A scenario is a list of steps.
3. Each step should state what the user does and/or what the system responds.
4. The steps must not mention how the system does something. Keep the steps essential or logical -- no colors, clicks, typing!
5. Each step needs to be analysed in detail before it becomes code.
6. Keep It Simple: use the simplest format you need.
7. Refine interesting use cases first.
8. Make sure you store use cases so that they are easily found, edited, and used.
9. Put use cases on a project web site.
10. Keep track of different versions.
11. Writing use cases is a team sport.
12. Focus on a particular user (give them a name) in each use case and each step.
13. Don't get bogged down in all the special ways it can go wrong until you've finished the main success story.



Start with a meaningful name

The minimum documentation is a well chosen name. It should start with a verb and indicate the type of user, and what they achieve:

 		Enrol student in class.

This is better than nothing... and the start for drafting more complete descriptions of the use case.

There is a lot to be said for labelling use cases with a short identifier.

 		(UC1): Enrol student in class.

Brief Format

Name + Terse one paragraph description of who does what to get what.

Notice that we just add the description to the name+label:
(UC1): Enrol student in class.

---

The student logs in to the enrolment system and requests a list of sections of a class. They then select one class to enrol in and the system records this enrolment. The student is provided with confirmation that they have been enrolled.

---

Casual Format

Name
(Main Success Scenario): Brief one paragraph description.
(Alternate scenario 1): if ...., one paragraph
(Alternate scenario 2): if ...., one paragraph

. . . . . . . . . ( end of section Casual Format) <<Contents | End>> Notice that the scenarios are labelled for later cross reference and discussion.

Example
(UC1): Enrol student in class.

---


(UC1main): The student logs in to the enrolment system and requests a list of sections of a class. They then select one class to enrol in and the system records this enrolment. The student is provided with confirmation that they have been enrolled.


(UC1a): The class is full and the system proposes an alternative.
(UC1b): The student cancels the enrollment after confirmation.
(UC1aa): The class is full adn ther is no alternativ, the system suggests talking to an advisor.

---

Fully Dressed

Use this only for the really valuable and interesting use cases.

Here are the headings for a fully dressed use case

Name

Start with a verb, numbering optional

Scope

The System Under Design or Context

Level

Enterpise goal, User-goal, or subfunction

Primary Actor

Name the actor who uses the system under design to achieve some goal.

Stakeholders and Interests

• (stakeholder1): what they want.
• (stockholder2): what they want.

Preconditions

State what special and interesting things must be true for this particular case to work.

Postconditions

List the interesting things that are true after a scenario is completed.

Main Success Scenario

1. step_number: actor does something or system responds

Extensions


(step numbers letter): condition

1. actor does something/system does something



. . . . . . . . . ( end of section Extensions) <<Contents | End>>

Special Requirements

• desired quality or technological limitation

Variations in Technology and Data

• step number: possible change in technology or data format

Frequency of Occurrence

Miscellaneous

• Question
• Topic to research

Fully dressed as a table

Here is a Tabular Format
Table

Name	Start with a verb, numbering optional
Scope	The System under Design
Level	User-goal or subfunction
Primary Actor	Asks the SUD to deliver service to meet goals
Stakeholders and Interests	(stakeholder1): what they want.
Preconditions	State what special and interesting things must be true for this particular case to work.
Postconditions	List the interesting things that are true after a scenario is completed
Main Success Scenario	actor does something or system responds
Extensions	(steps letter): condition steps
Special Requirements	desired qualities or technological limitations
Variations in Technology and Data	step number: possible change in technology or data format
Frequency of Occurrence	How often
Miscellaneous	Open issues to research


(Close Table)


Fully dressed template

[ fullydressed.txt ] [ fullydressed.html ]

. . . . . . . . . ( end of section Fully Dressed) <<Contents | End>>

Tools

Use a dumb editor!

Note that you can get an ASCII version of these forms here [ usecases.txt ] and use my m2h tool [ ../hole.html ] to generate HTML -- you don't have to send it to me -- just preview and save!

See Also

[Cockburn02b] (Alistair Cockburn's article).

[ http://www.accompa.com/product-management-blog/2009/10/08/use-case-template-example-requirements-management-basics/ ] (shorter fully dressed form).

[ url?sa=t&source=web&cd=4&ved=0CC0QFjAD&url=http%3A%2F%2Fninova.itu.edu.tr%2Fen%2Fcourses%2Finstitute-of-informatics%2F156%2Fbbl-502%2Fekkaynaklar%3Fg99523&rct=j&q=fully%20dressed%20use%20case%20example&ei=a5ztTMnuKMGVnwfi_sD9CA&usg=AFQjCNHEWXzGLEj3rDMNrNzzGQw_p3VPAQ&cad=rja ] (Larman's UC1: Process Sale in PDF).

[ Use_case ] (Wikipedia).

. . . . . . . . . ( end of section Use Case Templates) <<Contents | End>>

End