Constraints on any solution are identified, whether imposed by external or organizational stakeholders (plans, technical measures, maturity, regulation, life cycle cost, staffing), by interacting or enabling systems, by later life cycle work such as transition into service, operation or maintenance, or by measures of effectiveness and suitability; examples are a budget ceiling or a maintenance strategy driving reliability or built-in test. Requirements and functions bearing on critical quality characteristics (for example assurance, safety, security, environmental or health concerns) are singled out. Stakeholder requirements are then written so that they agree with the concepts, the scenarios, the user interactions, the constraints and those critical characteristics, after assessing opportunities to reuse existing requirements, using several elicitation techniques (workshops, interviews and questionnaires, observation, document review, market or competitor analysis, simulation, prototyping and modelling, benchmarking, organizational analysis) and applying the rules for well-formed requirements in 5.2, with stakeholders involved in checking the statements.
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.