| Artifact: System-Wide Requirements |
| |
 |
| This artifact captures quality attributes and constraints that have system-wide scope. It also captures system-wide functional requirements. |
| Domains: Requirements |
|
Purpose
This artifact is used for the following purposes:
-
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.
-
It is used to capture functional requirements that are not expressed as use cases.
-
It is used to negotiate between, and select from, competing design options.
-
It is used to assess the sizing, cost and viability of the proposed system.
-
It is a key consideration for understanding service level requirements for operational management of the solution.
|
Relationships
| Fulfilled Slots |
|
| Roles | Responsible:
| Modified By:
|
| Tasks | Input To:
| Output From:
|
Description
| Brief Outline |
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.
For each system-wide requirement capture attributes such as the source and priority of the requirements,
as described by the associated requirements management guidance.
|
Illustrations
Key Considerations
-
When documenting system-wide requirements, ensure that the needs of all stakeholders are represented. In
particular, don't forget to include the needs of those responsible for maintaining or supporting the system once
delivered.
-
There are typically 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 approach for capturing and processing every type of requirement.
-
System-wide requirements originate from many places. Documenting the source of the requirement is particularly
important when separating out externally mandated requirements.
-
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.
-
A good quality requirement is one that can be verified, either through testing or some other objective evaluation.
-
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.
|
Tailoring
| Impact of not having |
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.
|
| Reasons for not needing |
If none of the categories of system-wide requirements apply to the project under consideration, this artifact may not
be needed.
|
| Representation Options | This artifact represents influences on the design and delivery of a system which cover a broad range of themes.
Requirements for each theme should be documented under separate headings within a document, or under appropriate category
identifiers in a requirements gathering tool. Categories are often given easy-to-recognize identifiers so individual
requirements can be readily associated with the appropriate category. The format of requirements will vary from
category to category, with some being heavily textual, and others being more structured and quantitative. |
More Information
|
