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 | [Technical Specification]
Roles | Responsible: Analyst | Modified By: Analyst
Tasks | Input To: Detail System-Wide Requirements Create Test Cases Design the Solution Implement Solution Outline the Architecture Plan Project Refine the Architecture Assess Results Identify and Outline Requirements Plan Iteration | Output From: Detail System-Wide Requirements Identify and Outline Requirements Implement Solution
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
Templates | System-Wide Requirements Specification
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
Guidelines | Writing Requirements Statements
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. OpenUP Copyright.