Software components are designed to achieve what the software design specification requires, as far as the SIL requires. A software component design specification per component identifies every lowest-level component traced to the upper level, its detailed interfaces with the environment and other components with inputs and outputs, its SIL, and its detailed algorithms and data structures, self-consistent and sufficient to implement the component, with the design method possessing features for abstraction, modularity and complexity control, clear expression of functionality, information flow, sequencing and timing, concurrency and data structure, human comprehension, verification and validation and maintenance (7.4.4.1-6; Table A.4). A software component test specification is written defining the required test coverage (7.4.4.7 to 7.4.4.10; Table A.5). Both are verified for adequacy against the design specification, the test specification as test cases for the component design, the decomposition into components judged for whether the performance requirements can be met, testability, readability and maintainability, recorded in the software component design verification report (7.4.4.11 to 7.4.4.13). At Basic Integrity the component design, test specification and verification report are not required (Table A.1).
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.