The full body of system or software requirements is analysed to confirm that each statement and the set as a whole are well formed against the characteristics of 5.2.5 (single requirements) and 5.2.6 (sets), using the architecture to check that every feature and function it contains is represented; reused requirements are assessed and checked for consistency; the classifications of 5.2.8 assist, and the verification process's preparation activity is used to define, plan and run requirements verification. Critical performance measures are defined for assessing each system requirement. The analysed requirements are fed back to the applicable stakeholders for review to validate that stakeholder requirements were transformed correctly, using stakeholder reviews with checklists, prototypes at a fidelity matched to their purpose, modelling and simulation (including architecture views), conceptual models of the problem domain, or formal models for critical functions. Problems in the set, whether gaps, conflicts, defects or weak statements, are found and settled through continued negotiation.
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.