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