blob: 74acd282ccd6cdac08b1f49a4816521664b580bc [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore"
xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf"
epf:version="1.5.0" xmi:id="-BQLZ5GRUNrMdU6XeZAfe9Q"
name="use_case,_KudM0NcJEdqz_d2XWoVt6Q" guid="-BQLZ5GRUNrMdU6XeZAfe9Q" changeDate="2008-09-03T17:28:03.131-0700"
version="7.2.0">
<mainDescription>&lt;h3>&#xD;
Overview&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
A use case describes the interactions between one of more&amp;nbsp;&lt;a class=&quot;elementLink&quot; href=&quot;./../../../core.tech.common.extend_supp/guidances/concepts/actor_411726C.html&quot; guid=&quot;_zGqO0MDpEduTGJ8i4u8TMw&quot;>Actor&lt;/a>s and the system in order to provide an observable result of value for the&#xD;
initiating actor.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
The functionality of a system is defined by different use cases, each of which represents a specific goal (to obtain&#xD;
the observable result of value) for a particular actor.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
In an automated teller machine shown in Figure 1, the Bank Customer can withdraw cash from an account, transfer funds&#xD;
between accounts, or deposit funds to an account. These correspond to specific goals that the actor has in using the&#xD;
system.&amp;nbsp;&#xD;
&lt;/p>&lt;br />&#xD;
&lt;p>&#xD;
&lt;img height=&quot;321&quot; alt=&quot;Figure 1: ATM Use-Case Example&quot; src=&quot;resources/fig1_atm_ex.gif&quot; width=&quot;456&quot; />&#xD;
&lt;/p>&#xD;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
&lt;p>&#xD;
Figure 1: ATM Use-Case Example&#xD;
&lt;/p>&#xD;
&lt;/blockquote>&#xD;
&lt;/blockquote>&#xD;
&lt;p>&#xD;
Each use case is associated with a goal of one of the actors. The collection of use cases constitutes all the possible&#xD;
ways of using the system. You should be able to determine the goal of a use case simply by observing its name.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
A use case describes the interactions between the actor(s) and the system in the form of a dialog between the actor(s)&#xD;
and the system, structured as follows:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
&lt;li>&#xD;
The actor &amp;lt;&amp;lt;does something&amp;gt;&amp;gt;&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
The system &amp;lt;&amp;lt;does something in response&amp;gt;&amp;gt;&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
The actor &amp;lt;&amp;lt;does something else&amp;gt;&amp;gt;&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
The system ...&#xD;
&lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;p>&#xD;
Each dialog of this form is called a &quot;Flow of Events&quot;.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
Because there are many flows of events possible for achieving the goal (for example, the flow may differ depending upon&#xD;
specific input from the actor), and there are situations in which the goal cannot be achieved (for example, a required&#xD;
network connection is currently unavailable), each use case will contain several flows, including one &quot;Basic Flow of&#xD;
Events&quot; and several &quot;Alternative Flows&quot;.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
The Basic Flow of Events specifies the interactions between the actor(s) and the system for the ideal case, where&#xD;
everything goes as planned, and the actor's goal (the observable result of value) is met. The basic flow represents the&#xD;
main capability provided by the system for this use case.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
As the name implies, Alternative Flows specify alternative interactions associated with the same goal.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
Closely related to use cases is the concept of a scenario. A scenario is a &lt;em>&lt;strong>specific&lt;/strong>&lt;/em> flow of&#xD;
events, for a &lt;em>&lt;strong>specific&lt;/strong>&lt;/em> set of inputs to the system, states of the system, and states of the&#xD;
system's environment. Scenarios are closely related to test cases.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
Properties of Use Cases&#xD;
&lt;/h3>&#xD;
&lt;h4>&#xD;
&lt;a id=&quot;Name&quot; name=&quot;Name&quot;>Name&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
Each use case should have a name that indicates what is achieved by its interaction with the actors. The name may have&#xD;
to be several words to be understood. Note: No two use cases can have the same name.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
&lt;a id=&quot;Brief Description&quot; name=&quot;Brief Description&quot;>Brief Description&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
The brief description of the use case should reflect its purpose.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
Flow of Events&#xD;
&lt;/h4>&#xD;
&lt;h5>&#xD;
&lt;a id=&quot;Flow of Events - Contents&quot; name=&quot;Flow of Events - Contents&quot;>Flow of Events - Contents&lt;/a>&#xD;
&lt;/h5>&#xD;
&lt;p>&#xD;
The flow of events should describe the use case's flow of events clearly enough for an outsider to easily understand.&#xD;
Remember, the flow of events should represent &lt;em>what&lt;/em> the system does, not &lt;em>how&lt;/em> the system is design to&#xD;
perform the required behavior.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
Follow these guidelines for the contents of the flow of events:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
&lt;li>&#xD;
Describe how the use case starts and ends.&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
Describe what data is exchanged between the actor and the use case.&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
Do not describe the details of the user interface, unless it is necessary to understand the behavior of the&#xD;
system.&amp;nbsp;Specifying user interface details too early will limit design options.&amp;nbsp;&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
Describe the flow of events, not only the functionality. To enforce this, start every action with &quot;When the actor&#xD;
... &quot;.&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
Describe only the events that belong to the use case, and not what happens in other use cases or outside of the&#xD;
system.&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
Avoid vague terminology.&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
Detail the flow of events. Specify what happens when, for each action. Remember this text will be used to identify&#xD;
test cases.&#xD;
&lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
If you have used certain terms in other use cases, be sure to use the exact same terms in this use case, and&#xD;
that&amp;nbsp;the meaning of the terms is consistent. To manage common terms, put them in a glossary.&#xD;
&lt;/p>&#xD;
&lt;h5>&#xD;
&lt;a id=&quot;Flow of Events - Structure&quot; name=&quot;Flow of Events - Structure&quot;>Flow of Events - Structure&lt;/a>&#xD;
&lt;/h5>&#xD;
&lt;p>&#xD;
The two main parts of the flow of events are &lt;b>basic flow of events&lt;/b> and &lt;b>alternative flows of events&lt;/b>. The&#xD;
basic flow of events should cover what &quot;normally&quot; happens when the use case is performed. The alternative flows of&#xD;
events cover behavior of optional or exceptional character in relation to the normal behavior, and also variations of&#xD;
the normal behavior. You can think of the alternative flows of events as detours from the basic flow of events, some of&#xD;
which will return to the basic flow of events and some of which will end the execution of the use case.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
The straight arrow in Figure 2 represents the basic flow of events, and the curves represent alternative paths in&#xD;
relation to the normal. Some alternative paths return to the basic flow of events, whereas others end the use case.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
&lt;img height=&quot;212&quot; alt=&quot;Diagram described in caption.&quot; src=&quot;./resources/ucstrct.gif&quot; width=&quot;231&quot; />&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
Figure 2: Typical structure of a use case flow of events&#xD;
&lt;/p>&#xD;
&lt;p class=&quot;picturetext&quot;>&#xD;
Both the basic and alternative flows should be further structured into steps or sub-flows. In doing this, your main&#xD;
goal should be readability of the text. A&amp;nbsp;guideline is that a sub-flow should be a segment of behavior within the&#xD;
use case that has a clear purpose, and is &quot;atomic&quot; in the sense that you do either all or none of the actions&#xD;
described.&#xD;
&lt;/p>&#xD;
&lt;h4 class=&quot;picturetext&quot;>&#xD;
&lt;a id=&quot;Special Requirements&quot; name=&quot;Special Requirements&quot;>Special Requirements&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
In the Special Requirements of a use case, you describe all the requirements associated with&amp;nbsp;the use case that are&#xD;
not covered by the flow of events. These are non-functional requirements that will influence the design. See also the&#xD;
discussion on non-functional requirements in &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../core.tech.common.extend_supp/guidances/concepts/requirements_8006414F.html&quot; guid=&quot;_0Wh-sMlgEdmt3adZL5Dmdw&quot;>Concept: Requirements&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
&lt;a id=&quot;preconditions and Postconditions&quot; name=&quot;preconditions and Postconditions&quot;>Preconditions and Post-conditions&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
A &lt;strong>precondition&lt;/strong> is the state of the system and its&amp;nbsp;environment that is required before the use&#xD;
case can be started.&amp;nbsp;Post-Conditions are&amp;nbsp;the states the system can be in after the use case has ended. It can&#xD;
be&amp;nbsp;helpful to use the&amp;nbsp;concepts of &lt;b>precondition&lt;/b> and &lt;b>post-condition&lt;/b> to clarify how the flow of&#xD;
events starts and ends. However, only use them only if the audience for the description of the use case agrees that it&#xD;
is helpful. Figure 3 shows an example.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
&lt;img height=&quot;278&quot; alt=&quot;Diagram described in caption.&quot; src=&quot;./resources/ucprepst.gif&quot; width=&quot;344&quot; />&#xD;
&lt;/p>&lt;br class=&quot;picturetext&quot; />&#xD;
&lt;br />&#xD;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
&lt;p>&#xD;
Figure 3: Illustration of preconditions and resulting post-conditions&#xD;
&lt;/p>&#xD;
&lt;/blockquote>&#xD;
&lt;/blockquote>&#xD;
&lt;/blockquote>&#xD;
&lt;p class=&quot;exampleheading&quot; dir=&quot;ltr&quot;>&#xD;
Examples&#xD;
&lt;/p>&#xD;
&lt;p class=&quot;example&quot; dir=&quot;ltr&quot;>&#xD;
&lt;strong>A precondition for the use case Cash Withdrawal in the ATM machine:&lt;/strong> The customer has a personally&#xD;
issued card that fits in the card reader, has been issued a PIN number, and is registered with the banking system.&#xD;
&lt;/p>&#xD;
&lt;p class=&quot;example&quot; dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
&lt;strong>A post-condition for the use case Cash Withdrawal in the ATM machine:&lt;/strong> At the end of the use case, all&#xD;
account and transaction logs are balanced, communication with the banking system is reinitialized and the card is&#xD;
returned to the customer.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>