Validation and derived requirements are intimately related: the purpose of validation is to show that derived requirements are correct and complete, and the purpose of identifying derived requirements is to identify which requirements must be validated. Thus a discussion of either topic must by necessity discuss the other, since neither can exist in isolation.
The DO-254 definition of a derived requirement can be paraphrased as a requirement that is created as the result of the hardware design process. This definition is somewhat ambiguous, which often leads to confusion and questions: How does the design process create derived requirements? What are the characteristics of derived requirements? How are derived requirements identified and differentiated from nonderived requirements?
Derived requirements are created when functions are added to the hardware to support design decisions, when higher level functions are decomposed as they flow down to lower levels, and when a function is created that does not support a higher level function. The common characteristic of all of these requirements is that they contain new information that must be assessed—in other words validated—to confirm that the new information is correct, complete, and consistent with the intended functionality of the system (as expressed by system requirements).
In the software domain, Section 5 of DO-178B states that a derived requirement is a requirement that does not directly trace to a higher level requirement. This differs significantly from the definition in DO-254. As stated in previous chapters, the inertia of the initial DO-178B connotation of a derived requirement often finds its way into the hardware domain. This is understandable given that for many years the DO-178B definition and usage was the only one available. Considering the widespread use of the DO-178B definition and usage and its potential to create problems with hardware, it is appropriate to discuss that definition and how it differs from the DO-254 definition in both context and common use, and how those differences can affect the processes in DO-254.
The definition of derived requirements found in the glossary of DO-178 is almost identical to the one found in the glossary of DO-254. However, while Section 5 of DO-178B restates the definition as requirements that do not directly trace to a higher level requirement, DO-254 does not. Instead, DO-254 and its processes stick to the glossary definition, which allows for derived requirements that trace to parent requirements. In fact, instead of stating that derived requirements do not trace to higher level requirements, DO-254 does the opposite: paragraph 5.1.2-8 in DO-254 specifically states that requirements should be traceable to the next higher level of requirements, and that derived requirements should be traced as far as possible through the hierarchical levels. This statement leaves no doubt that hardware derived requirements can, do, and are intended to trace to higher level requirements.
The DO-254 definition is highly appropriate for hardware requirements because the decomposition of functionality (into derived requirements that trace to parent requirements) through successively lower levels of the system is one of the basic design methodologies used in hardware system design. Without this traceability from parent requirements to lower level derived requirements, tracking functionality as it decomposes from the system to the component level has considerably less meaning and loses much of its usefulness.
When hardware functionality flows downward it often gets decomposed and elaborated, and these decomposed and elaborated functions do (and should) trace to their higher level counterparts. This is a core aspect of the design of large hardware systems, and the traceability through the levels of hardware is how the implementation of the system functions is ensured and managed.
So hardware derived requirements normally trace up to a parent, or higher level, requirement as the flow down of system functionality is managed through the decomposition of the functionality captured in requirements. Under these conditions the two definitions of derived requirements will conflict and result in reduced design assurance in hardware because a significant portion of the hardware derived requirements will be misidentified as being non-derived and will therefore not be validated. Derived requirements may also trace up to—in other words be derived from—parent hardware design features and the design decisions that created them. This is worth noting because the ability to trace the functionality captured in derived requirements is one of the most useful benefits of traceability: not only does it allow tracking and confirming system functionality through and down to the lowest levels of hardware during the design process, it also greatly facilitates the tracking and management of future changes to the design. If the DO-178 connotation of derived requirements is used indiscriminately with hardware, much of the utility of traceability is lost, leaving a significant gap in design assurance both during initial development and when making future changes.
Thus traceability is simply an aspect of functional decomposition that provides a useful means for keeping track of system functions but actually has nothing to do with whether a requirement should be validated, so using traceability to identify a derived requirement is neither effective nor sensible for hardware.
Using the DO-178 connotation of derived requirements will typically cause a conundrum: if derived requirements are defined as requirements that do not trace upward, they will lose their connection with the higher level functions that spawned them, rendering the traceability useless for tracking functions from the system level. But if the traceability is used correctly to trace functionality from the system level, the derived requirements will have to trace to their higher level functions, robbing them of their derived status and thereby eliminating them from validation. Thus if the DO-178 connotation of a derived requirement is used with the DO-254 development processes, there is a danger that the validation process will be undermined or even break down altogether. At the very least it can mean a choice has to be made between having effective validation or effective traceability.
One way to get beyond this conflict of definitions and plug the resulting holes in hardware design assurance is to find a definition for derived requirements that does not rely on characteristics that are irrelevant or even contrary to the goals and objectives of DO-254 and its processes. As stated earlier, validation and derived requirements are intimately related, so going back to the objectives of the validation process in DO-254 can help understand what a derived requirement really is, and in the process “derive” a definition that is both sensible and practical.
The objective of validation is defined in DO-254 as verifying that derived requirements are correct and complete. In the DO-254 realm, only derived requirements are validated so the point of identifying requirements as being derived is to identify the requirements that should be validated for completeness and correctness, and they should be validated because they contain some kind of information that must be verified for integrity. If the validation objective is turned around, a suitable (and in many respects more useful) definition of a derived requirement is a requirement that needs to be validated to ensure that it is correct and complete. This definition can be refined to state that a derived requirement is any requirement that contains information that must be validated.
The above definition has some advantages over both the glossary definition and the DO-178 connotation: it is more easily applied than the glossary definition, it is independent of traceability (as it should be), and it is derived from and therefore satisfies the objectives of DO-254 and validation in particular.
At the aircraft level, all functions (again, expressed as requirements) are originated and thus those requirements need to be validated. The validation of these requirements ensures that this starting set of requirements is complete and correct, ensuring that the aircraft function starts with the right set of requirements that fully specifies the functionality from the aircraft level perspective.
At the next lower level of the system, some of the aircraft level functions (i.e., requirements) are flowed down unchanged (allocated) if the functionality in those requirements is already appropriate for the next lower level. Some of the functions (and their requirements) are decomposed to express their constituent functionality in terms that are appropriate for the next lower level, creating derived requirements in the process, and new functions that are not directly related to the higher level requirements are added as well, creating more derived requirements. Higher level design features will also dictate the functionality of lower level hardware, normally to define the interaction between the higher and lower level hardware, or integration of the lower level hardware into the higher level hardware, creating more derived requirements. This process is repeated at every level of the system. Figure 5.1 shows the requirements decomposition and allocation, and addition of derived requirements.
Derived requirements can originate or add functionality at all levels of abstraction or design. These derived requirements need to be validated at the level at which they were created to ensure that they are correct, complete, consistent with higher level functionality, and appropriate for their level in the system.
FIGURE 5.1 Requirements Flow Down
Derived requirements must also be assessed from the system and aircraft perspective to ensure that there is no safety impact. The worst case scenario would be if a function is added to the hardware that is in a higher level functional failure path.
Derived requirements should be identified as being derived, and as with non-derived requirements they should also be flagged if they are related to system safety. Derived requirements should also include a justification, or in other words validation data, that is used to justify the requirement and its parameters. Ideally this justification will include enough information to allow a reviewer to determine whether the derived requirement is both correct and complete. Validation of the requirement should include an analysis of the justification to make that determination. If the reviewer cannot determine that the requirement is correct and complete through an analysis of the justification, then it is normally a sign that the justification is incomplete.
Even arbitrary specifications should include a justification that explains how the arbitrary value was selected. For example, if an FPGA output drives the clock input of an ADC, and the idle value of the clock (the logic level of the clock when a clock signal is not being generated) can be either high or low without affecting the functionality of the ADC, the requirements can arbitrarily specify that the idle value be set to one value or the other when the clock is not being generated. While the specified logic level may be arbitrary, it still should be substantiated by describing the justification for the arbitrariness of the decision. In this case, the justification for the requirement would be that the particular ADC being driven by the clock can accept either a high or a low for the idle value, so it was arbitrarily set to one value. In the case of arbitrary specifications, the very fact that the specification is arbitrary is important information that needs to be documented so that future changes to the design can take into account that the specified value can be changed without affecting functionality. If the arbitrariness of the design is not documented, engineers working on the system in the future, or using the FPGA as previously developed hardware in a new application, will not have all of the pertinent information at their disposal and therefore will not be in a position to make fully informed decisions.
While validation can be achieved through review, analysis, or even test, the most common method to validate derived requirements for airborne electronic hardware is review. The review of derived requirements can be performed as a separate activity with its own criteria and results, or may be combined with the review of other non-derived requirements, as long as the review criteria are clear about which type of requirements they apply to. In some cases, it may be easier to review all requirements, derived or not, with all review criteria. An advantage of this approach is that it will assess allocated (directly flowed down) requirements for their applicability and appropriateness for the current level of the system, ensuring that all functions and the requirements that express them are appropriate for that level of hardware. Ignoring allocated functionality and requirements will not confirm that they are appropriate, possibly resulting in requirements that are inappropriate for the hardware level at which they exist.
The review criteria for validation should include a check that:
• Each derived requirement is correct
• Each derived requirement is complete
• The justification provides a rationale for the derived requirement
• Each derived requirement has been assessed for impact on system function
• Each derived requirement has been assessed for impact on aircraft function
• Each derived requirement was properly identified as a derived requirement
• All non-derived requirements were properly identified as non-derived
Reviewers performing the validation against the derived requirement review criteria should include team members representing:
• The author of the requirements for the end item (PLD or circuit requirements)
• The designer of the parent hardware—especially when the derived requirement stems from a design decision
• The system requirements
• The aircraft requirements
• Safety
• Designee or certification authority for airborne electronic hardware
• Designee or certification authority for the system
When a derived requirement is added for support of a design decision, for example if PLD requirements for how the PLD should interface to an analog to digital converter (ADC) device are derived from the design decision to use the PLD to control a particular ADC device, the review should assess the derived requirements against the design data of the upper level design. For a PLD, this could translate into reviewing PLD requirements alongside data sheets for integrated circuits that are peripheral to the PLD. If the circuit card designer decides to use a specific circuit that the PLD drives, then the PLD outputs need to meet the signal levels and timing specified for that circuit.
When a derived requirement is added to support manufacturing or test, then the derived requirements need to be reviewed against the specification of the manufacturing or test equipment.
Analysis is used extensively in validation. Even a requirements review will require some amount of analysis to determine whether a derived requirement is correct and complete, so in reality review and analysis often go hand in hand. If a derived requirement contains a translation or conversion of performance parameters, such as converting a hydraulic actuator displacement parameter at the system level to its equivalent voltage or current control signal output at the electronic box level, analysis can be used to confirm that the conversion from mechanical to electrical parameters was accurate. Note that test can also be used to validate the conversion if a suitable test setup is available; in fact, test is arguably the preferred method since it provides a real world conversion between mechanical and electrical parameters.
Test can also be used to validate requirements that specify design features (implementation) rather than functionality. As discussed in the verification chapter, implementation requirements can unintentionally interfere with the independence of verification, and also prevent verification from showing that the hardware implements its intended functionality because the design rather than the intended functionality is captured in the requirements. When this happens the burden of proving intended functionality falls upon validation, and the only real way to show that the hardware is meeting its intended functionality is to test the hardware in much the same way that verification would. Validation through test can be conducted on prototype hardware to show that the design being specified will perform as intended. Validation through testing of finished hardware will require that the hardware be designed and built against unvalidated requirements, which can result in rework if the requirements were in error.