blob: 40df95d48b22e0ff55037c2e990565a9dedbbf16 [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="" xmlns:org.eclipse.epf.uma="" 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">
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.
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
guid=&quot;_VXZ5wO0IEdqHTdbLTmC5IQ&quot;&gt;Concept: Supporting Requirements&lt;/a&gt;.
The figure that follows illustrates the relationship among the Supporting Requirements, Use Case Specifications, and
&amp;nbsp;&lt;img height=&quot;400&quot; alt=&quot;&quot; src=&quot;./resources/supporting_reguirements2.gif&quot; width=&quot;600&quot; /&gt;
<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;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;
Option: Include as Part of the Vision Document
&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>