The whole body of stakeholder requirements is analysed against the characteristics for single requirements (5.2.5) and for sets (5.2.6), then ranked and classified using the attributes of 5.2.8, with checklists or standard templates; requirements carried over from legacy systems are judged on whether they apply, are feasible, available, of good quality, cost-effective, valuable and current, and checked for consistency with the rest. Critical performance measures (MOPs and TPMs) are set for judging each stakeholder requirement. The analysed requirements are fed back to the stakeholders at formally scheduled points (reviews, simulation, prototyping) to validate that their needs are captured before resources are committed, with the project authority and the key stakeholders approving the outcome and so fixing the validation criteria. Issues are resolved by negotiation and trade-off with the stakeholders as early as possible, keeping decisions traceable to the stakeholder concerned.
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.