Derived Requirement are requirements that are not explicitly stated in the set of Stakeholder requirements, and yet is required to satisfy one or more of them. They also arise from constraints, consideration of issues implied but not explicitly stated in the requirements baseline, factors introduced by the selected architecture, Information Assurance (IA) requirements, and the design. Derived requirements are developed through Requirements Analysis as part of the overall Systems Engineering Process (SEP) and are part of the Allocated Baseline.

Definition: Derived requirements are constraints developed during the design activities which arise as a result of the selected solution but not explicitly stated in the requirements baseline.

Derived Technical Requirements

Derived Technical Requirements are those that result from the analysis and allocation of Technical Requirements to logical functional architectures that are developed as part of the Requirements Analysis process; or from the Analysis of Alternative (AoA) solutions done later as part of the Architecture Design Process. Derived Technical Requirements become the basis for the solution-specified requirements for the system model and are a ‘design-to’ requirement for the system.

Steps for Developing Derived Requirements

The process of developing deriving requirements is basically the same as for any sub-system. The steps are outlined below, with the addition of “complex electronics-specific issues” to consider: [1]

• Step 1: Allocate system and/or sub-system requirements to complex electronics. This is usually more than a cut-and-paste of the higher-level requirements because those requirements are often implemented by multiple sub-systems. The requirements have to be decomposed to state the specific requirements for the complex electronics.
• Step 2: Assess the safety, reliability, maintainability, and similar requirements for their implications for complex electronics. Derive any specific requirements for complex electronics. For example, complex electronics may need to meet a particular Mean-Time-To-Failure (MTTF) requirement. Or, there may be an overall safety requirement that all sub-systems must have a built-in self-test capability.
• Step 3: Consider the effects of the chosen system and sub-system architecture, the selected electronics, standards, procedures, and processes. Derive any requirements for the complex electronics that are necessary. For example, the manufacturing process for an ASIC may constrain the design options. These constraints should be included as derived requirements. Also, the selection of a communications method between sub-systems may generate specific requirements for a complex electronic device that uses the communications method.
• Step 4: Consider the effects of faults and anomalies in the complex electronic device on other system components, and also the effect of failures elsewhere in the system on the complex electronic device. If a Failure Modes and Effects Analysis (FMEA) was performed, use that as a starting point. Ask yourself:
  • Should anomalies in the complex electronics be handled by the device itself or by a higher-level component?
  • What anomalies or faults can be tolerated (i.e. no action is taken)?
  • If the device has an anomaly or failure, will it affect the safety of the system?
  • What failures or faults elsewhere in the system will have an impact on the device? How severe would the impact be? What actions should this device take?
• Step 5: Identify all interfaces between the complex electronics and other parts of the system. This includes requirements for signal levels and timing. Be sure to specify data formats and protocols.
• Step 6: Consider environmental constraints, such as radiation, thermal environment, and mission duration. Does the system need a mitigation strategy for Single Event Upsets and/or total radiation dose? If so, what part will the complex electronics play in that strategy? Has the complex electronic device been allocated a power dissipation budget?
• Step 7: Consider any testability requirements, and how they will be met for the complex electronics. What testing can be done on the bench? What testing will require a system component, or the complete system? Do any special access pins or ports need to be defined, to aid in testing?
• Step 8: Assess any off-the-shelf design components (e.g., IP cores) that will be used. Consider the functions of the component, and whether any will remain unused. Assess any unused functions for impact on the system if they were inadvertently executed, and add requirements to prevent this situation if appropriate. Add derived requirements for any constraints imposed by the off-the-shelf component on the complex electronics design. Are there any constraints imposed by the tools used to develop complex electronics? If so, these constraints should be captured as derived requirements.

Example Derived Requirement

The missile shall be aimed within 2 degrees of the target so that the warhead terminal seeker can lock on and perform the terminal intercept. [1]

Deriving Electronic Requirements

Derived Electronic Requirements are specific requirements for an electronic device that will be derived from the system requirements, safety analyses, system architecture, performance requirements, and the operational environment.

AcqLinks and References:

• Defense Acquisition Guidebook (DAG)
• Requirements Development Checklist
• DAU Systems Engineering Fundamentals Guide
• Space and Missile Systems Center (SMC) Systems Engineering Primer & Handbook
• NASA Systems Engineering Handbook (large 9M file)
• White Paper: Writing a Requirements Document “For Multimedia and Software Projects” by Rachel S. Smith
• White Paper: Requirements Development, Verification, and Validation Famous Failures by Bahill & Henderson

Updated: 7/1/2021

Rank: G1.0