Well-formed requirements carry descriptive attributes, held with each requirement in the chosen repository, that help identify, understand and manage them: a unique identifier that is never changed or reused, even when the requirement is revised or deleted, so that tracing stays intact; a version indicating which text is being implemented and how volatile it is; an owner who maintains it, approves its changes and reports its status; stakeholder priority, agreed among the stakeholders on a scale or as high, medium or low, to inform trade-offs; a risk value, including risk inherited from the parent and risk from immature technology; the rationale, pointing to the analysis, trade study, model or simulation behind it; the assumed difficulty; and a type (functional and performance, interface, process, quality or non-functional, usability and quality in use, human factors) used to group requirements for analysis and allocation.
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.