The requirements review confirms requirements are acceptable and may serve validation and verification together; requirement changes after the first review go through the same or an equivalent review. It checks that each requirement is unambiguous, verifiable, detailed enough for its level and not in conflict with others; derived requirements are consistent with their parents; requirements are consistent with the SSA; derived safety requirements are defined and returned to the SSA; requirements suit the design standards and available technology; component requirements (performance, temperature range, de-rating, screening) fit the safety and reliability requirements; testability, maintainability and manufacturability are addressed; the software/hardware interface is defined; requirements trace upward to the next level as the plan sets; derived requirements capture implementation constraints not verified at a higher level; and omissions and errors are fed back. Completeness and correctness checklists cover upper-level coverage, standards, functions and interfaces, architecture, prohibited behaviours from the safety assessment, operating environment, assumptions and known problems, and whether requirements state what rather than how, are realisable, verifiable and consistent with the safety assessment.
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.
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 2 it maps to, and the evidence behind each claim, over MCP and REST.