The full set of software requirements is written down, meeting all system and safety requirements to the extent the SIL requires, as a comprehensive document for every subsequent phase, together with the overall software test specification. The software requirements specification expresses required properties rather than procedures: functionality including capacity and response time, reliability and maintainability, safety including the safety functions and their SIL, efficiency, usability and portability; it is complete, clear, exact, unambiguous, verifiable, testable, maintainable and achievable, traceable to the system requirements, system safety requirements, system architecture and external interface documents, understandable to all responsible personnel, includes a plain-language statement of the problem with any formal or semi-formal notation, identifies and documents all interfaces to other systems and operators, details all modes of operation and of behaviour of the programmable electronics including failure behaviour, identifies constraints between hardware and software, states how far the software checks itself and of hardware checking by the software, includes requirements for periodic testing of functions and for testability of safety functions during system validation, clearly identifies safety functions and non-safety functions, and shows that untraceable material has no bearing on safety (7.2.4.1 to 7.2.4.15; techniques of Table A.2). The overall software test specification is developed from it, identifying per required function the test cases with input signals, sequences and values, anticipated outputs and acceptance criteria including performance and quality (7.2.4.16 to 7.2.4.19; Table A.7); both are verified for adequacy against the system documents, internal consistency and the adequacy of the test specification for testing the requirements, recorded in the software requirements verification report (7.2.4.21 and 7.2.4.22).
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.