DO-254 / ED-80 - Design Assurance Guidance for Airborne Electronic Hardware
Section 5: Hardware design processes – DO-254 / ED-80 - Design Assurance Guidance for Airborne Electronic Hardware

DO-254 / ED-80 - Design Assurance Guidance for Airborne Electronic Hardware 5.1.1: 5.1.1 Requirements capture objectives

Requirements capture identifies and records the item's requirements, including derived requirements arising from architecture, technology, basic and optional functionality, environment and performance, and those set by the system safety assessment. Its objectives are that requirements, including allocated PSSA requirements and derived requirements coming out of the hardware safety assessment, are identified, defined and documented; derived requirements go back to whichever process needs them; and omissions and errors are passed to the appropriate process for resolution. Establishing the method of tracing verification results to requirements during capture is desirable.

Maintained by Gerard Blokdyk

What else in your programme already covers this

This control maps to 2 controls across 2 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.

  • A-2.1 High-level software requirements produced from the allocated system requirements

Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.

Other controls in Section 5: Hardware design processes – DO-254 / ED-80 - Design Assurance Guidance for Airborne Electronic Hardware

Query this from an agent

The graph holds this control, the 2 it maps to, and the evidence behind each claim, over MCP and REST.