System Requirements

From SEBoK
Revision as of 20:52, 4 June 2011 by Afaisandier (talk | contribs) (5.1. Introduction, Definition and Purpose of System Requirements)
Jump to: navigation, search

5.1. Introduction, Definition and Purpose of System Requirements

Introduction - This section provides knowledge about the notion of system requirements, the translation of stakeholders’ requirements into System Requirements, the relationships between the system requirements of the system-of-interest and those of its sub-systems or system elements, and the related SE activities and methods. The set of baselined System Requirements represents the problem from a supplier and a designer point of view, and is one of the major outcomes of these activities.


Definition and Purpose - A requirement is “a statement that identifies a system, product or process characteristic or constraint, which is unambiguous, clear, unique, consistent, stand‐alone (not grouped), and verifiable, and is deemed necessary for stakeholder acceptability.” (INCOSE 2010, p. 362). The System Requirements are all of the requirements at the “system level” that have been properly translated from the list of stakeholders' requirements. The system requirements will form the basis of system design, verification, and stakeholder acceptance. In this context, the “stakeholders” include, but are not limited to, end users, end user organizations, supporters, developers, producers, trainers, maintainers, disposers, acquirers, customers, operators, supplier organizations, accreditors, and regulatory bodies. (ISO/IEC June 2010)



5.2. Principles about System Requirements

5.2.1. Translation of Stakeholder Requirements into System Requirements

Quite often, the set of Stakeholder Requirements could contain vague, ambiguous, and qualitative “user-oriented” requirements that are difficult to use for design or to verify. Each of these requirements may need to be further clarified and translated into “engineering-oriented” language to enable proper design and verification activities. The System Requirements resulting from this translation are expressed in technical language useful for design; unambiguous, consistent, with no contradiction, exhaustive, and verifiable. Of course, close coordination with the stakeholders is necessary to ensure the translation is accurate.

As an example, a Stakeholder Requirement such as, "The users expect a comfortable means of transportation" will be translated in a set of System Requirements specifying thermal monitoring conditions, vibration level, acoustic ambiance, ergonomic characteristics of seats, etc. as measurable characteristics.

5.2.2. Utility of requirements definition

ADD ACTION RELATED TO COMMENT 3038

5.2.3. Traceability and Allocation of System Requirements during design

Requirements traceability provides the ability to trace information from the origin of the stakeholder requirements at the top level to the lowest level of the system hierarchy. Traceability is also used to provide an understanding of the extent of a change as an input to impact analyses conducted with respect to proposed engineering improvements or requests for change.

ADD ACTION RELATED TO COMMENT 827, 2226

During design, the allocation of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate:

  1. Direct allocation: the system requirement from the higher level is directly allocated to a sub-system or a system element (for example, the color used to paint visible parts of the products)
  2. Indirect allocation: the System Requirement is distributed across several sub-systems and the sum or a more complex calculation 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 “allocation budget” for each allocation must be maintained.
  3. Derived allocation: the System Requirement is allocated to several sub-systems using an analysis or mathematical modeling technique, and the derived design parameters are allocated to the appropriate sub-systems (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 allocated to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.
  4. Derived or Design requirement: such System Requirements are developed during the design activities as a result of decision of the design team, not the stakeholder community. These requirements may include the use of Commercial-Off-the-Shelf (COTS) items, existing subsystems in inventory, common components, and similar design decisions in order to produce a “best value” solution for the customer. As such, these design requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or constraint.

5.2.4. Classification of System Requirements

ADD ACTION RELATED TO COMMENT 406

Several classifications of System Requirements are possible, depending on the requirements definition methods and/or the design methods used. (ISO/IEC June 2010) provides a classification summarized below – see references for other interesting classification:

  1. Functional Requirements: describes qualitatively the system or system element functions or tasks to be performed.
  2. Performance Requirements: defines quantitatively the extent, or how well, and under what conditions a function or task is to be performed. 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.
  3. Interface Requirements: defines how the system is required to interact with external systems (external interface) or how system elements within the system, including human elements, interact with each other (internal interface).
  4. Design Constraints: defines 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 on-line repository).
  5. Non-Functional Requirements: These specify requirements under which the system is required to operate or exist or its properties. They define how a system is supposed to be. Quality requirements and human factors requirements are examples of this type.
  6. Process requirements: These are stakeholder, usually acquirer or user, requirements imposed through the contract or statement of work. These requirements do not directly address the end-item system, but rather how the end-item system is developed and provided. Process requirements include compliance with national, state or local laws, including environmental laws; administrative requirements; acquirer/supplier relationship requirements; and specific work directives. Process requirements may also be imposed on a program by corporate policy or practice. System or system element implementation process requirements, such as mandating a particular design method, are usually captured in project agreement documentation such as contracts, statements of work (SOW), and quality plans.

ADD ACTION RELATED TO COMMENT 1155, 2743, 2744, 2745, 2746






Article Discussion

[Go to discussion page]