<?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:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-BQLZ5GRUNrMdU6XeZAfe9Q"
    name="use_case,_KudM0NcJEdqz_d2XWoVt6Q" guid="-BQLZ5GRUNrMdU6XeZAfe9Q" changeDate="2007-03-30T12:15:40.660-0800"
    version="1.0.0">
  <mainDescription>&lt;h3>&#xD;
    Explanation&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    A use case describes the interactions between one of more &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/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&#xD;
    funds between accounts, or deposit funds to an account. These correspond to specific goals that the actor has in using&#xD;
    the system.&#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;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 class=&quot;picturetext&quot;>&#xD;
                    Figure 1: ATM use case example.&#xD;
                &lt;/p>&#xD;
            &lt;/blockquote>&#xD;
        &lt;/blockquote>&#xD;
    &lt;/blockquote>&#xD;
&lt;/blockquote>&#xD;
&#xD;
&#xD;
&lt;p class=&quot;picturecenter&quot; align=&quot;center&quot;>&#xD;
     &lt;img height=&quot;321&quot; alt=&quot;automated teller machine and actors&quot; src=&quot;./resources/im_uc.gif&quot; width=&quot;456&quot; />&#xD;
&lt;/p>&#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…&lt;br />&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;p>&#xD;
    Each dialog of this form is called a “Flow of Events”.&#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 “Basic Flow of&#xD;
    Events” and several “Alternative Flows”.&#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&#xD;
    represents the 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;b>specific&lt;/b> flow of&#xD;
    events, for a &lt;b>specific&lt;/b> set of inputs to the system, states of the system, and states of the system’s&#xD;
    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 clearly describes the main goal of the use case. The name may have to be several&#xD;
    words long to be understood. Typically the name is a verb phrase, for example: Withdraw Cash. &lt;br/>&#xD;
	&lt;b>Note:&lt;/b> No two use cases can&#xD;
    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;
    &lt;a id=&quot;XE_use_case__flow_of_events&quot; name=&quot;XE_use_case__flow_of_events&quot;>&lt;/a>&lt;a id=&quot;XE_flow_of_events__guidelines_for&quot; name=&quot;XE_flow_of_events__guidelines_for&quot;>&lt;/a>&lt;a id=&quot;Flow of Events - Contents&quot; name=&quot;Flow of Events - Contents&quot;>Flow of&#xD;
    Events -- Contents&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    The &lt;b>flow of events&lt;/b> should describe the interactions between the actor(s) and the system clearly enough for an&#xD;
    outsider to easily understand. The flow of events should represent &lt;i>what&lt;/i> the system does, not &lt;i>how&lt;/i> the&#xD;
    system is design to 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 system.&#xD;
        Specifying user interface details too early will limit design options. &#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;
        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 the meaning of the terms is consistent. To manage common terms, put them in a &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/workproducts/glossary_5D300778.html&quot; guid=&quot;_Wn7HcNcEEdqz_d2XWoVt6Q&quot;>Glossary&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;h4>&#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;/h4>&#xD;
&lt;p>&#xD;
    The two main parts of the flow of events are &lt;b>basic flow of events&lt;/b> and &lt;a id=&quot;XE_flow_of_events__alternative_flow&quot; name=&quot;XE_flow_of_events__alternative_flow&quot;>&lt;/a>&lt;b>alternative flows of&#xD;
    events&lt;/b>. The basic flow of events should cover what &quot;normally&quot; happens when the use case is performed. The&#xD;
    alternative flows of events cover behavior of optional or exceptional character in relation to the normal behavior, and&#xD;
    also variations of the normal behavior. You can think of the alternative flows of events as detours from the basic flow&#xD;
    of events, some of which will return to the basic flow of events and some of which will end the execution of the use&#xD;
    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&#xD;
    case.&#xD;
&lt;/p>&#xD;
&#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 class=&quot;picturetext&quot;>&#xD;
                Figure 2: Typical structure of a use case flow of events&#xD;
            &lt;/p>&#xD;
        &lt;/blockquote>&#xD;
    &lt;/blockquote>&#xD;
&lt;/blockquote>&#xD;
&#xD;
&#xD;
&lt;p align=&quot;center&quot;>&#xD;
    &lt;img height=&quot;212&quot; alt=&quot;Arrows representing flow of events&quot; src=&quot;./resources/ucstrct.gif&quot; width=&quot;231&quot; />&#xD;
&lt;/p>&#xD;
&#xD;
&lt;p>&#xD;
    To clarify where an alternative flow of events fits in the structure, you need to describe the following for each&#xD;
    detour to the basic flow of events:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Where the alternative flow can be inserted in the basic flow of events&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The condition that needs to be fulfilled for the alternative behavior to start&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        How and where the basic flow of events is resumed, or how the use case ends&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    It might be tempting, if the alternative flow of events is very simple, to just describe it in the basic flow of events&#xD;
    section (using some informal &quot;if-then-else&quot; construct). This should be avoided. Too many alternatives will make the&#xD;
    normal behavior difficult to see. Also, including alternative paths in the basic flow of events section will make the&#xD;
    text more pseudo-code like and harder to read.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Both the basic and alternative flows may be further structured into subflows. In doing this, your main goal should be&#xD;
    readability of the text. A guideline is that a subflow should be a segment of behavior within the use case that has a&#xD;
    clear purpose, and is &quot;atomic&quot; in the sense that you do either all or none of the actions described. &#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;XE_use_case__flow_of_events&quot; name=&quot;XE_use_case__flow_of_events&quot;>&lt;/a>&lt;a id=&quot;XE_flow_of_events__guidelines_for&quot; name=&quot;XE_flow_of_events__guidelines_for&quot;>&lt;/a>&lt;a id=&quot;Special Requirements&quot; name=&quot;Special Requirements&quot;>Special&#xD;
    Requirements&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    In the Special Requirements of a use case, you describe all the requirements on the use case that are not covered by&#xD;
    the flow of events. These are typically non-functional requirements that will influence the design model. See also the&#xD;
    discussion on non-functional requirements in &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/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;XE_postcondition__guidelines_for&quot; name=&quot;XE_postcondition__guidelines_for&quot;>&lt;/a>&lt;a id=&quot;XE_precondition__guidelines_for&quot; name=&quot;XE_precondition__guidelines_for&quot;>&lt;/a>&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 precondition is the state of the system and its surroundings that is required before the use case can be&#xD;
    started. Post-Conditions are the states the system can be in after the use case has ended. It can&#xD;
    be helpful to use the concepts of precondition and post-condition to clarify how the flow of events starts&#xD;
    and ends. However, only use them if the audience for the description of the use case agrees that it is helpful.&#xD;
	Figure 3 shows an example.&#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;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;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
&lt;p align=&quot;center&quot;>&#xD;
    &lt;img height=&quot;278&quot; alt=&quot;examples marked with circles on arrow diagram&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;p class=&quot;exampleheading&quot;>&#xD;
        Examples&#xD;
    &lt;/p>&#xD;
    &lt;p class=&quot;example&quot;>&#xD;
        &lt;b>A precondition for the use case Cash Withdrawal in the ATM machine:&lt;/b> 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;>&#xD;
        &lt;b>A post-condition for the use case Cash Withdrawal in the ATM machine:&lt;/b> At the end of the use case,&#xD;
        all account and transaction logs are balanced, communication with the banking system is reinitialized, and the card&#xD;
        is returned to the customer.  &#xD;
    &lt;/p>&#xD;
&lt;/blockquote>&#xD;
&lt;h3>&#xD;
    Level of detail necessary in use cases&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    There will often be use cases in your model that are so simple that they do not need a detailed structured description&#xD;
    of the use case (that is, a step-by-step outline is quite enough). The criteria for making this decision is that you don't see&#xD;
    disagreement among different readers on what the use case means, and that designers and testers are comfortable with&#xD;
    the level of detail provided by the step-by-step format. Examples are use cases that describe simple data entry or retrieval&#xD;
    in your system.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    For more information on possible formats and the level of detail captured for each use case see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/guidelines/use_case_formats_FF4AE425.html&quot; guid=&quot;_qq0GMAXkEduj_7BEUj1JfQ&quot;>Guideline: Use Case Formats&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Example &lt;a id=&quot;The Scope of a Use Case&quot; name=&quot;The Scope of a Use Case&quot;>Use Case&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    For an example of a completed use-case specification see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/examples/use_case_spec_CD5DD9B1.html&quot; guid=&quot;_JLOiIMNvEdu2IdAIaWZyAw&quot;>Example: Use-Case Specification&lt;/a>.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>