Requirements at every level (stakeholder, system and element) are written as well-formed statements. Each names its subject (for example the system or the software) and states either an action or a constraint on that subject; it answers a problem, objective or stakeholder concern, carries measurable conditions where they apply, is bounded by constraints, expresses a capability or performance of the system rather than of its user or operator, and can be verified. Before writing starts the project agrees the keywords that mark binding text: 'shall' for requirements, 'will' for facts, futurity or purpose, 'should' for goals that are not requirements and 'may' for allowances; 'must' and 'shall be able to' are avoided, negative and passive phrasing is avoided, and requirements-engineering terms are defined once and used consistently. Conditions and constraints are captured as attributes of the requirement, and requirements may be ranked or weighted by priority.
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.