<?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="-78ko4CuOJERKJF9ZvwMUBQ" name="detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q" guid="-78ko4CuOJERKJF9ZvwMUBQ" changeDate="2009-03-27T04:04:37.000-0700" version="1.0.0">
  <mainDescription>&lt;h4>&#xD;
    Most efficient way to write use cases&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Because use cases model requirements, they are highly dynamic by nature. The more we examine a requirement, the more we&#xD;
    learn, and the more things change. To further complicate the issue, changes to one use case can lead to changes in&#xD;
    others. Therefore, we want a flexible, highly efficient method for writing use cases that eliminates unnecessary work&#xD;
    and rewriting.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    An iterative, breadth-first approach, in which the use case is continuously evaluated before adding detail, is an&#xD;
    effective way to write use cases. This breadth-first approach involves two aspects: writing the set of use cases and&#xD;
    writing individual use cases.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;strong>Writing sets of use cases:&lt;/strong> Use cases exist in sets, and the relationships between the various use&#xD;
    cases and Actors&amp;nbsp;are important. As you learn more about the Actors, you also learn more about the system's&#xD;
    boundaries and transactions. Likewise, as you learn more about the system's transactions, you learn more about its&#xD;
    Actors. Therefore, it is more efficient to write several use cases simultaneously than to write them sequentially. This&#xD;
    way, you can identify and understand the effects of the various use cases upon each other as you write them, rather&#xD;
    than as afterthoughts that require rewriting or elimination of previous work.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;strong>Writing individual use cases.&lt;/strong> Similarly, it makes sense to write each individual use case iteratively.&#xD;
    Starting with the main scenario, you can then identify various alternative and error flows that the use case might&#xD;
    follow, then evaluate, rearrange or eliminate them, and then add the details of the surviving scenarios.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Consider factors that can influence the format and level of detail for your use case description.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Detail the flow of events of the main scenario&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    As a starting point, use the step-by-step description of the use-case main scenario. Then, gradually add details to&#xD;
    this scenario, describing &lt;strong>what&lt;/strong> the use case does, &lt;strong>not how&lt;/strong> to solve problems internal&#xD;
    to the system.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A flow of events description explores:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        How and when the use case starts&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        When the use case interacts with the Actors, and what data they exchange&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        When the use case uses data stored in the system or stores data in the system&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        How and when the use case ends&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    It does not describe:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        The GUI&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Technical details of hardware or software&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Design issues&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Identify alternate flows&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    A use case consists of a number of scenarios, each representing specific instances of the use case that correspond to&#xD;
    specific inputs from the Actor or to specific conditions in the environment. Each scenario describes alternate ways&#xD;
    that the system provides a behavior, or it can describe failure or exception cases.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    As you detail the main scenario, identify alternate flows by asking these questions:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Are there different options available, depending on input from the Actor? (for example, if the Actor enters an&#xD;
        invalid PIN number while accessing an ATM)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        What business rules can come into play? (For instance, the Actor requests more money from the ATM than is available&#xD;
        in her account)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        What could go wrong? (Such as no network connection available when required to perform a transaction)&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    It is best to develop these scenarios iteratively, as well. Begin by identifying them. Examine each possible scenario&#xD;
    to determine whether it is relevant, that it can actually happen, and that it is distinct from other scenarios.&#xD;
    Eliminate redundant or unnecessary scenarios, and then start elaborating on the more important ones.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Structure the use case&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    It is useful to structure the use case according to scenarios. This helps both to simplify communication and&#xD;
    maintenance and to permit the use cases to be implemented iteratively.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In addition to structuring the use cases according to scenarios, it is often useful to structure the scenarios&#xD;
    themselves into sub-flows. This provides an additional level of granularity for planning work and tracking progress.&#xD;
    Unless a sub-flow involves only a minor part of the complete flow of events (which can be described in the body of the&#xD;
    text), it is recommended that you describe each sub-flow in a separate section to the Flow of Events section. Sub-flows&#xD;
    that need to be in a separate section include these examples:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Sub-flows that occupy a large segment of a given flow of events.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Exceptional and alternate flows of events. This helps the use case's basic flow of events to stand out more&#xD;
        clearly.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Any sub-flow that can be executed at several intervals in the same flow of events.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Describe special requirements&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    You must also capture any requirements that are related to the use case, but are not taken into consideration in the&#xD;
    flow of events of the use case. Such requirements are likely to be nonfunctional.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Typically, nonfunctional requirements that refer to a specific use case are captured in the special requirements&#xD;
    section of the use case.&amp;nbsp;If there are nonfunctional requirements that apply to more than one use case, capture&#xD;
    these in the system-wide requirements specification.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Describe preconditions and postconditions&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    A &lt;strong>precondition&lt;/strong> on a use case explains the state that the system must be in for the use case to be able&#xD;
    to start. Be careful in describing the system state. Avoid describing the detail of other, incidental activities that&#xD;
    might already have taken place.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A &lt;strong>postcondition&lt;/strong> on a use case lists possible states that the system can be in at the end of the use&#xD;
    case execution. The system must be in one of those states. A postcondition also states actions that the system performs&#xD;
    at the end of the use case, regardless of what occurred in the use case. Post-Conditions can be categorized as Minimal&#xD;
    Guarantees&amp;nbsp;or Success Guarantees.&amp;nbsp; A Minimal Guarantee represents a condition that will be true when the use&#xD;
    case ends, regardless of how it terminates.&amp;nbsp; A Success Guarantee represents a condition that will be true when the&#xD;
    use case ends successfully, regardless of which path it took.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Neither preconditions nor postconditions need to be used to create a sequence of use cases. As a general rule, there&#xD;
    must never be a case where you have to first perform one use case and then another to have a meaningful flow of events.&#xD;
    If that is the case, correct the problem by reviewing the use cases.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
