First of all, the definition of derived requirements was updated in DO-178C/ED-12C, the focus being more on the content of the requirements rather than on the traceability aspects: It is now considered that some “traceable” requirements can be identified as derived because they specify behavior beyond that specified in higher level of requirements. It should be noted that this does not really change the previous definition, as the term “may be not traceable” already opened the door to the same interpretation. FAQ#36 of DO-248C/ED-94C was reworked to provide examples of the two “classes” of derived requirements.
A correct application of this concept (derived requirements) requires good experience and maturity within the software engineering team: The purpose of the traceability feature is both to enable the verification of the complete implementation of the higher level of requirements and give visibility on the derived requirements, as now clarified in section §5.5 (new). Therefore, beyond the accurate definition/identification of the derived requirements, it is very important to define a traceability approach that actually supports and complies with the above purpose.