In product development the supplier documents how the system will function and be designed so as to satisfy the defined requirements, across software, hardware and configuration. Functional specifications set out, clearly and in full, what the product will do so that it can be tested objectively, and design specifications build on them with enough detail for development to proceed. According to complexity and risk, specifications may be one document or several, or records held in tools; they are reviewed and approved, traceable to one another and kept under change control with attention to changes that ripple into other documents. Suppliers do not have to use the guide's names for specifications if they achieve the same aim, and where the supplier configures a product or builds a custom application it agrees with the regulated company how many specifications there will be and in how much detail.
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.