| <?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><h3>
 |
| Getting Started 
 |
| </h3>
 |
| <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.
 |
| </p>
 |
| <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.
 |
| </p>
 |
| <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.
 |
| </p>
 |
| <h4>
 |
| Common pitfalls
 |
| </h4>
 |
| <p>
 |
| Try to avoid applying functional decomposition approach to use cases. That may 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 may result in overloaded use cases. It may 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.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
