<?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf"
    epf:version="1.5.0" xmi:id="-3WNAtOgFvwsJtFvhDugsVA"
    name="new_roadmap,_PJKZkMRfEdyBt8f9agIerg" guid="-3WNAtOgFvwsJtFvhDugsVA" changeDate="2008-02-29T10:35:38.187-0800"
    version="7.2.0">
  <mainDescription>&lt;h3>&#xD;
    Getting Started &#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    After getting some basic familiarity with the concept of use cases, consider identifying use cases in a workshop&#xD;
    environment, led by someone experienced in writing use cases. Detail one or a few example scenarios to serve as an&#xD;
    example for other use case authors, to set a standard for format, style, and level of detail.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Some teams prefer to identify all of the use cases and actors first, capturing those in a UML use-case diagram, or other sort&#xD;
    of visual notation. Then they iteratively detail the use cases assigned to the current or next iteration, by outlining&#xD;
    the steps in the use case main flow and alternative flows. When these steps and flows are detailed in the amount needed&#xD;
    for development to start, it is useful to group flows in what is called use-case scenarios. Some teams prefer to&#xD;
    identify scenarios first and then write the use cases in a more structured way later, by grouping related scenarios&#xD;
    together. Scenarios can be used as a unit of work assignment and progress measurement on how use cases are analyzed,&#xD;
    designed, implemented, and tested throughout the project.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    As you get more comfortable with this practice, consider supplementing your use cases with storyboards, activity&#xD;
    diagrams, and additional requirements techniques. Modeling use cases in UML diagrams or in modeling tools can be&#xD;
    helpful when there are lots of use cases, but start with a focus on the text and some key scenarios.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Common pitfalls&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Try to avoid applying functional decomposition approach to use cases. That may lead you to find too many use&#xD;
    cases, and use-case descriptions that are a half-page or less in length. On the other hand, finding too few use&#xD;
    cases may result in overloaded use cases. It may lead to long and complex use-case descriptions. Try to find&#xD;
    a balance that makes sense for your team, stakeholders, and the type of system that you are developing. There are different&#xD;
    opinions about what is the appropriate number of use cases for a system. The suggestion is that even large, complex&#xD;
    systems will have no more than a couple dozen use cases on average.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>