| <?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><h3>
 |
| Definition
 |
| </h3>
 |
| <p>
 |
| Supporting requirements are requirements that&nbsp;define necessary system quality attributes&nbsp;such as performance,
 |
| usability and reliability, as well as global functional requirements&nbsp;that are not captured in behavioral
 |
| requirements artifacts such as use-cases.
 |
| </p>
 |
| <h3>
 |
| Supporting Requirements Categories
 |
| </h3>
 |
| <p>
 |
| Supporting requirements are categorized according to the FURPS+ model (Functional, Usability, Reliability, Performance,
 |
| Supportability + constraints). Constraints&nbsp;include design, implementation, interfaces, physical constraints, and
 |
| business rules. A description of each of these types of requirements follows.
 |
| </p>
 |
| <p>
 |
| 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&nbsp;support at least one feature, and each feature
 |
| should be supported by at least one to requirement.
 |
| </p>
 |
| <p>
 |
| In general, <strong>functional</strong> requirements describe behavior and are captured in&nbsp;Use Cases (see&nbsp;<a class="elementLinkWithType" href="./../../../openup/workproducts/use_case_22BE66E2.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Artifact: Use Case</a>). <strong>Non-functional</strong> requirements are captured in
 |
| the <a class="elementLinkWithType" href="./../../../openup/workproducts/supporting_requirements_spec_7D9DD47C.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Artifact: Supporting Requirements Specification</a>. 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.&nbsp; Similarly, there are global, or system-wide, functional requirements that are often captured
 |
| among the supporting requirements for the same reasons.&nbsp;
 |
| </p>
 |
| <h4>
 |
| Functional requirements
 |
| </h4>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <h4>
 |
| Usability requirements
 |
| </h4>
 |
| <p>
 |
| Usability requirements include requirements based on human factors and user interface issues such as accessibility,
 |
| interface aesthetics, and consistency within the user interface.
 |
| </p>
 |
| <h4>
 |
| Reliability requirements
 |
| </h4>
 |
| <p>
 |
| Reliability requirements include aspects such as availability, accuracy, predictability, frequency of failure or
 |
| recoverability of the system from shut-down failure.
 |
| </p>
 |
| <h4>
 |
| Performance requirements
 |
| </h4>
 |
| <p>
 |
| Performance requirements address concerns such as throughput of information through the system, system response time
 |
| and resource usage.
 |
| </p>
 |
| <h4>
 |
| Supportability requirements
 |
| </h4>
 |
| <p>
 |
| Supportability requirements include requirements such as compatibility and the abilities to test, adapt, maintain,
 |
| configure, install, scale, localize, and so on.
 |
| </p>
 |
| <h4>
 |
| + Constraints
 |
| </h4>
 |
| <p>
 |
| The <strong>+</strong> of the FURPS+ acronym allows you to specify constraints, such as design, implementation,
 |
| interfaces, physical constraints, and business rules:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>Design constraints</strong> limit the design and state requirements on the approach that should be taken in
 |
| developing the system.
 |
| </li>
 |
| <li>
 |
| <strong>Implementation constraints</strong> put limits on coding or construction (required standards, languages,
 |
| tools, or platform)
 |
| </li>
 |
| <li>
 |
| <strong>Interface constraints</strong> are requirements to interact with external systems, describing protocols or
 |
| the nature of the information that is passed across that interface.
 |
| </li>
 |
| <li>
 |
| <strong>Physical constraints</strong> affect the hardware or packaging housing the system (shape, size, and
 |
| weight).
 |
| </li>
 |
| <li>
 |
| <strong>Business rules</strong> are policies or decisions that govern how the business operates. They may constrain
 |
| the steps described in the Use Case flow.
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
