Capture should document the system requirements allocated to the item (functionality, performance, segregation, built-in test, testability, interfaces, environment, test and maintenance, power, physical characteristics); identify PSSA safety requirements (assurance levels, probability requirements for malfunction or loss, architectural and functional safety attributes); identify design constraints arising from technology, standards, procedures, the design environment, guidance and production processes; determine derived requirements needed for implementation, uniquely identifying those from the safety assessment with safety implications (for example protection of higher-level functions from lower-level anomalies at their interface, input data ranges and bit states, power-up and reset states, supply demands, time-related functions, all possible state transitions, signal timing in normal and worst case, noise and cross-talk, glitches in asynchronous logic, control of unused functions); feed derived requirements back to the SSA; state requirements quantitatively with tolerances and free of design or verification solutions; return omissions and errors to the system process; and make requirements traceable to the next higher level, with derived requirements flagged and traced down the hierarchy as far as they go.
This control maps to 6 controls across 3 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
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.
The graph holds this control, the 6 it maps to, and the evidence behind each claim, over MCP and REST.