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