blob: add4e6807daf46dad40324138cabb52f839d8879 [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
<!-- VERSION rmc:7.1.0 -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<!-- START NON-TRANSLATABLE -->
<title>\openup_basic\workproducts\supporting_requirements.xmi</title>
</head>
<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
<body>
Element Name: supporting_requirements.xmi<br/><br/>
<!-- END NON-TRANSLATABLE -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: presentationName<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:presentationName,_BVh9cL-CEdqb7N6KIeDL8Q CRC: 3054352662 -->Supporting Requirements<!-- END:presentationName,_BVh9cL-CEdqb7N6KIeDL8Q -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: briefDescription<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:briefDescription,_BVh9cL-CEdqb7N6KIeDL8Q CRC: 301387017 -->This artifact captures system-wide requirements not captured in scenarios or use cases, including requirements on quality attributes and global functional requirements.<!-- END:briefDescription,_BVh9cL-CEdqb7N6KIeDL8Q -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: mainDescription<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:mainDescription,-_dNuyh-0q5vpCiIiLfbj6w CRC: 2532495142 --><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 in 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_basic/guidances/concepts/supporting_requirements,_VXZ5wO0IEdqHTdbLTmC5IQ.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>
&nbsp;<img height="400" alt="" src="./resources/supporting_reguirements2.gif" width="600" />
</p><!-- END:mainDescription,-_dNuyh-0q5vpCiIiLfbj6w -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: impactOfNotHaving<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:impactOfNotHaving,-_dNuyh-0q5vpCiIiLfbj6w CRC: 107606050 --><p> The goal of&nbsp;this&nbsp;work product is&nbsp;to make sure that all types
of requirements are covered, which reduces the risk of not considering some
important facet of the system.&nbsp;FURPS+ requirements are system-wide, and
they&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.<strong>
</strong></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><!-- END:impactOfNotHaving,-_dNuyh-0q5vpCiIiLfbj6w -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: representationOptions<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:representationOptions,-_dNuyh-0q5vpCiIiLfbj6w CRC: 523446910 --><p> 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.<strong> </strong></p>
<p align="left"> The following are recommendation and options for representing
the Supporting Requirements:</p>
<h4> Option: Use the Work Items List</h4>
<p> Consider capturing Supporting Requirements in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact:
Work Items List</a>, 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. </p>
<h4>
Option: Include as Part of the Vision Document
</h4>
<p> Consider including some types of Supporting Requirements in <a class="elementLinkWithType" href="./../../openup_basic/workproducts/vision,_0WVxcMlgEdmt3adZL5Dmdw.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Artifact:
Vision</a>. To keep the Vision stable, follow this option for the requirements
types that need less refinement, such as Product Qualities, Documentation, or
Compliance. </p><!-- END:representationOptions,-_dNuyh-0q5vpCiIiLfbj6w -->
</body>
</html>