| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ArtifactDescription 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="-_dNuyh-0q5vpCiIiLfbj6w" |
| name="supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q" guid="-_dNuyh-0q5vpCiIiLfbj6w" |
| changeDate="2007-06-06T05:19:08.886-0700"> |
| <mainDescription><p>
 |
| Supporting Requirements and Use Cases, together, define the system requirements. Use Cases describe the behavioral
 |
| requirements for the system, and Supporting Requirements describe system-wide requirements that are not captured within
 |
| the Use-Case Specifications. Making this distinction simplifies maintenance.
 |
| </p>
 |
| <p>
 |
| Supporting Requirements may be categorized according to the FURPS+ model (Functional, Usability, Reliability,
 |
| Performance, Supportability + Constraints). For more information on this classification, see <a class="elementLinkWithType" href="./../../openup/guidances/concepts/supporting_requirements_B2C4D610.html" guid="_VXZ5wO0IEdqHTdbLTmC5IQ">Concept: Supporting Requirements</a>.
 |
| </p>
 |
| <p>
 |
| The figure that follows illustrates the relationship among the Supporting Requirements, Use-Case Specifications, and
 |
| Actors.
 |
| </p>
 |
| <p>
 |
| <img height="400" alt="" src="./resources/supporting_reguirements2.gif" width="600" />
 |
| </p></mainDescription> |
| <impactOfNotHaving><p>
 |
| The goal of this work product is to make sure that all types of requirements are covered, which reduces the risk of not
 |
| considering some important facet of the system. FURPS+ requirements are system-wide, and they influence the
 |
| Architectural Mechanisms that you will create, thus guiding development of the system's foundation. These requirements
 |
| are frequently the major cost item, because they determine architectural choices.
 |
| </p>
 |
| <p>
 |
| Furthermore, if you do not capture system-wide requirements in a central location, but repeat them throughout the Use
 |
| Cases, the result will be more maintenance and more chance for error.
 |
| </p></impactOfNotHaving> |
| <representationOptions><h4>
 |
| 
 |
| Recommendation: Use the Supporting Requirements Specification Template
 |
| 
 |
| </h4>
 |
| 
 |
| <p>
 |
| 
 |
| The <a class="elementLink" href="./../../openup/guidances/templates/supporting_requirements_spec_4223C78.html" guid="_ItYXcNa9Edqrw4BYKyYKiA">Supporting Requirements Specification</a> template provides a tool to capture,
 |
| 
 |
| structure, and organize the supporting requirements.
 |
| 
 |
| </p>
 |
| 
 |
| <p>
 |
| 
 |
| Even in a small project, a requirements management tool, a database, or a spreadsheet, are recommended for prioritizing
 |
| 
 |
| and managing requirements. If Stakeholders are comfortable with accessing requirements directly from that tool, or with
 |
| 
 |
| accessing a report automatically generated from the tool, you do not need a separate document.
 |
| 
 |
| </p></representationOptions> |
| </org.eclipse.epf.uma:ArtifactDescription> |
