• as the essential inputs of the system architecture and design activities;
• as reference for the system validation activities; and
• as a communication means, between the various technical staff that interact within the project.
Definition and Purpose of Requirements
A requirement is a statement that identifies a product or process operational, functional, or design characteristic or constraint which is unambiguous, testable or measurable and necessary for product or process acceptability. (ISO/IEC 2007)
To avoid confusion in the multitude of terms around requirements, consider the following classifications:
• Process role or state: The role the requirement plays in the definition process; for instance, its position in the system block: translated, derived, satisfied; or its state of agreement: proposed, approved, cancelled.
• Level of abstraction: The level within the definition process for the requirement stands; for instance, stakeholder requirement, system requirement, system element requirement.
• Type of requirement: The nature of the requirement itself; for instance functional, performance, constraint, etc.
Requirements Management
Requirements management is performed to ensure alignment of the system and system element requirements with other representations, analysis, and artifacts of the system. It includes ensuring an understanding of the requirements, obtaining commitment, managing changes, maintaining bi-directional traceability among the requirements and with the rest of the system definition, and alignment with project resources and schedule.
There are many tools available to provide a supporting infrastructure for requirements management; the best choice is the one that matches the processes of the project or enterprise. Requirements management is also closely tied to configuration management for baseline management and control. When the requirements have been defined, documented, and approved, they need to be put under baseline management and control. The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of ongoing proposed changes.
Assessment Types for a System Requirement. (SEBoK Original)
Direct Assignment The system requirement from the higher level is directly assigned to a system or a system element for a lower level (for example, the color used to paint visible parts of the product).
Indirect Assignment (Simply Decomposed) The system requirement is distributed across several systems or system elements, and the sum or a more complex calculation for distribution is equal to the requirement of higher level (for example, a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained.
Indirect Assignment (Modeled and Decomposed) The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique, and the resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, a radar detection requirement may be analyzed; lower-level parameters for output power, beam size, frequencies, etc. will then be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.
Derived Requirement (from Design) Such system requirements are developed during the design activities as a result of the decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such, these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.
Classification of System Requirements
Several classifications of system requirements are possible, depending on the requirements definition methods and/or the architecture and design methods used.
Functional Requirements Describe qualitatively the system functions or tasks to be performed in operation.
Performance Requirements Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task.
Usability Requirements Define quality in use such as measurable effectiveness, efficiency, and satisfaction criteria.
Interface Requirements Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges.
Operational Requirements Define operational conditions or properties under which the system is required to operate or exist. This type of requirement includes human factors and ergonomics, availability, maintainability, reliability, security.
Modes and/or States Requirements Define the various operational modes of the system in use and events conducting to transitions of modes.
Adaptability Requirements Define potential extension, growth, or scalability during the lift of the system.
Physical Constraints Define constraints on weight, volume, and dimension applicable on system elements that compose the system.
Design Constraints Define the limits on the options open to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository).
Environmental Conditions Define the environmental conditions to be encountered by the system in its different operational modes. Should be addressed the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environment (e.g. motion, shock, noise, electromagnetism, thermal, etc.), threats societal environment (e.g. legal, political, economic, social, business, etc.).
Logistical Requirements Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.
Policies and Regulations Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.).
Cost and Schedule Constraints Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.