<?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="_eUfzwMMyEdmdo9HxCRR_Gw"
    name="requirements,_0Wh-sMlgEdmt3adZL5Dmdw" guid="_eUfzwMMyEdmdo9HxCRR_Gw" changeDate="2006-12-21T08:21:47.640-0800"
    version="1.0.0">
  <mainDescription>&lt;p>&#xD;
    Requirements are the project team's to-do list.&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
    Requirements define what is needed and focus the project team. They are the primary method used to communicate the&#xD;
    goals of the project to everyone on the team.&#xD;
&lt;/p>&#xD;
&lt;div class=&quot;O&quot; v:shape=&quot;_x0000_s1026&quot;>&#xD;
    &lt;div style=&quot;mso-line-spacing: '100 30 0'&quot;>&#xD;
        Requirements define:&#xD;
    &lt;/div>&#xD;
&lt;/div>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        What the&amp;nbsp;stakeholders&amp;nbsp;need; and&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        What the system must include to satisfy the stakeholder needs.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
    Requirements are the basis for capturing and communicating needs, managing expectations, prioritizing and assigning&#xD;
    work, verifying and validating the system (acceptance), and managing the scope of the project.&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
    Requirements may take different forms, including Use Cases and Scenarios, unstructured text, structured text, or a&#xD;
    combination, and they may be stated at different levels of granularity. At the highest level of granularity,&amp;nbsp;&lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/guidances/termdefinitions/feature_4ED64AEE.html&quot; guid=&quot;_PgYREAeYEduWycDgioo5rg&quot;>feature&lt;/a>s define the services that the system must provide to solve the customer's&#xD;
    problem. These are captured as structured or unstructured text in the &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/workproducts/vision_2E71B03C.html&quot; guid=&quot;_0WVxcMlgEdmt3adZL5Dmdw&quot;>Artifact: Vision&lt;/a>. At the next level of granularity, Use Cases define the&#xD;
    functionality that the system must provide to&amp;nbsp;deliver the required features. These are captured&amp;nbsp;as Use Cases&#xD;
    (see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/workproducts/use_case_22BE66E2.html&quot; guid=&quot;_0VGbUMlgEdmt3adZL5Dmdw&quot;>Artifact: Use Case&lt;/a>)&amp;nbsp;that describe the sequence of actions performed by the&#xD;
    system to yield an observable result of value.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A system must perform according to the behavior that Use Cases specify. However, there are system requirements that do&#xD;
    not represent a specific behavior:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Legal and regulatory requirements, as well as application standards&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Quality attributes of the system to be built, including usability, reliability, performance, and supportability&#xD;
        requirements&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Interface requirements to be able to communicate with external systems&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Design constraints, such as those for operating systems and environments and for compatibility with other software&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    These quality requirements are often referred to as &lt;strong>non-functional&lt;/strong> requirements.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Quality requirements that apply to the system as a whole are captured as structured text in &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/workproducts/supporting_requirements_spec_7D9DD47C.html&quot; guid=&quot;_BVh9cL-CEdqb7N6KIeDL8Q&quot;>Artifact: Supporting Requirements Specification&lt;/a>.&amp;nbsp; Quality requirements that are closely&#xD;
    associated with a particular Use Case are often captured in the Use Case itself to simplify review, understanding, and&#xD;
    maintenance.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>