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