An appropriate verification method or technique, with its criteria, is selected for every verification action, ideally assigned as each requirement is written, and documented in a requirements verification and traceability matrix or as verification statements in a verification plan. Each method states how compliance will be shown (including success criteria and how the item is closed), who leads it, when it happens (an event-based milestone rather than a calendar date) and where (any special venue or environment). Four standard methods yield the objective evidence: inspection (examination against documentation, naming the documents or drawings used); analysis, including modelling and simulation, where realistic testing is impractical, and analysis by similarity only when the items match in design, manufacture and use, the earlier verification was equal or stricter and the intended environment is no harsher (naming the analysis, tools, input data and data reduction, with tools agreed with the acquirer); demonstration (a qualitative showing of function with little or no instrumentation, naming witnesses, steps and special resources); and test (quantitative verification under controlled real or simulated conditions, naming witnesses, facility, equipment, conditions, personnel qualifications, data to collect, repeatability criteria and analysis methods). Certification, a written assurance usually given by an independent party against a recognized standard, is sometimes used instead. All of this is recorded in the RTM or in a VCRM.
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.