OpenUP/OpenUP_SP/library/openup_basic/guidances/concepts/supporting_requirements.xmi

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