Because stakeholders view the system at different levels, requirements are also defined and documented below the system of interest by allocating system requirements to system elements during architecture definition, iterating with architecture and design to settle trade-offs. As elements are defined, derived requirements are written to state relationships between architectural elements, to give clarity at the lower level of abstraction, or to impose design constraints or performance levels on elements, by applying the requirements definition processes recursively; some requirements, such as throughput that depends on hardware, software, people and environment together, can only be derived once part of the architecture exists. The depth of analysis may vary (off-the-shelf elements may need less), but critical requirements, those with high risk or affecting public safety, the environment or health, are always analysed more rigorously. Iteration back into requirements is expected for genuine change of need, feasibility and technology risk, defects or obsolescence in non-developmental elements, reverse engineering for regulatory compliance, and because requirements are never perfect.
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.