| <?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="-_dNuyh-0q5vpCiIiLfbj6w" |
| name="system_wide_requirements,_BVh9cL-CEdqb7N6KIeDL8Q" guid="-_dNuyh-0q5vpCiIiLfbj6w" |
| changeDate="2008-08-15T12:49:32.109-0700" version="1.0.0"> |
| <keyConsiderations><ul>
 |
| <li> When you document system-wide requirements, ensure that the needs
 |
| of all of the stakeholders are represented. In particular, include
 |
| the needs of those who are responsible for maintaining or supporting the system
 |
| after it is delivered. </li>
 |
| <li> Typically, there are some overlaps and gray areas between system-wide
 |
| requirements and other requirements work products. For example, the
 |
| authorization behavior of a system can be specified as use cases or as statements
 |
| within system-wide requirements. The overall driving need is that no important
 |
| requirements are missed or duplicated, and that there is an agreed upon approach
 |
| for capturing and processing every type of requirement. </li>
 |
| <li> System-wide requirements originate from many places. Documenting
 |
| the source of the requirement is particularly important when you separate
 |
| externally mandated requirements. </li>
 |
| <li> Requirements are often thought of as "Qualitative" (specifying
 |
| a quality or desirable characteristic) versus "Quantitative" (specifying
 |
| a quantity). Qualitative requirements can sometimes be elaborated into quantitative
 |
| requirements. </li>
 |
| <li> A good quality requirement is one that you can verify, either
 |
| through testing or some other objective evaluation. </li>
 |
| <li> You must evaluate system-wide requirements for cost, schedule
 |
| impact, and level of contribution to business goals. Based on your
 |
| evaluation, the system-wide requirements should be iteratively challenged,
 |
| defended, and amended. </li>
 |
| </ul></keyConsiderations> |
| <purpose><p> 
 |
| This artifact is used for the following purposes: </p> <ul>
 |
| <li> To describe the quality attributes of the system, and the constraints
 |
| that the design options must satisfy to deliver the business goals, objectives,
 |
| or capabilities </li>
 |
| <li> To capture functional requirements that are not expressed as
 |
| use cases </li>
 |
| <li> To negotiate between, and select from, competing design options
 |
| </li>
 |
| <li> To assess the sizing, cost, and viability of the proposed system
 |
| </li>
 |
| <li> To understand the service-level requirements for operational
 |
| management of the solution </li>
 |
| </ul></purpose> |
| <impactOfNotHaving><p> If
 |
| you do not adequately manage and meet system-wide requirements, you risk delivering
 |
| a system that might be unacceptable to stakeholders.<br/> </p></impactOfNotHaving> |
| <reasonsForNotNeeding><p
 |
| > You do not need to use this artifact if none of the categories of system-wide
 |
| requirements apply to the project under consideration. </p></reasonsForNotNeeding> |
| <briefOutline><p> Organize
 |
| system-wide requirements by a number of common themes or subcategories: the
 |
| areas of performance and capacity, availability, usability, security and privacy,
 |
| maintainability, manageability, and flexibility. See the supporting guidance
 |
| for a description of the recommended categorization approach. </p> <p>For
 |
| each system-wide requirement, capture attributes such as the source and priority
 |
| of the requirements, as described by the associated requirements management
 |
| guidance. </p></briefOutline> |
| <representationOptions>This
 |
| artifact represents the influences on the design and delivery of a system,
 |
| which cover a broad range of themes. Document the requirements for each theme
 |
| under separate headings within a document or under appropriate category identifiers
 |
| in a requirements gathering tool. Give categories easy-to-recognize identifiers,
 |
| so individual requirements can be readily associated with the appropriate
 |
| category. The format of requirements vary from category to category; some
 |
| are heavily textual, and others are more structured and quantitative.</representationOptions> |
| </org.eclipse.epf.uma:ArtifactDescription> |
