<?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="_AGvpcMM3EdmSIPI87WLu3g" name="uc_model,_0VAUsMlgEdmt3adZL5Dmdw" guid="_AGvpcMM3EdmSIPI87WLu3g" changeDate="2009-03-28T10:40:44.000-0700" version="1.0.0">
  <mainDescription>&lt;h3>&#xD;
    Introduction&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The key to successful iterative development is ensuring that the development team maximizes stakeholder value and&#xD;
    minimizes risk early in the lifecycle, while minimizing re-work later.&amp;nbsp; This imposes some constraints on how we&#xD;
    develop the use-case model.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    At one extreme is the classical waterfall approach, which attempts to&amp;nbsp;detail all of the requirements prior to&#xD;
    design and implementation.&amp;nbsp; This approach delays delivery of stakeholder value and risk reduction unnecessarily.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    At the other extreme is&amp;nbsp;beginning development prior to understanding what the system must do.&amp;nbsp; This approach&#xD;
    results in significant, and costly, re-work later in the lifecycle.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A better approach is to detail only those requirements which will be the focus of development in the next iteration (or&#xD;
    two).&amp;nbsp; Selection of these requirements is driven by value and risk, and thus requires as a minimum an abstract&#xD;
    understanding of the &quot;big-picture&quot;.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The following discussion will outline the approach used to evolve the use-case model to achieve these goals.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;How the Use-Case Model Evolves&quot; name=&quot;How the Use-Case Model Evolves&quot;>How the Use-Case Model Evolves&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The recommended approach to evolving the use-case model takes a &quot;breadth before depth&quot; approach.&amp;nbsp; In this&#xD;
    approach, one identifies the actors and use cases and outlines them quickly.&amp;nbsp; Based on this knowledge, one can&#xD;
    then perform an initial assessment of risk and priorities and thus focus the effort of&amp;nbsp;detailing&amp;nbsp;the use&#xD;
    cases on the right areas.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Inception&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    The purpose of inception is to understand the scope of the system.&amp;nbsp; We need to understand the main purpose of the&#xD;
    system, what is within the scope of the system, and what is external to the system.&amp;nbsp; We must strive to list all&#xD;
    the primary actors and use cases, however we don't have the luxury of being able to detail all of these requirements at&#xD;
    this time.&amp;nbsp; Strive to&amp;nbsp;identify by name&amp;nbsp;~80% of the primary actors and use cases and provide a brief&#xD;
    description (one - three sentences) for each.&#xD;
&lt;/p>&#xD;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
    &lt;h5>&#xD;
        Identify stakeholders&#xD;
    &lt;/h5>&#xD;
    &lt;p>&#xD;
        Begin by listing all the external stakeholders for the system.&amp;nbsp; These individuals will be the source of the&#xD;
        requirements.&#xD;
    &lt;/p>&#xD;
    &lt;h5>&#xD;
        Identify Actors&#xD;
    &lt;/h5>&#xD;
    &lt;p>&#xD;
        Name and describe the primary actors.&amp;nbsp; See &lt;a class=&quot;elementLinkWithType&quot;&#xD;
        href=&quot;./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/identify_and_outline_actors_and_ucs_BB5516A9.html&quot;&#xD;
         guid=&quot;_eyL0wCu-EdqSxKAVa9kmvA&quot;>Guideline: Identify and Outline Actors and Use Cases&lt;/a>.&#xD;
    &lt;/p>&#xD;
    &lt;h5>&#xD;
        Identify Use Cases&#xD;
    &lt;/h5>&#xD;
    &lt;p>&#xD;
        For each actor, ask &quot;what does this actor want to accomplish with the system&quot;?&amp;nbsp; This will reveal the primary&#xD;
        use cases for the system.&amp;nbsp; Name and describe each of these as you discover them.&#xD;
    &lt;/p>&#xD;
    &lt;h5>&#xD;
        Update the Use-Case Model&#xD;
    &lt;/h5>&#xD;
    &lt;p>&#xD;
        Update the use case model to capture the actor and use case names and brief description.&amp;nbsp; Capture the&#xD;
        relationship between the actors and use cases.&#xD;
    &lt;/p>&#xD;
    &lt;h5>&#xD;
        Outline the Basic Flows&#xD;
    &lt;/h5>&#xD;
    &lt;p>&#xD;
        For those use cases that are considered high priority by the stakeholders, or high risk by the development team,&#xD;
        capture a step-by-step description of the Basic Flow.&amp;nbsp; Don't worry about structuring the flow at this&#xD;
        point.&amp;nbsp; Focus on capturing the dialogue between the actor and the system and the key requirements for the&#xD;
        system.&#xD;
    &lt;/p>&#xD;
    &lt;h5>&#xD;
        Identify Alternate Flows&#xD;
    &lt;/h5>&#xD;
    &lt;p>&#xD;
        As you work through the Basic Flows, ask: &quot;What can go wrong?&quot;; &quot;What options are available at this point?&quot;;&#xD;
        etc.&amp;nbsp; These types of questions will reveal alternate flows.&amp;nbsp; Capture these, giving each a name and brief&#xD;
        description.&amp;nbsp; Fight the urge to detail these alternate flows at this time.&#xD;
    &lt;/p>&#xD;
    &lt;h5>&#xD;
        Refactor the Use Case Model&#xD;
    &lt;/h5>&#xD;
    &lt;p>&#xD;
        Based on the Basic Flows you have identified, determine if there is common behavior that could be factored out into&#xD;
        &amp;lt;&amp;lt;include&amp;gt;&amp;gt; use cases.&amp;nbsp; Refactor the Use Case model accordingly.&#xD;
    &lt;/p>&#xD;
    &lt;h5>&#xD;
        Prioritize Use Cases&#xD;
    &lt;/h5>&#xD;
    &lt;p>&#xD;
        Given the abstract description you now have of the requirements, work with stakeholders to prioritize the use&#xD;
        cases.&amp;nbsp; This will be the primary input to iteration planning.&#xD;
    &lt;/p>&#xD;
&lt;/blockquote>&#xD;
&lt;h4>&#xD;
    Elaboration&#xD;
&lt;/h4>&#xD;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
    &lt;p>&#xD;
        The purpose of elaboration is to demonstrate the feasibility of&amp;nbsp;the solution prior to committing additional&#xD;
        resources.&amp;nbsp; To be successful, one must demonstrate that stakeholder value can be delivered and that the risk&#xD;
        of continuing is acceptable.&amp;nbsp; We must strive to detail and implement ~20% of the scenarios.&amp;nbsp; These&#xD;
        scenarios must be selected to achieve good coverage of the architecture (for example, a vertical slice through the&#xD;
        architecture, touching as many&amp;nbsp;components and interfaces as possible, is preferred to elaborating the GUI&#xD;
        only).&#xD;
    &lt;/p>&#xD;
    &lt;h5>&#xD;
        Detail Basic Flow&#xD;
    &lt;/h5>&#xD;
    &lt;p>&#xD;
        For those UC selected for the next iteration, spend the time to detail the basic flow now.&amp;nbsp; See &lt;a&#xD;
        class=&quot;elementLinkWithType&quot;&#xD;
        href=&quot;./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/detail_ucs_and_scenarios_6BC56BB7.html&quot;&#xD;
         guid=&quot;_4BJ_YCxSEdqjsdw1QLH_6Q&quot;>Guideline: Detail Use Cases and Scenarios&lt;/a>.&#xD;
    &lt;/p>&#xD;
    &lt;h5>&#xD;
        Detail Alternate Flow&#xD;
    &lt;/h5>&#xD;
    &lt;p>&#xD;
        For those alternate flows selected for the next iteration, spend the time to detail the flows now.&#xD;
    &lt;/p>&#xD;
    &lt;h5>&#xD;
        Update the Use-Case Model&#xD;
    &lt;/h5>&#xD;
    &lt;p>&#xD;
        Update the Use-Case Model to capture any refinements made as a result of your work.&amp;nbsp; Depending upon the&#xD;
        complexity of the system, you might want to introduce packages to group the use cases in a logical manner to&#xD;
        simplify communications, iteration planning, and parallel development.&#xD;
    &lt;/p>&#xD;
&lt;/blockquote>&#xD;
&lt;h4>&#xD;
    Construction&#xD;
&lt;/h4>&#xD;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
    &lt;p>&#xD;
        The purpose of construction is to incrementally deliver functionality (and value).&amp;nbsp; Working from the iteration&#xD;
        plan, continue detailing the remaining requirements.&amp;nbsp; Shoot for completion of ~90 - ~95% of use cases by the&#xD;
        end of construction.&#xD;
    &lt;/p>&#xD;
    &lt;h5>&#xD;
        Detail Basic Flows&#xD;
    &lt;/h5>&#xD;
    &lt;p>&#xD;
        For those UC selected for the next iteration, spend the time to detail the basic flow now.&amp;nbsp; See &lt;a&#xD;
        class=&quot;elementLinkWithType&quot;&#xD;
        href=&quot;./../../../practice.tech.use_case_driven_dev.base/guidances/guidelines/detail_ucs_and_scenarios_6BC56BB7.html&quot;&#xD;
         guid=&quot;_4BJ_YCxSEdqjsdw1QLH_6Q&quot;>Guideline: Detail Use Cases and Scenarios&lt;/a>.&#xD;
    &lt;/p>&#xD;
    &lt;h5>&#xD;
        Detail Alternate Flows&#xD;
    &lt;/h5>&#xD;
    &lt;p>&#xD;
        For those alternate flows selected for the next iteration, spend the time to detail the flows now.&#xD;
    &lt;/p>&#xD;
    &lt;h5>&#xD;
        Update the Use-Case Model&#xD;
    &lt;/h5>&#xD;
    &lt;p>&#xD;
        Update the Use-Case Model to capture any refinements made as a result of your work.&#xD;
    &lt;/p>&#xD;
&lt;/blockquote>&#xD;
&lt;h4>&#xD;
    Transition&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    The purpose of transition is to make the system operational in its intended environment.&amp;nbsp; Some requirements will&#xD;
    not be covered at this point.&amp;nbsp; But the requirements must clearly not stress the design.&amp;nbsp; The remaining ~5% to&#xD;
    ~10% of use cases must be detailed and implemented in this phase.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Avoiding Functional Decomposition&quot; name=&quot;Avoiding Functional Decomposition&quot;>Avoiding Functional&#xD;
    Decomposition&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    A common pitfall for those new to use-case models is to perform a&amp;nbsp;functional decomposition of the system. This&#xD;
    results in many small &quot;use cases&quot;, that on their own do not deliver the &quot;observable result of value&quot; to the&#xD;
    actor.&amp;nbsp; To avoid this, watch for the following symptoms:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;strong>Small&lt;/strong> use cases, meaning that the description of the flow of events is only one or a few&#xD;
        sentences.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Many&lt;/strong> use cases, meaning that the number of use cases is some multiple of a hundred, rather than a&#xD;
        multiple of ten.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Use-case names that are constructions such as &quot;do this operation on this particular data&quot; or &quot;do this function with&#xD;
        this particular data&quot;. For example, &quot;Enter Personal Identification Number in an ATM machine&quot; must not be modeled as&#xD;
        a separate use case for the ATM machine, because no one would use the system to do just this. A use case is a&#xD;
        complete flow of events that results in something of value to an actor.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    To avoid functional decomposition, make sure that the use-case model helps answer these kinds of questions:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        What is the context of the system?&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Why are you building this system?&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        What does the user want the system to do?&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        How&amp;nbsp;do the users benefit from the system?&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Structuring the Use-Case Model&quot; name=&quot;Structuring the Use-Case Model&quot;>Structuring the Use-Case Model&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    There are three main reasons for structuring the use-case model:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        To make the use cases easier to understand.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        To partition common behavior described within many use cases.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        To make the use-case model easier to maintain.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Structuring is not the first thing you do, however. There is no point in structuring the use cases until you know a bit&#xD;
    more about their behavior than a one-sentence description. Establishing a step-by-step outline of the flow of events&#xD;
    can assure your decisions are based on an accurate understanding of the behavior&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    There are several advanced modeling concepts available in the literature for&amp;nbsp;structuring the use-case model,&#xD;
    however, following the principle of &quot;keep-it-simple&quot; only the most useful of these, namely the &amp;lt;&amp;lt;include&amp;gt;&amp;gt;&#xD;
    relationship is discussed in this process.&amp;nbsp; This relationship permits one to factor out common behavior into a&#xD;
    separate use case that is &quot;include&quot; in other use cases.&amp;nbsp; See &lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../core.tech.common.extend_supp/guidances/concepts/use_case_model_CD178AF9.html&quot;&#xD;
    guid=&quot;_2jyfUAhVEduRe8TeoBmuGg&quot;>Concept: Use-Case Model&lt;/a>&amp;nbsp;for more&amp;nbsp;details.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Another aspect of&amp;nbsp;structuring the use-case model for easier understanding is grouping the use cases into packages.&#xD;
    The use-case model can be organized as a hierarchy of use-case packages. For more information on use-case packages, see&#xD;
    &lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../core.tech.common.extend_supp/guidances/concepts/use_case_model_CD178AF9.html&quot;&#xD;
    guid=&quot;_2jyfUAhVEduRe8TeoBmuGg&quot;>Concept: Use-Case Model&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Use Cases Are Always Related to Actors&quot; name=&quot;Use Cases Are Always Related to Actors&quot;>Relationship Between Use&#xD;
    Cases and Actors&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Running each use case includes communication with one or more actors. A use-case instance is always started by an actor&#xD;
    asking the system to do something. This implies that every use case must have communicates-associations with actors.&#xD;
    The reason for this rule is to enforce that the system provides only the functionality that users need and nothing&#xD;
    else. Having use cases that no one requests is an indication that something is wrong in the use-case model or in the&#xD;
    requirements.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    However, there are some exceptions to this rule:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        An&amp;nbsp;&quot;included&quot; use case might not interact with an actor if the base use case does.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        A use case can be initiated according to a schedule (for example, once a week or once a day), which means that the&#xD;
        system clock is the initiator. The system clock is internal to the system; therefore, the use case is not initiated&#xD;
        by an actor but by an internal system event. If no other actor interaction occurs in the use case, it will not have&#xD;
        any associations to actors. However, for clarity, you can use &quot;time&quot; as an actor to show how the use case is&#xD;
        initiated in your use-case diagrams. &lt;strong>CAUTION:&lt;/strong> if you have a lot of &quot;time&quot; actors in your model,&#xD;
        challenge them.&amp;nbsp; Perhaps you missed a real actor, such as an administrator responsible for scheduling reports,&#xD;
        etc.&#xD;
    &lt;/li>&#xD;
&lt;/ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>