Roadmap: How to Adopt this Practice |  |
This roadmap describes how to adopt the Use-Case Driven Development Practice.
Main Description
### Getting Started 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. Some teams prefer to identify all use cases and actors first, capturing those in an 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. 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. #### Common Pitfalls 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 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 type of system you are developing. There are discussions around 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.
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. OpenUP Copyright.