Verification examines and judges on evidence that the output of each development phase fulfils its requirements and plans for completeness, correctness and consistency. A software verification plan, created early and extended as needs become clear, documents the criteria, techniques and tools per phase, the activities ensuring correctness and consistency against the phase's inputs, the selection of strategies and techniques (preferring readily analysable methods), the test equipment, the documentation of activities, the evaluation of results, the evaluation of reliability requirements, roles and responsibilities and the degree of coverage required (6.2.4.1 to 6.2.4.9); verification is performed by a party independent to the extent the SIL requires; results are recorded in auditable form and each activity yields a verification report stating pass or the reasons for failure and addressing non-conformities with the requirements, design, component design and SQAP, modules, data, structures and algorithms ill suited to the problem, detected errors or deficiencies, and which items, in which configuration, were verified (6.2.4.10 to 6.2.4.13). The techniques of Tables A.5 to A.8 are selected for the SIL.
This control maps to 1 controls across 1 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 1 it maps to, and the evidence behind each claim, over MCP and REST.