A requirements specification sets out what the system has to do. The regulated company owns it, although a supplier or other third party may draft it; subject matter experts review it and the process owner approves it, with the system owner and the quality unit commonly approving as well. It states exactly and unambiguously the functions and facilities needed, any constraints, and the regulatory and documentation requirements. Under Agile methods the requirements may be built up step by step, and the backlog items then serve as the requirements specification, as Appendix D1 explains.
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.