EPF_Practices/practice.tech.use_case_driven_dev.base/guidances/roadmaps/how_to_adopt.xmi

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