Each function the system, software system or element must perform is defined, with requirements emerging from analyses of performance and effectiveness, from trade studies, design work, interface definition and cost-benefit work, once reuse has been assessed; for software the required states or modes of operation are identified. Necessary implementation constraints are defined and validated with stakeholders, including those from interfacing and enabling systems and regulation. Requirements tied to risk, system criticality or critical quality characteristics are identified, supported by measures of performance, technical performance measures and quality-in-use measures. The requirements and their rationale are defined; for software they cover data elements, structures, formats and retention; user interfaces, user documentation and training; interfaces with other systems and services; functions and non-functional characteristics including cost targets; transition, migration, installation and acceptance; and per-requirement attributes including rationale, priority, links to the software elements, test cases and information items, how it will be verified, which baselines include it and its assessed risk. Source and rationale are captured for every requirement, and traceability is updated to show how the system or software requirements, derived requirements included, meet the stakeholder requirements; the results are documented in the SyRS and SRS.
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.