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. The specific requirements for an electronic device will be derived from the system requirements, safety analyses, system architecture, performance requirements, and the operational environment. The objectives of the requirements capture and derivation/decomposition process are: 
- Identify, derive, and document the requirements for complex electronics
- Assess derived requirements as part of the system requirements engineering processes
- Correct omissions and errors in requirements
Steps for Developing Deriving Electronic Requirements
The process of deriving requirements for electronics is basically the same as for any sub-system. The steps are out-lined below, with the addition of complex electronics-specific issues to consider: 
- 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 the complex electronics. Derive any specific requirements for the complex electronics. For example, the 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 the complex electronics? If so, these constraints should be captured as derived requirements.
AcqLinks and References:
- Defense Acquisition Guidebook (DAG) – Chapter 4
- 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)
- EIA-632 “Processes for Engineering a System” – 7 Jan 99
- 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
- Website: DAU – Systems Engineering
- Website: International Council on Systems Engineering (INCOSE)