| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:PracticeDescription 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="-J8H_fSsJx2Au1sebs1zyCg" |
| name="new_practice,_w1JD4B4jEd2bS8fFOQ7WWA" guid="-J8H_fSsJx2Au1sebs1zyCg" changeDate="2008-08-04T13:32:09.312-0700" |
| version="7.5.0"> |
| <additionalInfo><h3>
 |
| Books and Articles<br />
 |
| <br />
 |
| </h3>
 |
| <table width="100%" summary="layout table" border="0">
 |
| <tbody>
 |
| <tr>
 |
| <td colspan="2">
 |
| Kurt Bittner and Ian Spence 2003. <i>Use Case Modeling.</i> Addison Wesley Longman.
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td width="10%">
 |
| </td>
 |
| <td style="PADDING-BOTTOM: 10px" width="78%">
 |
| Comprehensive coverage of use case techniques and practices, including useful examples showing how use-case
 |
| specifications evolve over time.
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td colspan="2">
 |
| Alistair Cockburn 2001. <i>Writing Effective Use Cases.</i> Addison Wesley Longman.
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td width="10%">
 |
| </td>
 |
| <td style="PADDING-BOTTOM: 10px" width="78%">
 |
| Excellent guidance for those who need to write use cases. Multiple styles and techniques contrasted with
 |
| insight in an unbiased way. Many helpful tips to improve your use cases.
 |
| </td>
 |
| </tr>
 |
| </tbody>
 |
| </table></additionalInfo> |
| <problem><p>
 |
| Many organizations document requirements as a list of declarative statements (or "shall" statements) that lead the team
 |
| to focus on developing atomic functions and fine-grained assertions of need. Moreover, applications developed from
 |
| such requirements are often difficult to use and require more time for integration and testing than applications
 |
| developed using user-focused requirements.
 |
| </p>
 |
| <p>
 |
| A second, more serious organizational anti-pattern is no focus on requirements at all. Many organizations simply fail
 |
| to document requirements, leaving it to developers to discern from a perhaps vague vision document, or even nothing
 |
| more than a meeting or conversation, what the application or system to be developed must do.
 |
| </p>
 |
| <p>
 |
| This practice shows how to avoid these pitfalls by using use cases and scenarios to capture functional requirements.
 |
| That approach provides development of usage scenarios that clearly express behavior (or the interaction between users
 |
| and the system under development). Use cases categorize valuable and useful end-to-end, testable and collaborative
 |
| behavior in which the system is involved. Non-functional requirements (such as performance, stability, usability, and
 |
| so on) can still be captured using traditional techniques. This practice also explains how use cases and scenarios are
 |
| best developed in conjunction with (and used to drive) other development activities, including design and
 |
| testing.&nbsp;&nbsp;
 |
| </p></problem> |
| <application><p>
 |
| The best way to review a practice is to familiarize yourself with the enablement materials, and then review key
 |
| concepts, work products, tasks, and the more detailed guidance, either by reviewing the guidance category directly, or
 |
| by navigating from tasks and work products to their related guidance.
 |
| </p>
 |
| <p>
 |
| You may first want to become familiar with general requirements concepts:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/requirements_8006414F.html" guid="_0Wh-sMlgEdmt3adZL5Dmdw">Requirements</a>
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Then become familiar with use cases:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/use_case_BB199D1B.html" guid="_KudM0NcJEdqz_d2XWoVt6Q">Use Case</a>
 |
| </li>
 |
| <li>
 |
| <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/actor_411726C.html" guid="_zGqO0MDpEduTGJ8i4u8TMw">Actor</a>
 |
| </li>
 |
| <li>
 |
| <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/use_case_model_CD178AF9.html" guid="_2jyfUAhVEduRe8TeoBmuGg">Use-Case Model</a>
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| This practice focuses on the following work products:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <a class="elementLink" href="./../../../core.tech.common.extend_supp/workproducts/use_case_22BE66E2.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>
 |
| </li>
 |
| <li>
 |
| <a class="elementLink" href="./../../../core.tech.common.extend_supp/workproducts/system_wide_requirements_7D9DD47C.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">System-Wide Requirements</a>
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Both work products go through similar states: they are identified and outlined, which allows them to be prioritized,
 |
| and then detailed. However, in general, a use case is detailed a scenario at a time. (This is particularly important
 |
| when following an iterative approach, where a scenario is detailed "just in time" to be implemented, as opposed to the
 |
| approach of detailing all or most requirements up front). The tasks that drive these states are listed here: <a class="elementLink" href="./../../../practice.tech.use_case_driven_dev.base/customcategories/tasks_61FD663B.html" guid="_K5oBwMSFEdyBt8f9agIerg">Tasks</a>.
 |
| </p>
 |
| <p>
 |
| In addition, guidelines and tool mentors associated with each task provide details of how to perform the
 |
| task.&nbsp;Templates and checklists associated with the work products guide you in their completion and evaluation.
 |
| </p>
 |
| <p>
 |
| Measurements can guide you on assessing how well you are following this practice.
 |
| </p></application> |
| </org.eclipse.epf.uma:PracticeDescription> |
