grammar and sentence corrections in the checklist (eclipse-score#196)

Author: RolandJentschETAS

docs/features/architecture/arc_inspection.rst

@@ -62,15 +62,14 @@ Feature Architecture File
    :included_by: feat__mtef
    :fulfils: feat_req__example_feature__example_req
 
+   This interface carries the feature's primary control requests and status data. It connects the feature to the component responsible for core control, with inputs validated and errors reported through the operation results.
+
    .. needarch::
       :scale: 50
       :align: center
 
       {{ draw_interface(need(), needs) }}
 
-   Logical Interface 1 provides the primary control and communication interface for the feature.
-   It is implemented by sub-component 1 which handles the core functionality.
-
 
 .. logic_arc_int:: Logical Interface 2
    :id: logic_arc_int__example_feature__if_2
@@ -81,15 +80,14 @@ Feature Architecture File
    :included_by: feat__mtef
    :fulfils: feat_req__example_feature__example_req
 
+   This interface transfers data between the feature and the component responsible for processing it. It supports data submission and retrieval, with operation results indicating success or an applicable error.
+
    .. needarch::
       :scale: 50
       :align: center
 
       {{ draw_interface(need(), needs) }}
 
-   Logical Interface 2 provides support for data processing and communication between sub-components.
-   It is implemented by sub-component 2 which handles data flow and processing operations.
-
 
 .. logic_arc_int:: Logical Interface 3
    :id: logic_arc_int__example_feature__if_3
@@ -100,7 +98,7 @@ Feature Architecture File
    :included_by: feat__mtef
    :fulfils: feat_req__example_feature__example_req
 
-   Logical Interface 3 provides additional support and monitoring capabilities for the feature.
+   This interface exposes the feature's monitoring and diagnostic information. It provides status and event data to authorized consumers and reports errors when requested information is unavailable.
 
 .. Logical Interface Operation
 
@@ -112,6 +110,8 @@ Feature Architecture File
    :version: 1
    :included_by: logic_arc_int__example_feature__if_1
 
+   Accepts a control request and returns whether the request was accepted or an error occurred.
+
 .. logic_arc_int_op:: Logical Operation 2
    :id: logic_arc_int_op__example_feature__op_2
    :security: YES
@@ -120,6 +120,8 @@ Feature Architecture File
    :version: 1
    :included_by: logic_arc_int__example_feature__if_1
 
+   Returns the current control status so the caller can determine the feature's state.
+
 .. logic_arc_int_op:: Logical Operation 3
    :id: logic_arc_int_op__example_feature__op_3
    :security: YES
@@ -128,6 +130,8 @@ Feature Architecture File
    :version: 1
    :included_by: logic_arc_int__example_feature__if_2
 
+   Submits data for processing and reports whether the data was accepted or invalid.
+
 .. logic_arc_int_op:: Logical Operation 4
    :id: logic_arc_int_op__example_feature__op_4
    :security: YES
@@ -136,6 +140,8 @@ Feature Architecture File
    :version: 1
    :included_by: logic_arc_int__example_feature__if_2
 
+   Retrieves the result of a completed data-processing request or reports that no result is available.
+
 .. logic_arc_int_op:: Logical Operation 5
    :id: logic_arc_int_op__example_feature__op_5
    :security: YES
@@ -144,6 +150,8 @@ Feature Architecture File
    :version: 1
    :included_by: logic_arc_int__example_feature__if_3
 
+   Returns a health summary for the feature's monitored components.
+
 .. logic_arc_int_op:: Logical Operation 6
    :id: logic_arc_int_op__example_feature__op_6
    :security: YES
@@ -152,6 +160,8 @@ Feature Architecture File
    :version: 1
    :included_by: logic_arc_int__example_feature__if_3
 
+   Retrieves diagnostic information for an identified component or reports that the information is unavailable.
+
 .. logic_arc_int_op:: Logical Operation 7
    :id: logic_arc_int_op__example_feature__op_7
    :security: YES
@@ -160,6 +170,8 @@ Feature Architecture File
    :version: 1
    :included_by: logic_arc_int__example_feature__if_3
 
+   Publishes a monitoring event when a component's status changes.
+
 .. logic_arc_int_op:: Logical Operation 8
    :id: logic_arc_int_op__example_feature__op_8
    :security: YES
@@ -168,6 +180,8 @@ Feature Architecture File
    :version: 1
    :included_by: logic_arc_int__example_feature__if_3
 
+   Acknowledges a monitoring event and reports whether the event identifier is valid.
+
 
 Module View File
 ================

examples/docs/architecture_modeling_example.rst

@@ -34,6 +34,8 @@
     - Adjust ``status`` to be ``valid``
     - Adjust ``safety`` and ``tags`` according to your needs
 
+.. note:: Create separate architecture, safety-analysis, and security-analysis documentation for lower-level components only when the component is decomposed into subcomponents and those artifacts apply. This document describes the current component and may be needed even when it has no subcomponents.
+
 
 Overview
 --------

score/component_example/docs/architecture/component_architecture.rst

@@ -15,7 +15,7 @@
 .. document:: [Component Name] Implementation Inspection Checklist
   :id: doc__mod_temp_component_name_impl_inspection
   :status: draft
-  :version: 1
+  :version: 2
   :safety: ASIL_B
   :security: YES
   :realizes: wp__sw_implementation_inspection
@@ -35,90 +35,86 @@
 Purpose
 -------
 
-The purpose of this checklist is to collect the topics to be checked during implementation,
-i.e. in the detailed design and the source code of the units.
+The purpose of this checklist is to define the topics to be reviewed during implementation,
+including the detailed design and unit source code. Unit testing and structural coverage are
+addressed separately through the verification activities and report.
 
-The checklist shall be agnostic to which programming language is used. Differences shall be treated
-by linking to C++ or Rust specific documentation.
+The checklist is intended to be language-agnostic. Language-specific guidance should be referenced
+where applicable, for example, in the C++ or Rust documentation.
 
 Conduct
 -------
 
-As described in the concept :need:`doc_concept__wp_inspections` the following "inspection roles" are expected to be filled:
+As described in the concept :need:`doc_concept__wp_inspections`, the following inspection roles are expected to be assigned:
 
-- content responsible (author): <contributor/committer explicitly named here, who is the main author, as can be seen in config mgt tooling>
-- reviewer: <contributor/committer explicitly named here, who is the main content reviewer, must be different from content responsible>
-- moderator: <committer explicitly named here, who is is the safety manager, security manager or quality manager initiating the inspection>
+- content responsible (author): <contributor/committer explicitly named here who is the main author, as shown in configuration management tooling>
+- reviewer: <contributor/committer explicitly named here who is the main content reviewer; this person must differ from the content responsible>
+- moderator: <committer explicitly named here who initiates the inspection as the safety, security, or quality manager>
 
 Checklist
 ---------
 
-It is mandatory to fill in the "passed" column with "yes" or "no" for each checklist item and additionally to add in the remarks why it is passed or not passed.
-In case of "no" an issue link to the issue tracking system has to be added in the last column (if not solved in the same issue).
+Enter "yes" or "no" in the "Passed" column for each checklist item, and explain the result in the "Remarks" column.
+If "no" is entered, add a link to the corresponding issue in the "Issue link" column unless the finding is already tracked in the issue conducting the inspection.
 See also :need:`doc_concept__wp_inspections` for further information about reviews in general and inspection in particular.
 
 .. list-table:: Implementation Checklist
    :header-rows: 1
    :widths: 10,30,50,6,6,8
 
    * - Review ID
-     - Acceptance Criteria
+     - Acceptance criteria
      - Guidance
      - Passed
      - Remarks
      - Issue link
    * - IMPL_01_01
-     - Is the design according to guidelines?
-     - see :need:`gd_temp__detailed_design` and :need:`doc_concept__imp_concept`
-       (e.g. are the views done with the proposed UML diagrams)
+     - Does the detailed design follow the applicable project guidelines?
+     - See :need:`gd_temp__detailed_design` and :need:`doc_concept__imp_concept`.
+       For example, check whether design views use the notations recommended by the project.
      -
      -
      -
    * - IMPL_01_02
-     - Is the implementation according to specification?
-     - Check if the linked component requirements are fulfilled
-       and detailed design also matches architecture description.
+     - Does the implementation conform to the allocated requirements, architecture, and detailed design?
+     - Check whether the linked component requirements are fulfilled and whether the detailed design is consistent with the architecture description.
      -
      -
      -
    * - IMPL_01_03
-     - Are the design decisions and constraints documented?
-     - Check also for plausibility of these.
+     - Are the design decisions, assumptions, and constraints documented and justified?
+     - Check whether the rationale is clear and consistent with the requirements and architecture.
      -
      -
      -
    * - IMPL_01_04
-     - Are all external libraries used by the component specified in the detailed design?
-     - Check the automated dependency analysis.
-       Also make sure ASIL rated units also only use ASIL rated libraries.
+     - Are all external libraries and other third-party dependencies used by the component identified and assessed for the intended use?
+     - Check the automated dependency analysis and confirm that relevant safety evidence, assumptions, constraints, and usage conditions are documented. Where a dependency is used in a safety-related context, justify its suitability for the required safety integrity level; do not assume that an "ASIL-rated" label alone demonstrates suitability.
      -
      -
      -
    * - IMPL_02_01
-     - Are the static and dynamic code analysis reports verified for violations?
-     - All violations in ASIL related code must be justified. This includes the checks of coding guidelines.
+     - Have the static and dynamic code-analysis results been reviewed, and have the findings been resolved or justified?
+     - Review findings against the applicable coding guidelines. Resolve findings or document and approve the rationale for accepted deviations, especially in safety-related code.
      -
      -
      -
    * - IMPL_02_02
-     - Do manual checks, that are derived from the coding guideline, find no safety critical error?
-     - Check this for the programming language used (e.g. C++ <link_to_checks_list>, Rust <link_to_checks_list>)
+     - Have the manual checks required by the applicable coding guidelines been performed, with findings resolved or justified?
+     - Use the checks applicable to the programming language (e.g., C++ <link_to_checks_list>, Rust <link_to_checks_list>).
      -
      -
      -
    * - IMPL_03_01
-     - Do the UID of the interface in component documentation match the implemented interface names of the unit?
-     - Compare interface UIDs (which contains the interface name) in component architecture/detailed design documentation
-       with public interfaces in source code (e.g. API headers, traits, public types/functions).
+     - Are the interface UIDs in the component documentation traceable to the corresponding implemented public interfaces?
+     - Compare the interface UIDs in the component architecture and detailed design documentation with the corresponding public interfaces in the source code (e.g., API headers, traits, public types, or functions). The identifiers need not match source-level names exactly, but their correspondence should be clear.
      -
      -
      -
    * - IMPL_03_02
-     - Are detailed design and source code consistent and is the respective traceability established ?
-     - Check if available static and dynamic design diagrams and the textual descriptions match the code
-       (e.g. naming of interfaces, units, functions/operations/messages, data types).
-       Check if the folder/file names of the units and its source code matches the intended functionality.
-       For example if a unit is named "communication" it should not contain code for "data processing".
+     - Are the detailed design and source code consistent, and is traceability between them established?
+     - Check whether available static and dynamic design diagrams and textual descriptions match the code (e.g., the names of interfaces, units, functions, operations, messages, and data types).
+       Where required by project conventions, check whether unit folder and file names reflect their intended functionality. For example, a unit named "communication" should not contain unrelated data-processing code.
      -
      -
      -

score/component_example/docs/detailed_design/chklst_impl_inspection.rst

@@ -78,6 +78,8 @@ Further Documentation of the component can be found in the following sections:
 Component Detail Information
 ============================
 
+.. note:: The documents listed below describe this component. Create separate architecture, safety-analysis, and security-analysis documents for subcomponents only when this component is decomposed into subcomponents and those artifacts apply.
+
 .. toctree::
    :maxdepth: 1
 
@@ -87,5 +89,5 @@ Component Detail Information
    safety_analysis/dfa
    safety_analysis/fmea
    safety_analysis/aou_requirements
-   component_classification
+   safety_analysis/component_classification
    security_analysis/aou_requirements

score/component_example/docs/index.rst

@@ -25,6 +25,9 @@
    :realizes: wp__sw_component_dfa
    :tags: template
 
+
+.. note:: Create separate DFA documentation for lower-level components only when the component is decomposed into subcomponents and a separate analysis applies. This document covers the current component's DFA scope.
+
 .. note:: Use the content of the document to describe e.g. why a fault model is not applicable for the diagram.
 
 .. attention::

…xample/docs/component_classification.rst …ty_analysis/component_classification.rstscore/component_example/docs/component_classification.rst renamed to score/component_example/docs/safety_analysis/component_classification.rst score/component_example/docs/component_classification.rst renamed to score/component_example/docs/safety_analysis/component_classification.rst

@@ -25,6 +25,9 @@
    :realizes: wp__sw_component_fmea
    :tags: template
 
+
+.. note:: Create separate FMEA documentation for lower-level components only when the component is decomposed into subcomponents and a separate analysis applies. This document covers the current component's FMEA scope.
+
 .. note:: Use the content of the document to describe e.g. why a fault model is not applicable for the diagram.
 
 .. attention::