|
18 | 18 | .. document:: [Feature Name] Architecture Inspection |
19 | 19 | :id: doc__feature_name_arc_inspection |
20 | 20 | :status: draft |
21 | | - :version: 2 |
| 21 | + :version: 3 |
22 | 22 | :safety: ASIL_B |
23 | 23 | :security: YES |
24 | 24 | :realizes: wp__sw_arch_verification |
@@ -85,26 +85,20 @@ Architecture Inspection Checklist |
85 | 85 | - Remarks |
86 | 86 | - Issue link |
87 | 87 | * - ARC_01_01 |
88 | | - - Is traceability from software architectural elements to requirements and to architectural elements at other levels (e.g., from a component to an interface) established in accordance with the “Relations between the architectural elements” described in :need:`doc_concept__arch_process`? |
89 | | - - Traceability should be checked automatically by tooling in the future. This item will be removed from the checklist once the requirement (:need:`Correlations of the architectural building blocks <gd_req__arch_build_blocks_corr>`) is implemented. Refer to `Tool Requirements <https://eclipse-score.github.io/docs-as-code/main/internals/requirements/requirements.html>`_ for the current status. |
90 | | - - |
91 | | - - |
92 | | - - |
93 | | - * - ARC_01_02 |
94 | 88 | - Does the software architecture design take into account all requirements allocated to the architectural element, including functional, non-functional, safety, and security requirements, as well as all related design decisions? |
95 | 89 | - Check whether all requirements allocated to the architectural element are considered in the design. These include functional requirements (e.g., functional safety requirements), non-functional requirements (e.g., performance and reliability), and security requirements (e.g., confidentiality and integrity). Also ensure that all related design decisions are taken into account and documented in the architectural design. Security-related requirements should also be reviewed through the applicable cybersecurity process; this checklist does not replace cybersecurity activities. |
96 | 90 | - |
97 | 91 | - |
98 | 92 | - |
99 | | - * - ARC_01_03 |
| 93 | + * - ARC_01_02 |
100 | 94 | - If the architectural element is related to any supplier manuals (including safety and security), are the relevant parts covered? |
101 | 95 | - If the architecture makes use of supplied elements, their manuals (e.g., safety manuals) must be considered; their functionality must match expectations, and their assumptions must be fulfilled. For a safety component, this means that the assumed Technical Safety Requirements and assumptions of use (AoUs) in the safety manual are covered. |
102 | 96 | - |
103 | 97 | - |
104 | 98 | - |
105 | | - * - ARC_01_04 |
| 99 | + * - ARC_01_03 |
106 | 100 | - Is the architectural element traceable to lower-level artifacts as defined by work-product traceability? |
107 | | - - |
| 101 | + - Check if every logical interface is provided by exactly one component and used by at least one. CHeck if every component of the feature is included by exactly one module. |
108 | 102 | - |
109 | 103 | - |
110 | 104 | - |
@@ -235,3 +229,7 @@ and the following dynamic views "valid" state and with "inspected" tag set are i |
235 | 229 | :columns: id;status;tags |
236 | 230 | :colwidths: 25,25,25 |
237 | 231 | :sort: title |
| 232 | + |
| 233 | +.. note:: |
| 234 | + |
| 235 | + For these static and dynamic views the inspected ground truth is documented in the rendered documentation and not in the source read by the drawing tool. |
0 commit comments