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