| <?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.4/uma.ecore" |
| xmlns:rmc="http://www.ibm.com/rmc" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.2.0" xmi:id="-BQLZ5GRUNrMdU6XeZAfe9Q" |
| name="use_case,_KudM0NcJEdqz_d2XWoVt6Q" guid="-BQLZ5GRUNrMdU6XeZAfe9Q" changeDate="2007-03-30T13:15:40.660-0700" |
| version="1.0.0"> |
| <mainDescription><h3>
 |
| Explanation
 |
| </h3>
 |
| <p>
 |
| A use case describes the interactions between one of more&nbsp;<a class="elementLink" href="./../../../openup/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 class="picturecenter" align="center">
 |
| &nbsp;<img height="321" alt="Figure 1: ATM use case example" src="./resources/im_uc.gif" width="456" />
 |
| </p>
 |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
 |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
 |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
 |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
 |
| <p class="picturetext">
 |
| Figure 1: ATM use case example.
 |
| </p>
 |
| </blockquote>
 |
| </blockquote>
 |
| </blockquote>
 |
| </blockquote>
 |
| <p>
 |
| In an automated teller machine illustrated 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.
 |
| </p>
 |
| <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 of the form:
 |
| </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…<br />
 |
| </li>
 |
| </ol>
 |
| <p>
 |
| Each dialog of this form is called a “Flow of Events”.
 |
| </p>
 |
| <p>
 |
| Since 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.&nbsp; 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.&nbsp; A scenario is a <strong>specific</strong> flow of
 |
| events, for a <strong>specific</strong> set of inputs to the system, states of the system, and states of the system’s
 |
| environment.&nbsp; 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 clearly describes the main goal of the use case. The name may have to be several
 |
| words to be understood. Typically the name is a verb phrase, for example: Withdraw Cash. 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.&nbsp;
 |
| </p>
 |
| <h4>
 |
| <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><a id="Flow of Events - Contents" name="Flow of Events - Contents">Flow of
 |
| Events - Contents</a>
 |
| </h4>
 |
| <p>
 |
| The <b>flow of events</b> should describe the interactions between the actor(s) and the system clearly enough for an
 |
| outsider to easily understand. 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.
 |
| 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
 |
| ... ".&nbsp;&nbsp;
 |
| </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 <a class="elementLink" href="./../../../openup/workproducts/glossary_5D300778.html" guid="_Wn7HcNcEEdqz_d2XWoVt6Q">Glossary</a>.
 |
| </p>
 |
| <h4>
 |
| <a id="Flow of Events - Structure" name="Flow of Events - Structure">Flow of Events - Structure</a>
 |
| </h4>
 |
| <p>
 |
| The two main parts of the flow of events are <b>basic flow of events</b> and <a id="XE_flow_of_events__alternative_flow" name="XE_flow_of_events__alternative_flow"></a><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 align="center">
 |
| <img height="212" alt="Diagram described in caption." src="./resources/ucstrct.gif" width="231" />
 |
| </p>
 |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
 |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
 |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
 |
| <p class="picturetext">
 |
| Figure 2: Typical structure of a use case flow of events
 |
| </p>
 |
| </blockquote>
 |
| </blockquote>
 |
| </blockquote>
 |
| <p class="picturetext">
 |
| 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,&nbsp;others end the use
 |
| case.
 |
| </p>
 |
| <p>
 |
| To clarify where an alternative flow of events fits in the structure, you need to describe the following for each
 |
| detour to the basic flow of events:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Where the alternative flow can be inserted in the basic flow of events.
 |
| </li>
 |
| <li>
 |
| The condition that needs to be fulfilled for the alternative behavior to start.
 |
| </li>
 |
| <li>
 |
| How and where the basic flow of events is resumed, or how the use case ends.&nbsp;&nbsp;
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| It might be tempting, if the alternative flow of events is very simple, to just describe it in the basic flow of events
 |
| section (using some informal "if-then-else" construct). This should be avoided. Too many alternatives will make the
 |
| normal behavior difficult to see. Also, including alternative paths in the basic flow of events section will make the
 |
| text more pseudo-code like and harder to read.
 |
| </p>
 |
| <p>
 |
| Both the basic and alternative flows may be further structured into subflows. In doing this, your main goal should be
 |
| readability of the text. A guideline is that a subflow 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.&nbsp;
 |
| </p>
 |
| <h4>
 |
| <a id="XE_use_case__flow_of_events" name="XE_use_case__flow_of_events"></a><a id="XE_flow_of_events__guidelines_for" name="XE_flow_of_events__guidelines_for"></a><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 on the use case that are not covered by
 |
| the flow of events. These are typically non-functional requirements that will influence the design model. See also the
 |
| discussion on non-functional requirements in <a class="elementLinkWithType" href="./../../../openup/guidances/concepts/requirements_8006414F.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Concept: Requirements</a>.&nbsp;
 |
| </p>
 |
| <h4>
 |
| <a id="XE_postcondition__guidelines_for" name="XE_postcondition__guidelines_for"></a><a id="XE_precondition__guidelines_for" name="XE_precondition__guidelines_for"></a><a id="preconditions and Postconditions" name="preconditions and Postconditions">Preconditions and Post-conditions</a>
 |
| </h4>
 |
| <p>
 |
| A precondition is the state of the system and its surroundings 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 precondition and post-condition 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.
 |
| </p>
 |
| <p align="center">
 |
| <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>
 |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
 |
| <p class="exampleheading">
 |
| Examples
 |
| </p>
 |
| <p class="example">
 |
| <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">
 |
| <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.&nbsp;&nbsp;
 |
| </p>
 |
| </blockquote>
 |
| <h3>
 |
| Level of detail necessary in use cases
 |
| </h3>
 |
| <p>
 |
| There will often be use cases in your model that are so simple that they do not need a detailed structured description
 |
| of the use case, a step-by-step outline is quite enough. The criteria for making this decision is that you don't see
 |
| disagreement among different readers on what the use case means, and that designers and testers are comfortable with
 |
| the level of detail provided by the step-by-step format. Examples are use cases that describe simple entry or retrieval
 |
| of some data from the system.
 |
| </p>
 |
| <p>
 |
| For more information on possible formats and level of detail captured for each use case see <a class="elementLinkWithType" href="./../../../openup/guidances/guidelines/use_case_formats_FF4AE425.html" guid="_qq0GMAXkEduj_7BEUj1JfQ">Guideline: Use Case Formats</a>.
 |
| </p>
 |
| <h3>
 |
| Example <a id="The Scope of a Use Case" name="The Scope of a Use Case">Use Case</a>
 |
| </h3>
 |
| <p>
 |
| For an example of a completed use-case specification see <a class="elementLinkWithType" href="./../../../openup/guidances/examples/use_case_spec_CD5DD9B1.html" guid="_JLOiIMNvEdu2IdAIaWZyAw">Example: Use-Case Specification</a>.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
