<?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="-3SXuKijeVOZalgLPgWRyFA"
    name="supporting_requirements_1,_VXZ5wO0IEdqHTdbLTmC5IQ" guid="-3SXuKijeVOZalgLPgWRyFA"
    authors="Chris Sibbald" changeDate="2006-12-21T09:31:36.206-0800" version="0.2">
  <mainDescription>&lt;h3>&#xD;
    Definition&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Supporting requirements are requirements that&amp;nbsp;define necessary system quality attributes&amp;nbsp;such as performance,&#xD;
    usability and reliability, as well as global functional requirements&amp;nbsp;that are not captured in behavioral&#xD;
    requirements artifacts such as use-cases.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Supporting Requirements Categories&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Supporting requirements are categorized according to the FURPS+ model (Functional, Usability, Reliability, Performance,&#xD;
    Supportability + constraints). Constraints&amp;nbsp;include design, implementation, interfaces, physical constraints, and&#xD;
    business rules. A description of each of these types of requirements follows.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Supporting requirements and Use Cases, together, define the requirements of the system. These requirements support the&#xD;
    features listed in the Vision statement. Each requirement should&amp;nbsp;support at least one feature, and each feature&#xD;
    should be supported by at least one to requirement.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In general, &lt;strong>functional&lt;/strong> requirements describe behavior and are captured in&amp;nbsp;Use Cases (see&amp;nbsp;&lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/workproducts/use_case_22BE66E2.html&quot; guid=&quot;_0VGbUMlgEdmt3adZL5Dmdw&quot;>Artifact: Use Case&lt;/a>). &lt;strong>Non-functional&lt;/strong> requirements are captured in&#xD;
    the &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>. However, nonfunctional requirements that are&#xD;
    closely associated with a particular Use Case are often captured within the Use Case itself to simplify communication&#xD;
    and maintenance.&amp;nbsp; Similarly, there are global, or system-wide, functional requirements that are often captured&#xD;
    among the supporting requirements for the same reasons.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Functional requirements&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Functionality requirements include all the overarching, system wide functional requirements. These functional&#xD;
    requirements represent the main system features that are familiar within the business domain or technically oriented&#xD;
    requirements such as auditing, licensing, localization, mail, online help, printing, reporting, security, system&#xD;
    management, or workflow.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Usability requirements&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Usability requirements include requirements based on human factors and user interface issues such as accessibility,&#xD;
    interface aesthetics, and consistency within the user interface.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Reliability requirements&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Reliability requirements include aspects such as availability, accuracy, predictability, frequency of failure or&#xD;
    recoverability of the system from shut-down failure.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Performance requirements&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Performance requirements address concerns such as throughput of information through the system, system response time&#xD;
    and resource usage.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Supportability requirements&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Supportability requirements include requirements such as compatibility and the abilities to test, adapt, maintain,&#xD;
    configure, install, scale, localize, and so on.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    + Constraints&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    The &lt;strong>+&lt;/strong> of the FURPS+ acronym allows you to specify constraints, such as design, implementation,&#xD;
    interfaces, physical constraints, and business rules:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;strong>Design constraints&lt;/strong> limit the design and state requirements on the approach that should be taken in&#xD;
        developing the system.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Implementation constraints&lt;/strong> put limits on coding or construction (required standards, languages,&#xD;
        tools, or platform)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Interface constraints&lt;/strong> are requirements to interact with external systems, describing protocols or&#xD;
        the nature of the information that is passed across that interface.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Physical constraints&lt;/strong> affect the hardware or packaging housing the system (shape, size, and&#xD;
        weight).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Business rules&lt;/strong> are policies or decisions that govern how the business operates. They may constrain&#xD;
        the steps described in the Use Case flow.&#xD;
    &lt;/li>&#xD;
&lt;/ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>