| <?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.4/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.2.0" xmi:id="-3SXuKijeVOZalgLPgWRyFA" |
| name="supporting_requirements_1,_VXZ5wO0IEdqHTdbLTmC5IQ" guid="-3SXuKijeVOZalgLPgWRyFA" |
| authors="Chris Sibbald" changeDate="2008-02-11T13:54:28.636-0800" version="0.2"> |
| <mainDescription><h3>
 |
| Definition
 |
| </h3>
 |
| <p>
 |
| System-wide 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>
 |
| System-wide&nbsp;Requirements Categories
 |
| </h3>
 |
| <p>
 |
| System-wide&nbsp;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>
 |
| System-wide 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 requirement.
 |
| </p>
 |
| <p>
 |
| In general, <strong>functional</strong> requirements describe behavior and can be captured as&nbsp;use cases.
 |
| <strong>Non-functional</strong> requirements are captured in a system-wide requirements specification.&nbsp;However,
 |
| nonfunctional requirements that are closely associated with a particular use case are often captured within the
 |
| use-case specification itself to simplify communication and maintenance.&nbsp;Similarly, there are global, or
 |
| system-wide functional requirements that are often captured among the system-wide requirements for the same
 |
| reasons.&nbsp;
 |
| </p>
 |
| <h4>
 |
| Functional requirements
 |
| </h4>
 |
| <p>
 |
| Functional requirements include all the overarching, system-wide functional requirements that are not expressed as use
 |
| cases. These functional requirements represent the main system features that are familiar within the business domain or
 |
| technically oriented requirements such as auditing, licensing, localization, e-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&nbsp;requirements such as compatibility and the abilities to test, adapt, maintain,
 |
| configure, install, scale, and localize the system.
 |
| </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 us-case flow.
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
