Aim: a full set of software requirements that satisfies every system and safety requirement, forming the basis for later phases, plus the Overall Software Test Specification. Inputs: the system requirements and system architecture documents, the external interface specifications (software to software, software to hardware), and the quality assurance and validation plans. The Requirements Manager writes the Software Requirements Specification, which states functionality (with capacity and response time), robustness and maintainability, safety (safety-related functions and their SILs), efficiency, usability and portability; records the integrity level derived under clause 4; is complete, clear, precise, unambiguous, verifiable, maintainable, feasible and traceable to all inputs, in forms the people using it understand; identifies or references every interface with other systems and operators wherever a direct link exists now or is foreseen; details all operating modes and how the programmable electronics can behave, above all when failing; records hardware and software constraints; covers software self-checking and software checking of hardware as the system documents require; includes periodic testing of functions as safety requires and testability of all functions during system operation as the system specification requires; names every function with its integrity level; states explicitly any function configurable by application data (which makes the software configurable by data); and uses Table A.2 techniques as the quality plan chose. The Tester writes the Overall Software Test Specification, describing the tests of the finished software with Table A.7 techniques as the verification plan chose, and for each function the input signals, sequences and values, expected outputs, success criteria including performance and quality, and the response to out-of-specification interface inputs unless covered in integration testing. The Verifier's requirements verification report checks the specification against the system requirements and quality plan, its readability, traceability and specific content, the adequacy of the overall test specification, any extra activity for requirements that cannot be tested, internal consistency and the treatment of hardware and software constraints.
This control maps to 10 controls across 4 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 10 it maps to, and the evidence behind each claim, over MCP and REST.