Explicit agreement on the system or software requirements is obtained, mostly through requirements reviews and negotiation led by the requirements owner. Traceability of the system or software requirements is maintained so that the source of each requirement can be recovered and the effect of a change predicted; it includes interface requirements and underpins coverage analysis (every stakeholder requirement met in the design, every low-level requirement justified), compliance analysis and impact analysis. Each requirement is traceable downward to lower-level requirements (through allocation, since the derived requirements come later), to the logical or physical architecture, to the hardware and software elements that implement it and to the verification entities that satisfy it with their supporting models and analyses, and upward to its parent requirements or the stakeholder needs it came from; a requirement that came out of a trade study or design study traces to that study, and the study traces to the higher-level requirements that informed it. Bidirectional traceability supports integrity, tracking of coverage, compliance and complexity, review of relationships between layers, and later change. The requirements are configuration controlled, with rationale, decisions, assumptions, change history and categorization recorded, and the SyRS and SRS are provided as baselined items.
This control maps to 3 controls across 3 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 3 it maps to, and the evidence behind each claim, over MCP and REST.