OpenUP/OpenUP_SP/library/openup_basic/workproducts/supporting_requirements.xmi

<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-_dNuyh-0q5vpCiIiLfbj6w" name="supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q" guid="-_dNuyh-0q5vpCiIiLfbj6w" changeDate="2006-12-21T12:42:23.035-0500">
  <mainDescription>&lt;p&gt;
    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 in Use
    Case Specifications. Making this distinction simplifies maintenance.
&lt;/p&gt;
&lt;p&gt;
    Supporting Requirements may be categorized according to the FURPS+ model (Functional, Usability, Reliability,
    Performance, Supportability + Constraints). For more information on this classification, see &lt;a
    class=&quot;elementLinkWithType&quot;
    href=&quot;./../../openup_basic/guidances/concepts/supporting_requirements,_VXZ5wO0IEdqHTdbLTmC5IQ.html&quot;
    guid=&quot;_VXZ5wO0IEdqHTdbLTmC5IQ&quot;&gt;Concept: Supporting Requirements&lt;/a&gt;.
&lt;/p&gt;
&lt;p&gt;
    The figure that follows illustrates the relationship among the Supporting Requirements, Use Case Specifications, and
    Actors.
&lt;/p&gt;
&lt;p&gt;
    &amp;nbsp;&lt;img height=&quot;400&quot; alt=&quot;&quot; src=&quot;./resources/supporting_reguirements2.gif&quot; width=&quot;600&quot; /&gt;
&lt;/p&gt;</mainDescription>
  <impactOfNotHaving>&lt;p&gt; The goal of&amp;nbsp;this&amp;nbsp;work product is&amp;nbsp;to make sure that all types 
  of requirements are covered, which reduces the risk of not considering some 
  important facet of the system.&amp;nbsp;FURPS+ requirements are system-wide, and 
  they&amp;nbsp;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.&lt;strong&gt; 
  &lt;/strong&gt;&lt;/p&gt;
&lt;p&gt; 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. &lt;/p&gt;</impactOfNotHaving>
  <representationOptions>&lt;p&gt; This work product does not imply using only one 
  document to capture all requirement types. To manage the communication of the 
  information, it makes more sense to separate the information into separate documents 
  or to use the Work Items List.&lt;strong&gt; &lt;/strong&gt;&lt;/p&gt;
&lt;p align=&quot;left&quot;&gt; The following are recommendation and options for representing 
  the Supporting Requirements:&lt;/p&gt;
&lt;h4&gt; Option: Use the Work Items List&lt;/h4&gt;
&lt;p&gt; Consider capturing Supporting Requirements in the &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html&quot; guid=&quot;_rGNWsCbSEdqh1LYUOGRh2A&quot;&gt;Artifact: 
  Work Items List&lt;/a&gt;, which you can use for prioritizing and managing requirements. 
  If Stakeholders are comfortable with it, or with accessing a report automatically 
  generated from it, then you do not need a separate document. &lt;/p&gt;
&lt;h4&gt;
    Option: Include as Part of the Vision Document
&lt;/h4&gt;
&lt;p&gt; Consider including some types of Supporting Requirements in &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0WVxcMlgEdmt3adZL5Dmdw&quot;&gt;Artifact: 
  Vision&lt;/a&gt;. To keep the Vision stable, follow this option for the requirements 
  types that need less refinement, such as Product Qualities, Documentation, or 
  Compliance. &lt;/p&gt;</representationOptions>
</org.eclipse.epf.uma:ArtifactDescription>