<?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="-78ko4CuOJERKJF9ZvwMUBQ"
    name="detail_ucs_and_scenarios,_4BJ_YCxSEdqjsdw1QLH_6Q" guid="-78ko4CuOJERKJF9ZvwMUBQ"
    changeDate="2007-07-18T12:11:58.614-0700" version="1.0.0">
  <mainDescription>&lt;h3>&#xD;
    Most efficient way to write use cases&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Because use cases model requirements, they are highly dynamic by nature. The more we examine a scenario, 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 maximizes stakeholder value&#xD;
    and minimizes risk early in the project and minimizes costly rework later.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    An iterative, breadth-before-depth approach is best. This breadth-first approach involves two aspects: finding and&#xD;
    outlining use cases and detailing individual use cases.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Finding and outlining use cases&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Use cases exist in sets, and the relationships between the various use cases and Actors are important. As you learn&#xD;
    more about the Actors, you also learn more about the system's boundaries and transactions. Likewise, as you learn more&#xD;
    about the system's transactions, you learn more about its Actors. Therefore, it is more efficient to capture and&#xD;
    outline the primary use cases before detailing individual use cases. This way, you can identify and understand the&#xD;
    importance and risk associated with each use case before committing time to detailing them.&amp;nbsp; This aspect of the&#xD;
    breadth-before-depth approach is embodied in the process by the explicit separation of two tasks &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/tasks/find_and_outline_requirements_90D272B9.html&quot; guid=&quot;_P9cMUPV_EdmdHa9MmVPgqQ&quot;>Find and Outline Requirements&lt;/a>&amp;nbsp;and &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/tasks/detail_requirements_9747F71E.html&quot; guid=&quot;_0e1mIMlgEdmt3adZL5Dmdw&quot;>Detail Requirements&lt;/a>.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Detailing individual use cases&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Similarly, it makes sense to write each individual use case iteratively. Start by detailing the main scenario.&amp;nbsp; As&#xD;
    you do this, you can identify various alternative and error flows that the use case might follow, and then evaluate,&#xD;
    rearrange, or eliminate them and prioritize them before detailing the surviving scenarios, so you can focus your effort&#xD;
    in the right place.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The level of detail that you capture depends on several factors. 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> for guidance on selecting the correct format for your use cases.&#xD;
&lt;/p>&#xD;
&lt;h5>&#xD;
    Detail the basic flow of events (main scenario)&#xD;
&lt;/h5>&#xD;
&lt;p>&#xD;
    As a starting point, use the step-by-step description of the main scenario that you created during &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/tasks/find_and_outline_requirements_90D272B9.html&quot; guid=&quot;_P9cMUPV_EdmdHa9MmVPgqQ&quot;>Task: Find and Outline Requirements&lt;/a>. Then, gradually add details to this scenario,&#xD;
    describing &lt;strong>what&lt;/strong> the use case does, &lt;strong>not how&lt;/strong> to solve problems internal to the system.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A flow of events description covers:&#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;p>&#xD;
    Describe the flow of events for the main scenario in the form:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        The use case starts when &amp;lt;Actor name&amp;gt; &amp;lt;does something&amp;gt;.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The system &amp;lt;does something in response&amp;gt;.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The &amp;lt;Actor name&amp;gt; does something else.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;p>&#xD;
    See Section 4 of&amp;nbsp;&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> for a sample completed basic flow.&#xD;
&lt;/p>&#xD;
&lt;h5>&#xD;
    Detail alternate flows&#xD;
&lt;/h5>&#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 behaves, or it may describe failure or exception cases.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Review the list of alternative flows that you captured during &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/tasks/find_and_outline_requirements_90D272B9.html&quot; guid=&quot;_P9cMUPV_EdmdHa9MmVPgqQ&quot;>Task: Find and Outline Requirements&lt;/a>. As you detail the main scenario, you may identify additional alternate flows by asking these&#xD;
    questions:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Are there different options available, depending on input from the Actor? (Example: If the Actor enters an invalid&#xD;
        PIN number while accessing an ATM.)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        What business rules may come into play? (Example: The Actor requests more money from the ATM than is available in&#xD;
        her account.)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        What could go wrong? (Example: 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.&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        Begin by identifying them.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Examine each possible scenario to determine whether it is relevant, that it can actually happen, and that it is&#xD;
        distinct from other scenarios.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Eliminate redundant or unnecessary scenarios.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Prioritize the remaining scenarios and start detailing the more important ones.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;p>&#xD;
    In addition to the detailing the flow of events of each alternative flow in the form described above, each alternative&#xD;
    flow should describe:&#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;
    See Section 5 of&amp;nbsp;&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> for examples of completed alternative flows.&#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. Name and describe each key scenario so that&#xD;
    these may be prioritized, assigned to an iteration and an individual, and referenced from the&amp;nbsp;&lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/workproducts/work_items_list_39D03CC8.html&quot; guid=&quot;_rGNWsCbSEdqh1LYUOGRh2A&quot;>Work Items List&lt;/a> for implementation.&#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 subflows. This provides an additional level of granularity for planning work and tracking progress.&#xD;
    Unless a subflow involves only a minor part of the complete flow of events (which can be described in the body of the&#xD;
    text), describe each subflow in a separate section of the Flow of Events section. Subflows that should be in a separate&#xD;
    section include these examples:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Subflows that occupy a large segment of a given flow of events.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Exceptional and alternative 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 subflow that can be run at several intervals in the same flow of events.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    If there are subflows identified that are common to multiple use cases, you can re-factor your use-case model to&#xD;
    include these. See&amp;nbsp;&lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/concepts/use_case_model_CD178AF9.html&quot; guid=&quot;_2jyfUAhVEduRe8TeoBmuGg&quot;>Concept: Use-Case Model&lt;/a> for more information on the &amp;lt;&amp;lt;include&amp;gt;&amp;gt;&#xD;
    dependency.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    For more information on structuring the use case, see the &quot;Flow of Events - Structure&quot; section&amp;nbsp;in &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/concepts/use_case_BB199D1B.html&quot; guid=&quot;_KudM0NcJEdqz_d2XWoVt6Q&quot;>Concept: Use Case&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The&amp;nbsp;&lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/templates/uc_specification_E97E98B0.html&quot; guid=&quot;_0cpNwMlgEdmt3adZL5Dmdw&quot;>Template: Use-Case Specification&lt;/a> provides a suggested structure for the use case&#xD;
    specification. See&amp;nbsp;&lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/examples/uc_model_evolve_960F136B.html&quot; guid=&quot;_t4QdAMNqEdu2IdAIaWZyAw&quot;>Example: Evolution of the Use-Case Model&lt;/a> and&amp;nbsp;&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> for examples of structuring the use-case model and use case specifications, respectively.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Detail special requirements&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Be sure to 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.&amp;nbsp;These requirements include business rules, design constraints, usability&#xD;
    requirements, performance requirements, reliability requirements, supportability requirements, and interface&#xD;
    requirements. These requirements all influence the implementation and associated cost as much as the flow of events.&#xD;
    Therefore, they must be agreed upon and prioritized.&#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. For more information, see the &quot;Special Requirements&quot; section in &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/concepts/use_case_BB199D1B.html&quot; guid=&quot;_KudM0NcJEdqz_d2XWoVt6Q&quot;>Concept: Use Case&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If there are nonfunctional requirements that apply to more than one use case, capture these in the &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/workproducts/supporting_requirements_spec_7D9DD47C.html&quot; guid=&quot;_BVh9cL-CEdqb7N6KIeDL8Q&quot;>Artifact: Supporting Requirements Specification&lt;/a>. For more information on supporting&#xD;
    requirements, see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/concepts/supporting_requirements_B2C4D610.html&quot; guid=&quot;_VXZ5wO0IEdqHTdbLTmC5IQ&quot;>Concept: Supporting Requirements&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    For guidance in writing clear, concise, unambiguous special and supporting requirements, see&amp;nbsp;guidelines &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/guidances/guidelines/writing_good_requirements_48248536.html&quot; guid=&quot;_6jXzYNcKEdqz_d2XWoVt6Q&quot;>Writing Good Requirements&lt;/a>&amp;nbsp;and &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/guidances/guidelines/requirement_pitfalls_14EE9652.html&quot; guid=&quot;_1AOsMO0JEdqHTdbLTmC5IQ&quot;>Requirement Pitfalls&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    See Section 8 of&amp;nbsp;&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> for examples of special requirements.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Describe preconditions and post-conditions&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    A &lt;strong>precondition&lt;/strong> of 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;
    may already have taken place.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A &lt;strong>post-condition&lt;/strong> of a use case lists possible states that the system can be in after the use case&#xD;
    runs. The system must be in one of those states. A post-condition also states actions that the system performs at the&#xD;
    end of the use case, regardless of what occurred in the use case. Post-conditions may be categorized as Minimal&#xD;
    Guarantees&amp;nbsp;or Success Guarantees:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Minimal Guarantees&lt;/b> represent conditions that will be true when the use cases end, regardless of how they&#xD;
        terminate.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Success Guarantees&lt;/b> represent condition that will be true when the use cases end successfully, regardless of&#xD;
        which paths they took.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Consider the following when specifying preconditions and post-condition:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        The states described by pre- or post-conditions should be states that the user can observe. &quot;The user has logged on&#xD;
        to the system&quot; or &quot;The user has opened the document&quot; are examples of observable states.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        A precondition is a constraint on when a use case can start. It is not the event that starts the use case.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        A precondition for a use case is not a precondition for only one subflow, although you can define preconditions and&#xD;
        post-conditions at the subflow level.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        A post-condition for a use case should be true regardless of which alternative flows were executed; it should not&#xD;
        be true only for the main flow. If something could fail, you would cover that in the post-condition by saying &quot;The&#xD;
        action has completed,&quot; or if something failed, &quot;The action was not performed,&quot; rather than just &quot;The action is&#xD;
        completed.&quot;&amp;nbsp;&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    For more information, see the &quot;Preconditions Post-conditions&quot; section in &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/concepts/use_case_BB199D1B.html&quot; guid=&quot;_KudM0NcJEdqz_d2XWoVt6Q&quot;>Concept: Use Case&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    See Section 7 of&amp;nbsp;&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> for example pre- and post-conditions.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>