.Open Use Case Templates
. About
This is a quick summary of how to write use cases.
. Advice
.List
 The name should start with a strong verb. 
 A use case is a set of scenarios.  A scenario is a list of steps.
 Each step should state what the user does and/or what the system responds.
 The steps must not mention `how` the system does something.
Keep the steps essential or logical -- no colors, clicks, typing!
 Each step needs to be analysed in detail before it becomes code.
 Keep It Simple: use the simplest format you need.
 Refine interesting use cases first.
 Make sure you store use cases so that they are easily found, edited, and used.
 Put use cases on a project web site.
 Keep track of different versions.
 Writing use cases is a team sport.
 Focus on a particular user (give them a name) in each use case and each step.
 Don't get bogged down in all the special ways it can go wrong until you've finished the main success story.
 Also see $Rules below.
.Close.List
. 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:
.As_is 		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.
.As_is 		(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.
.Box
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.
.Close.Box
.Open Casual Format
Name
(Main Success Scenario): Brief one paragraph description.
(Alternate scenario 1):  if ...., one paragraph
(Alternate scenario 2):  if ...., one paragraph
.Close Casual Format
Notice that the scenarios are labelled for later cross reference and discussion.

Example
(UC1):Enrol student in class.
.Box
(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 and there is no alternativ,e the system suggests talking
to an advisor.
.Close.Box
Notice that the scenarios are labelled for later cross reference and discussion.
.Close Casual Format


.Open Less Casual Format
This differs from a casual format in that the scenarios are numbered lists of
steps.
Name
(Main Success Scenario): list of steps.
(Steps letter):  if ...., list of steps.
(Steps letter):  if ...., list of steps.
Example
(UC):Enrol student in class.
.Box
(UC): 
.List
 The student logs in to the enrolment system and requests a list of sections
of a class.  
 The student selects one class to enrol in and the system records
this enrolment.
 The student is provided with confirmation that they have been enrolled.
	They can select more classes.
 The student logs out.
.Close.List

(UC2a): The class is full and the system proposes an alternative.
(UC3b): The student cancels the enrollment after confirmation.
(UC2aa): The class is full and there is no alternative, the system suggests talking
to an advisor.
.Close.Box

.Close Less Casual Format

.Open 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
.Set
 (stakeholder1): what they want.
 (stockholder2): what they want.
.Close.Set
. 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.
.Open Main Success Scenario
 step_number: actor does something or system responds
.Close
.Open Extensions
(step numbers letter): condition
.List
 actor does something/system does something
.Close.List
.Close Extensions
. Special Requirements
.Set
 desired quality or technological limitation
.Close.Set
. Variations in Technology and Data
.Set
 step number: possible change in technology or data format
.Close.Set
. Frequency of Occurrence
. Miscellaneous
.Set
 Question
 Topic to research
.Close.Set
. Fully dressed as a table
Here is a Tabular Format
.Table
.Row Name
.Item Start with a verb, numbering optional
.Row Scope
.Item The System under Design
.Row Level
.Item User-goal or subfunction
.Row Primary Actor
.Item Asks the $SUD to deliver service to meet goals
.Row Stakeholders and Interests
.Item (stakeholder1): what they want.
.Row Preconditions
.Item State what special and interesting things must be true for this particular  case to work.
.Row Postconditions
.Item List the interesting things that are true after a scenario is completed
.Row Main Success Scenario
.Item actor does something or system responds
.Close.List
.Row Extensions
.Item (steps letter): condition steps
.Row Special Requirements
.Item desired qualities or technological limitations
.Row Variations in Technology and Data
.Item step number: possible change in technology or data format
.Row Frequency of Occurrence
.Item How often
.Row Miscellaneous
.Item Open issues to research
.Close.Table
. Fully dressed template
.See ./fullydressed.txt
.See ./fullydressed.html
.Close Fully Dressed
.Open Rules for scenarios
Source:
.Key Rules
.See [YueBriandLabiche13]

 Each event is a sentence with either the system or an actor as the subject.
 Describe a sequence of events.
 No interations between actors.
 One action per sentence.
 Use active voice not passive.
 Clearly show who is sender and who reciever.
 Use Declarative sentences.
 Use words consistently.
 Don't use modal verbs like "might".
 Avoid adverbs.
 Use simple sententences: one sobject + one predicate.
 Don't use negative adjectives and adverbs.
 No pronouns.
 Don't use participle phrases as an adverbial phrase.
 Use "The system" consistently to refer to the system under design.
 You can INCLUDE another use case.
 You can indicate an EXTENDED BY use case.
 You should indicate where an alternative sequence flows from.
 Use IF-THEN-ELSE-END IF, and ELSEIF
 Use MEANWHILE ___
 Use VALIDATE THAT ___
 Use DO-UNTIL
 Use ABORT
 Use RESUME_STEP ___
 Each basic flow and alternative flow should have its own postcondition
** Controversial **
.Close Rules for scenarios

. Tools
Use a dumb editor!

. See Also
.See [Cockburn02b]
(Alistair Cockburn's article).

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

.See http://www.google.com/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).

.See http://en.wikipedia.org/wiki/Use_case
(Wikipedia).
.Close Use Case Templates