Types of Requirements

Reading

  1. NASA System Engineering Handbook NASA-SP-2007-6105-Rev-1, Section 4.2.2.1 Types of Requirements
  2. AcqNotes Requirements Development – Requirement Types

Requirement Types

Functional requirements

Functional requirements define what functions need to be performed to accomplish the objectives. For example “The Thrust Vector Controller (TVC) shall provide vehicle control about the pitch and yaw axes.” This statement describes a high-level function that the TVC must perform. The technical team needs to transform this statement into a set of design-to functional and performance requirements. [1]

Performance requirements

Performance requirements define how well the system needs to perform the functions. Here are the performance requirements associated with the functional requirements example. [2]

• The TVC shall gimbal the engine a maximum of 9 degrees, ± 0.1 degree.
• The TVC shall gimbal the engine at a maximum rate of 5 degrees/second ± 0.3 degrees/second.
• The TVC shall provide a force of 40,000 pounds, ± 500 pounds.
• The TVC shall have a frequency response of 20 Hz, ± 0.1 Hz.

Be careful not to make performance requirements too restrictive. For example, for a system that must be able to run on rechargeable batteries, if the performance requirements specify that the time to recharge should be less than 3 hours when a 12-hour recharge time would be sufficient, potential design solutions are eliminated. In the same sense, if the performance requirements specify that a weight must be within ±0.5 kg, when ±2.5 kg is sufficient, metrology cost will increase without adding value to the product.

Derived Requirements

Requirements that are implied but not explicitly stated or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.

Requirements arising from constraints, consideration of issues implied but not explicitly stated in higher-level requirements, factors introduced by the selected architecture, and the design. [3] For example, a requirement for long range or high speed may result in a design requirement for low weight. [4]

Allocated Requirements

A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items. By definition, these are interface requirements and may include mass properties, structural/mechanical, fluid, electrical (power), electronic (signal), software and data, environment (ex. dimensions, center-of-mass, field-of-view, stiffness), electromagnetic effects (electromagnetic compatibility, electromagnetic interference), to name a few. [5]

Specifications and Design Requirements

The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals. [6] All applicable standards must be referenced or included in the product specifications.

A specification provides sufficient depth, guidance, and constraints to build/purchase the design.

Technical Requirements

Technical Requirements are the customer and stakeholder needs that have been translated into a complete set of validated requirements for the system, including all interface requirements. [7]

  • Interface
    • The external interface forming the boundary between the product and the rest of the world.
    • Types of interfaces include: operational command and control, computer to computer, mechanical, electrical, thermal, and data.
  • Plus
    • Constraints… Environmental, Reliability, Safety, Programmatic (including cost, schedule), Institutional

Endnote

1) NASA System Engineering Handbook, NASA SP-2016-6105 Rev2 supersedes SP-2007-6105 Rev 1 dated December, 2007 Section 4.2.1.2.2 Define Requirements
2) ibid, Section 4.2.1.2.2 Define Requirements
3) ibid, Section 4.3.1.3 Outputs and Appendix B Derived Requirements
4) Wikipedia, Requirements analysis
5) NASA System Engineering Handbook, NASA SP-2016-6105, Section 3.2 Interface Requirements
6) Wikipedia, Requirements analysis
7) NASA System Engineering Handbook, NASA SP-2016-6105, Section 4.4.1.1 Inputs

Example of Functional and Performance Requirements

Initial Functional Statement

  • The Thrust Vector Controller (TVC) shall provide vehicle control about the pitch and yaw axes.

This statement describes a high-level function that the TVC must perform. The technical team needs to transform this statement into a set of design-to functional and performance requirements.

Functional Requirements with Associated Performance Requirements

  • The TVC shall gimbal the engine a maximum of 9 degrees, ± 0.1 degree.
  • The TVC shall gimbal the engine at a maximum rate of 5 degrees/second ± 0.3 degrees/second.
  • The TVC shall provide a force of 40,000 pounds, ± 500 pounds.
  • The TVC shall have a frequency response of 20 Hz, ± 0.1 Hz.

Requirement Types and Flowdown

In this section, I will look at how these requirement types fit within the temporal and hierarchical structure (Figure 1) of a NASA flight project.

Once the customer (e.g., NASA HQ) receives “Mission Authority” (funding), mission objectives and requirements are finalized and given to the implementing organization (e.g., JPL). Along with mission definition, the implementing organization is presented with programmatic constrains, including cost, schedule, and if applicable mission classification.

The implementing organization then translates these mission performance requirements and constants into project/system functional requirements. To these functional requirements, the implementing organization adds institutional constraints, assumption, environmental, and other design requirements and guidelines to a depth sufficient to write project/system performance requirements.

These project/system performance requirements are then further decomposed and allocated among the elements and subsystems. This decomposition and allocation process continues until a complete set of design-to requirements is achieved. At each level of decomposition (system, subsystem, component, etc.), the total set of derived requirements must be validated against the stakeholder expectations or higher level parent requirements before proceeding to the next level of decomposition.

Figure 1. Requirement Flowdown