Use Case Fundamentals.md 11.4 KB
Newer Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0052)http://members.aol.com/acockburn/papers/AltIntro.htm -->
<HTML><HEAD><TITLE>Use Case Alternate Intro</TITLE>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 6.00.2900.2995" name=GENERATOR>
<META content="C:\PROGRAM FILES\MICROSOFT OFFICE\OFFICE\html.dot" 
name=Template></HEAD>
<BODY vLink=#800080 link=#0000ff>
<P><A href="http://members.aol.com/acockburn">Alistair Cockburn </A>Humans and 
Technology, 7691 Dell Rd, Salt Lake City, UT 84121 email: <A 
href="mailto:arc@acm.org">mailto:arc@acm.org</A></P>
<H1>Use Case Fundamentals</H1>
<P>This Use Case Fundamentals mini-document was written by someone who had read the 
article <A 
href="http://members.aol.com/acockburn/papers/usecases.htm">"Structuring Use 
Cases with Goals"</A>, and wrote a digest of it. It provides the following information.</P>
<UL>
  <LI>A brief description of Use Cases, Actors and how they are used in the 
  development process. 
  <LI>A section on the Use Case methodology used along with a description of the 
  terms used. 
  <LI>A detailed description of the Use Case Reports generated during the Use 
  Case analysis of the proposed system. 
  <LI>A brief description of how to validate these Use Cases.</LI></UL>
<H2>What are Actors and Use Cases?</H2>
<P>Actors are basically users of the system. They are actually user types or 
categories. Actors are external entities (people or other systems) who interact 
with the system to achieve a desired goal.</P>
<P>Use Cases are what happens when actors interact with the system. An actor 
uses the system to achieve a desired goal. By recording all the ways our system 
is used ("cases of use" or Use Cases) we accumulate all the goals or 
requirements of our system.</P>
<P>Therefore: A use case is a collection of possible sequences of interactions 
between the system under discussion and its Users (or Actors), relating to a 
particular goal. The collection of Use Cases should define all system behavior 
relevant to the actors to assure them that their goals will be carried out 
properly. Any system behavior that is irrelevant to the actors should not be 
included in the use cases.</P>
<P>There are many methods of defining how to pick or create a use case. The use 
cases in this report are generated using a goal oriented Structuring Methodology 
presented by Alistair Cockburn of Humans and Technology. Examining all the 
Actor's goals that the system satisfies yields the functional requirements. 
Goals summarize system function in understandable verifiable terms of use that 
users, executives and developers can appreciate and leave little open to 
interpretation.</P>
<P>Use Cases:</P>
<UL>
  <LI>Hold Functional Requirements in a easy to read, easy to track text format. 

  <LI>Represents the goal of an interaction between an actor and the system. The 
  goal represents a meaningful and measurable objective for the actor. 
  <LI>Records a set of paths (scenarios) that traverse an actor from a trigger 
  event (start of the use case) to the goal (success scenarios). 
  <LI>Records a set of scenarios that traverse an actor from a trigger event 
  toward a goal but fall short of the goal (failure scenarios). 
  <LI>Are multi-level, one use case can use/extent the functionality of another. 
  </LI></UL>
<P>&nbsp;Use Cases Do Not...</P>
<UL>
  <LI>Specify user interface design. They specify the intent, not the action 
  Detail 
  <LI>Specify implementation detail (unless it is of particular importance to 
  the actor to be assured that the goal is properly met)</LI></UL>
<P>&nbsp;Use Cases are used during many stages of software development.</P>
<UL>
  <LI>To Capture the Requirements of the systems. 
  <LI>To act as a spring board for the software design. 
  <LI>To validate the software design against. 
  <LI>For Software Test and Quality Assurance. (Tests are performed to validate 
  proper and complete implementation of the use cases) 
  <LI>Potentially as an initial framework for the on line help and user 
  manual.</LI></UL>
<P>Use Case Definitions</P>
<H3>Primary Actors:</H3>
<DIR>
<DIR>
<DIR><FONT face=Arial size=2>
<P align=justify>The Actor(s) using the system to achieve a goal. The Use Case 
documents the interactions between the system and the actors to achieve the goal 
of the primary actor.</P></DIR></DIR></DIR></FONT>
<H3>Secondary Actors:</H3>
<DIR>
<DIR>
<DIR><FONT face=Arial size=2>
<P align=justify>Actors that the system needs assistance from to achieve the 
primary actors goal.</P></DIR></DIR></DIR></FONT>
<H3>Use Case:</H3>
<DIR>
<DIR>
<DIR><FONT face=Arial size=2>
<P align=justify>A collection of possible scenarios between the system under 
discussion and external actors, characterized by the goal the primary actor has 
toward the system's declared responsibilities, showing how the primary actor's 
goal might be delivered or might fail.</P>
<P align=justify>Use cases are goals (use cases and goals are used 
interchangeably) that are made up of scenarios. Scenarios consist of a sequence 
of steps to achieve the goal, each step in a scenario is a sub (or mini) goal of 
the use case. As such each sub goal represents either another use case 
(subordinate use case) or an autonomous action that is at the lowest level 
desired by our use case decomposition. </P>
<P align=justify>This hierarchical relationship is needed to properly model the 
requirements of a system being developed. A complete use case analysis requires 
several levels. In addition the level at which the use case is operating at it 
is important to understand the scope it is addressing. The level and scope are 
important to assure that the language and granularity of scenario steps remain 
consistent within the use case. </P>
<P align=justify>There are two scopes that use cases are written from: Strategic 
and System. There are also three levels: Summary, User and 
Sub-function.</P></FONT>
<P>&nbsp;</P></DIR></DIR></DIR>
<H2>Scopes: Strategic and System</H2>
<H3>Strategic Scope: </H3>
<DIR>
<DIR>
<DIR><FONT face=Arial size=2>
<P align=justify>The goal (Use Case) is a strategic goal with respect to the 
system. These goals are goals of value to the organization. The use case shows 
how the system is used to benefit the organization.</P>
<P align=justify>These strategic use cases will eventually use some of the same 
lower level (subordinate) use cases.</P></DIR></DIR></DIR></FONT>
<H3>System Scope:</H3>
<DIR>
<DIR>
<DIR><FONT face=Arial size=2>
<P align=justify>Use cases at system scope are bounded by the system under 
development. The goals represent specific functionality required of the system. 
The majority of the use cases are at system scope. These use cases are often 
steps in strategic level use cases</P></DIR></DIR></DIR></FONT>
<H2>Levels: Summary Goal , User Goal and Sub-function.</H2>
<H3>Sub-function Level Use Case: </H3>
<DIR>
<DIR>
<DIR><FONT face=Arial size=2>
<P align=justify>A sub goal or step is below the main level of interest to the 
user. Examples are "logging in" and "locate a device in a DB". Always at System 
Scope.</P></DIR></DIR></DIR></FONT>
<H3>User Level Use Case: </H3>
<DIR>
<DIR>
<DIR><FONT face=Arial size=2>
<P align=justify>This is the level of greatest interest. It represents a user 
task or elementary business process. A user level goal addresses the question 
"Does your job performance depend on how many of these you do in a day". For 
example "Create Site View" or "Create New Device" would be user level goals but 
"Log In to System" would not. Always at System 
Scope.</P></DIR></DIR></DIR></FONT>
<H3>Summary Level Use Case:</H3>
<DIR>
<DIR>
<DIR><FONT face=Arial size=2>
<P align=justify>Written for either strategic or system scope. They represent 
collections of User Level Goals. For example summary goal "Configure Data Base" 
might include as a step, user level goal "Add Device to database". Either at 
System of Strategic Scope.</P></FONT><FONT face=Arial>
<P>&nbsp;</P></DIR></DIR></DIR></FONT>
<H2>The Use Case Forms</H2>
<P>Use Case Header: The forms contain a use case header that describes the use 
case using the following fields:</P>
<UL>
  <LI>Name: the name of the use case 
  <LI>Goal: the goal of the use case in context of the scope and level 
  <LI>Scope: the scope that the use case is covering 
  <LI>Level: the level that the use case is written to 
  <LI>Preconditions: any prerequisites before the use case can be started 
  <LI>Success Condition: what is considered a successful end to the use case 
  <LI>Failure Condition: what is considered a failed end to the use case 
  <LI>Trigger: what external event happens that triggers the start of the use 
  case 
  <LI>Notes: Misc. notes regarding performance issues, frequency of use and 
  other issues.</LI></UL>
<P>Following the Use Case Header is the collection of scenarios. </P>
<H3>Scenario Header:</H3>
<P>For Each Scenario in the Use Case the Scenario header lists the Scenario 
Name. Each scenario presents its list of steps. </P><FONT face=Arial size=2>
<P align=justify>&nbsp;</P></FONT>
<H3>Steps Section:</H3>
<P>The Steps section of the report is defined by the following fields:</P>
<UL>
  <LI>Description: Description of the step usually written in a narrative form. 
  <LI>Variation: Any variations to the step that don't substantially change the 
  nature of the goal but are required for completeness. 
  <LI>Notes: Misc. notes regarding performance issues, frequency of use and 
  other issues 
  <LI>Use Case: Since steps are essentially sub goals, if they requires more 
  detailed elaboration a Use Case will be generated to detail (or satisfy) the 
  step. This indicates which Use Case satisfies the step.</LI></UL>
<P>Each Step is assumed to be successful, if there is a significant failure 
condition for the step that will prohibit the continued success of the scenario 
then the step may contain and exception. The exception either ends the use case 
in failure or details the steps required to recover. </P>
<H3>Exception Header:</H3>
<P>The exception header can be present for each step and has two fields:</P>
<UL>
  <LI>Name: Describes the nature of the exception 
  <LI>Return Step: Indicates for recovery cases which step in the scenario to 
  return to.</LI></UL>
<P>&nbsp;</P>
<DIR>
<DIR>
<DIR><FONT face=Arial size=2>
<P align=justify>The exception section then details each step required to 
recover.</P></DIR></DIR></DIR></FONT>
<H2>Validating Use Cases</H2>
<P>As stated before, Use Cases are used during many stages of software 
development.</P>
<UL>
  <LI>To Capture the Requirements of the systems. 
  <LI>To act as a spring board for the software design. 
  <LI>To validate the software design against. 
  <LI>For Software Test and Quality Assurance. (Tests are performed to validate 
  proper and complete implementation of the use cases) 
  <LI>Potentially as an initial framework for the on line help and user 
  manual.</LI></UL>
<P>&nbsp;Needless to say, it is very important that the Use Cases are validated 
thoroughly. As you are reading these use cases, ask the following 
questions...</P>
<UL>
  <LI>Is the Use Case complete? Are there any details that need to be added? 
  <LI>Do I feel confident that the actor's goal is going to be properly met? 
  <LI>Are there any procedural or requirement changes I can suggest that would 
  simplify the process depicted in the Use Case.? 
  <LI>Are there any additional Goals of the Actors that are not addressed? 
  <LI>Are there any additional Actors that are not represented (directly or 
  indirectly)?</LI></UL>
<P>End of document</P></BODY></HTML>