| <?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.4/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.2.0" xmi:id="-_dNuyh-0q5vpCiIiLfbj6w" |
| name="system_wide_requirements,_BVh9cL-CEdqb7N6KIeDL8Q" guid="-_dNuyh-0q5vpCiIiLfbj6w" |
| changeDate="2008-02-11T16:17:03.644-0800" version="1.0.0"> |
| <keyConsiderations><ul> |
| <li> |
| When documenting system-wide requirements, ensure that the needs of all stakeholders are represented.&nbsp; In |
| particular, don't forget to include the needs of those responsible for maintaining or supporting the system once |
| delivered. |
| </li> |
| <li> |
| There are typically some overlaps and "gray areas" between system-wide requirements and other requirements work |
| products.&nbsp; For example, the authorization behavior of a system can be specified as use cases, or as statements |
| within system-wide requirements.&nbsp; The overall driving need is that no important requirements are missed or |
| duplicated and that there is an agreed 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 separating out externally mandated requirements. |
| </li> |
| <li> |
| Requirements are often thought of as "Qualitative" (specifying a quality or desirable characteristic) versus |
| "Quantitative" (specifying a quantity).&nbsp;&nbsp;Qualitative requirements can sometimes be elaborated into |
| quantitative requirements. |
| </li> |
| <li> |
| A good quality requirement is one that can be verified, either through testing or some other objective evaluation. |
| </li> |
| <li> |
| System-wide requirements should be evaluated for cost, schedule impact and level of contribution to business goals. |
| They should be iteratively challenged, defended and amended based on this evaluation. |
| </li> |
| </ul></keyConsiderations> |
| <purpose><p>
 |
| This artifact is used for the following purposes:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| It is used to describe the quality attributes of the system and the constraints which the design options will be
 |
| required to satisfy in order to deliver the business goals, objectives or capabilities.
 |
| </li>
 |
| <li>
 |
| It is used to capture functional requirements that are not expressed as use cases.
 |
| </li>
 |
| <li>
 |
| It is used to negotiate between, and select from, competing design options.
 |
| </li>
 |
| <li>
 |
| It is used to assess the sizing, cost and viability of the proposed system.
 |
| </li>
 |
| <li>
 |
| It is a key consideration for understanding service level requirements for operational management of the solution.
 |
| </li>
 |
| </ul></purpose> |
| <impactOfNotHaving><p>
 |
| A failure to adequately manage and meet system-wide requirements leads to a risk of delivering a system which is
 |
| unacceptable to one or more stakeholders.<br />
 |
| </p></impactOfNotHaving> |
| <reasonsForNotNeeding><p>
 |
| If none of the categories of system-wide requirements apply to the project under consideration, this artifact may not
 |
| be needed.
 |
| </p></reasonsForNotNeeding> |
| <briefOutline><p>
 |
| System-wide requirements should be organized by a number of common themes or subcategories. These include the areas of
 |
| performance and capacity, availability, usability, security and privacy, maintainability, manageability and
 |
| flexibility. A description of the recommended categorization approach is given in the supporting guidance.
 |
| </p>
 |
| <p>
 |
| For each system-wide requirement capture attributes such as the source and priority of the requirements,
 |
| as&nbsp;described&nbsp;by the associated requirements management guidance.
 |
| </p></briefOutline> |
| <representationOptions>This artifact&nbsp;represent influences on the design and delivery of a system which cover a broad range of themes.&nbsp;
 |
| Requirements for each theme should be documented under separate headings within a document, or under appropriate category
 |
| identifiers in a requirements gathering tool.&nbsp; Categories are often given easy-to-recognize identifiers so individual
 |
| requirements can be readily associated with the appropriate category.&nbsp; The format of requirements will vary from
 |
| category to category, with some being heavily textual, and others being more structured and quantitative.</representationOptions> |
| </org.eclipse.epf.uma:ArtifactDescription> |
