Editing Use case (section)

== Templates ==

There are many ways to write a use case in the text, from ''use case brief'', ''casual'', ''outline'', to ''fully dressed'' etc., and with varied templates. Writing use cases in templates devised by various vendors or experts is a common industry practice to get high-quality functional system requirements.

=== Cockburn style ===

The template defined by [[Alistair Cockburn]] in his book ''Writing Effective Use Cases'' has been one of the most widely used writing styles of use cases.{{citation needed|date=March 2016}}

==== Design scopes ====

Cockburn suggests annotating each use case with a symbol to show the "Design Scope", which may be black-box (internal detail is hidden) or white box (internal detail is shown). Five symbols are available:<ref>Cockburn, 2001. Inside front cover. Icons "Design Scope".</ref>

{| class="wikitable"
|-
! Scope !! Icon|| 
|-
| Organization (black-box) || Filled House || [[File:Scope-icons-filled-house.png|Scope-icons-filled-house]]

|-
| Organization (white-box) || Unfilled House || [[File:Scope-icons-unfilled-house.png|center|Scope-icons-unfilled-house]]
|-
| System (black-box) || Filled Box || [[File:Scope-icons-filled-box.png|center|Scope-icons-filled-box]]
|-
| System (white-box) || Unfilled Box || [[File:Scope-icons-unfilled-box.png|center|Scope-icons-unfilled-box]]
|-
| Component || Screw or Bolt || [[File:Scope-icons-screw-bolt.png|center|Scope-icons-screw-bolt]]
|}

{{clear}}

Other authors sometimes call use cases at the Organization level "Business use cases".<ref>Suzanne Robertson. ''Scenarios in Requirements Discovery''. Chapter 3 in Alexander and Maiden, 2004. Pages 39-59.</ref>

==== Goal levels ====
[[File:Cockburnstyle use cases.svg|thumb|Hierarchy of goal levels]]
Cockburn suggests annotating each use case with a symbol to show the "Goal Level";<ref>Cockburn, 2001. Inside front cover. Icons "Goal Level".</ref> the preferred level is "User-goal" (or colloquially "sea level"<ref name=Fowler/>{{rp|101}}).

{| class="wikitable"
|-
! Goal Level !! Icon !! Symbol ||
|-
| Very High Summary || Cloud || ++ || [[File:Goal-level-icons-cloud.png|center]]
|-
| Summary || Flying Kite || + || [[File:Goal-level-icons-flying-kite.png|center]]
|-
| User Goal || Waves at Sea || ! || [[File:Goal-level-icons-waves-at-sea.png|center]]
|-
| Subfunction || Fish || - || [[File:Goal-level-icons-fish.png|center]]
|-
| Too Low || Seabed Clam-Shell || -- || [[File:Goal-level-icons-seabed-clam-shell.png|center]]
|}

{{clear}}

Sometimes in text writing, a use case name followed by an alternative text symbol (! +, -, etc.) is a more concise and convenient way to denote levels, e.g. ''place an order!'', ''login-''.

==== Fully dressed ====

Cockburn describes a more detailed structure for a use case but permits it to be simplified when less detail is needed. His fully dressed use case template lists the following fields:<ref name=Cockburn120>Cockburn, 2001. Page 120.</ref>

* Title: "an active-verb goal phrase that names the goal of the primary actor"<ref>Cockburn, 2001. Inside rear cover. Field "Use Case Title".</ref>
* Primary Actor
* Goal in Context
* Scope
* Level
* Stakeholders and Interests
* Precondition
* Minimal Guarantees
* Success Guarantees
* Trigger
* Main Success Scenario
* Extensions
* Technology & Data Variations List

In addition, Cockburn suggests using two devices to indicate the nature of each use case: icons for design scope and goal level.

Cockburn's approach has influenced other authors; for example, Alexander and Beus-Dukic generalize Cockburn's "Fully dressed use case" template from software to systems of all kinds, with the following fields differing from Cockburn:<ref>Alexander and Beus-Dukic, 2009. Page 121</ref>

* Variation scenarios "(maybe branching off from and maybe returning to the main scenario)"
* Exceptions "i.e. exception events and their exception-handling scenarios"

==== Casual ====

Cockburn recognizes that projects may not always need detailed "fully dressed" use cases. He describes a Casual use case with the fields:<ref name=Cockburn120/>

* Title (goal)
* Primary Actor
* Scope
* Level
* (Story): the body of the use case is simply a paragraph or two of text, informally describing what happens.

=== Fowler style ===

[[Martin Fowler (software engineer)|Martin Fowler]] states "There is no standard way to write the content of a use case, and different formats work well in different cases."<ref name=Fowler>Fowler, 2004.</ref>{{rp|100}} He describes "a common style to use" as follows:<ref name=Fowler/>{{rp|101}}
* Title: "goal the use case is trying to satisfy"<ref name=Fowler/>{{rp|101}}
* Main Success Scenario: numbered list of steps<ref name=Fowler/>{{rp|101}}
** Step: "a simple statement of the interaction between the actor and a system"<ref name=Fowler/>{{rp|101}}
* Extensions: separately numbered lists, one per Extension<ref name=Fowler/>{{rp|101}}
** Extension: "a condition that results in different interactions from .. the main success scenario". An extension from main step 3 is numbered 3a, etc.<ref name=Fowler/>{{rp|101}}

The Fowler style can also be viewed as a simplified variant of the Cockburn template. This variant is called a [[user story]].

Alistair Cockburn stated:<ref name="wiki.c2.com">{{cite web |url=http://wiki.c2.com/?UserStoryAndUseCaseComparison | title=User Story And Use Case Comparison | access-date=2024-01-19}}</ref>

{{quote|Think of a User Story as a Use Case at 2 bits of precision. Bit 1 of precision names the goal of the use case, and Bit 2 adds the main scenario. Bit 3 adds the failure conditions, Bit 4 adds the failure actions. Bit 5 adds a data description of the in/out data. I would put Catalysis at the 6th bit of precision, as they include a model also of the recipient of the message. In the CrystalMethodology family, differently founded projects use cases at different levels of precision. A methodologically light project uses User Stories, a methodologically heavier project uses Use Cases to 4 bits of precision, and Catalysis uses 6 bits of precision.}}

Martin Fowler stated:<ref name="wiki.c2.com"/>

{{quote|It is all about how people use cases. I've seen many people use cases in a very formalized manner. Kent does his UserStories in a much more approachable manner. I do use cases the way Kent does User Stories. I call them to use cases to better communicate with other developers and to influence them to use a more lightweight approach.}}