<?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" xmi:id="-pQrBSyxJHLLodLbS4R_Zdw" name="new_guideline,_qq0GMAXkEduj_7BEUj1JfQ" guid="-pQrBSyxJHLLodLbS4R_Zdw" changeDate="2007-05-31T20:09:37.540+0330" version="7.1.0">
  <mainDescription>&lt;h3>&#xD;
    Use Case Formats&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The level of detail required in use cases differs from project to project, and even between use cases and scenarios&#xD;
    within the same project.&amp;nbsp; A use case format that works in one situation may be totally unsuited for&#xD;
    another.&amp;nbsp;The key to maximizing efficiency and effectiveness is to capture the right amount of detail for each&#xD;
    particular use case and scenario.&amp;nbsp;(See &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#ADO04&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[ADO04]&lt;/a> for more information on use case formats.)&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Some use cases need a high degree of detail. If the writers used a template, then they filled out all or almost all of&#xD;
    its fields for each use case. High-detail use cases are best suited complex, novel, or safety-critical functionality,&#xD;
    such as that found in flight control systems, telephone switches, and so forth where the risk of misinterpretation is&#xD;
    high.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Other use cases need less detail. If the writers used a template, then they may have left many of the fields blank.&#xD;
    Low-detail use cases are best suited for well understood, low complexity or less safety-critical functionality where&#xD;
    most of the stakeholders have a strong background in the problem domain and the risk of misinterpretation is low. In&#xD;
    these cases, simple brief descriptions or step-by-step outlines suffice.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Furthermore, not all scenarios are created equally.&amp;nbsp; Within the same use case, some scenarios are very well&#xD;
    understood and a brief description is sufficient to ensure un-ambiguous interpretation.&amp;nbsp;&amp;nbsp; Other scenarios may&#xD;
    require more detail to capture the essential behavior un-ambiguously.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Finally, as explained in &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/guidelines/detail_ucs_and_scenarios_6BC56BB7.html&quot; guid=&quot;_4BJ_YCxSEdqjsdw1QLH_6Q&quot;>Guideline: Detail Use Cases and Scenarios&lt;/a>, it makes sense to write use cases&#xD;
    iteratively. Starting with the basic details, you can then identify the various alternative and error paths that the&#xD;
    use case might follow so that you can evaluate, rearrange, or eliminate them, and then elaborate or fill in the details&#xD;
    of the&amp;nbsp;remaining scenarios.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Write use cases and scenarios in one or more of the following formats, progressively, until you reach the level of&#xD;
    detail required:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;strong>Use-case model overview:&lt;/strong> A format for understanding the “big-picture”&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Use-case brief descriptions:&lt;/strong> A format for writing summary use cases&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Step-by-step outlines:&lt;/strong> A format for writing less formal, low-ceremony use cases&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Fully detailed:&lt;/strong> A format for writing more formal, high-ceremony use cases&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Use-Case Model Overview&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Create a use-case model overview, which captures actors and associated use cases.&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Start by identifying the list of actors who will use the system, and then identify at least one goal for each.&#xD;
        Actors without goals indicate that you haven’t adequately defined the system. The actor is beyond the system’s&#xD;
        scope, doesn’t belong in the system, or is part of another actor.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Likewise, leftover goals can indicate that the system is too complex and you're trying to accomplish too much, or&#xD;
        that you haven’t adequately defined all of the necessary actors. Carefully evaluate the leftovers to see if you are&#xD;
        just overlooking some detail, or whether they don’t belong in the system.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Remove unassociated actors and goals from the model.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Sometimes, this overview may provide enough information to serve as the use-case model for very small,&#xD;
    high-communicating, low-ceremony project teams. Usually, the use-case model overview is the first step of identifying&#xD;
    use cases and system boundaries.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Use-Case brief descriptions&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Write two to four sentences per use case, capturing key activities and key-extension handling.&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Expand the high priority use-cases by writing a two- to four-sentence use cases for each entry in the list.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Briefly describe each use case’s main&amp;nbsp;scenario and most important extensions.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Include enough information to eliminate ambiguity for at least the main&amp;nbsp;scenario.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Step-by-step outlines&amp;nbsp;&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Write the step-by-step outline which describes the interaction between the actor(s) and the system.&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Key scenarios are detailed to describe the interaction&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Triggering events are specified&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Information exchanged&amp;nbsp;is described&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Fully Detailed&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Complete all sections of the &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/guidances/templates/uc_specification_E97E98B0.html&quot; guid=&quot;_0cpNwMlgEdmt3adZL5Dmdw&quot;>Use-Case Specification&lt;/a>&amp;nbsp;template.&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        The main scenario is detailed&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        All alternative flows are identified and detailed&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Special requirements are complete and un-ambiguous&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Pre- and Post-conditions are specified.&#xD;
    &lt;/li>&#xD;
&lt;/ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
