eclipse-score · aschemmel-tech · Jan 21, 2026
@@ -40,14 +40,14 @@ Requirement Inspection Checklist
 
    As described in the concept :need:`doc_concept__wp_inspections` the following "inspection roles" are expected to be filled:
 
-   - author: <contributor/committer(s) explicitly named here, who is/are the content responsible(s)>
-   - reviewer: these are all persons committing into this inspection document or giving a pull request verdict on it (can be derived from version mgt tool)
-   - moderator: only needed for conflict resolution between author and reviewers, is the safety manager, security manager or quality manager called in as a reviewer (can be derived from version mgt tool)
+   - 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: <contributor/committer explicitly named here, who is is the safety manager, security manager or quality manager initiating the inspection>
    - test expert: <one of the reviewers explicitly named here, to cover REQ_08_01 as described>
 
    **Checklist**
 
-   See also :ref:`review_concept` for further information about reviews in general and inspection in particular.
+   See also :need:`doc_concept__wp_inspections` for further information about reviews in general and inspection in particular.
 
    .. list-table:: Feature Requirement Inspection Checklist
       :header-rows: 1
@@ -127,7 +127,7 @@ Requirement Inspection Checklist
         -
       * - REQ_07_02
         - Is the *security* attribute set correctly?
-        - For feature requirements this checklist item is supported by automated check: "Every requirement which satisfies a stakeholder requirement with security attribute set to YES inherits this". But the feature requirements/architecture may additionally also be subject to a :ref:`Software Security Analysis <security_analysis>`.
+        - For feature requirements this checklist item is supported by automated check: "Every requirement which satisfies a stakeholder requirement with security attribute set to YES inherits this". But the feature requirements/architecture may additionally also be subject to a :need:`wp__feature_security_analysis`
         -
         -
         -
@@ -153,8 +153,9 @@ Requirement Inspection Checklist
 
 .. attention::
     The above checklist entries must be filled according to your component requirements in scope.
+    It is mandatory to fill remarks also for checklist entries which are passed, to be able to understand the verdict.
 
-Note: If a Review ID is not applicable for your requirement, then state ""n/a" in status and comment accordingly in remarks. For example "no stakeholder requirement (no rationale needed)"
+Note: If a Review ID is not applicable for your requirement, then state ""n/a" in status and comment accordingly in remarks.
 
 The following requirements in "valid" state and with "inspected" tag set are in the scope of this inspection:
 
@@ -167,7 +168,7 @@ The following requirements in "valid" state and with "inspected" tag set are in
    :colwidths: 25,25,25
    :sort: title
 
-And also the following AoUs in "valid" state and with "inspected" tag set (for these please answer the questions above as if the AoUs are requirements, except questions REQ_03_01 and REQ_03_02):
+And also the following AoUs in "valid" state and with "inspected" tag set (for these please answer the questions above as if the AoUs are requirements, except question REQ_03_01):
 
 .. needtable::
    :filter: "feature_name" in docname and "requirements" in docname and docname is not None and status == "valid"

@@ -40,14 +40,14 @@ Requirement Inspection Checklist
 
    As described in the concept :need:`doc_concept__wp_inspections` the following "inspection roles" are expected to be filled:
 
-   - author: <contributor/committer(s) explicitly named here, who is/are the content responsible(s)>
-   - reviewer: these are all persons committing into this inspection document or giving a pull request verdict on it (can be derived from version mgt tool)
-   - moderator: only needed for conflict resolution between author and reviewers, is the safety manager, security manager or quality manager called in as a reviewer (can be derived from version mgt tool)
+   - 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: <contributor/committer explicitly named here, who is is the safety manager, security manager or quality manager initiating the inspection>
    - test expert: <one of the reviewers explicitly named here, to cover REQ_08_01 as described>
 
    **Checklist**
 
-   See also :ref:`review_concept` for further information about reviews in general and inspection in particular.
+   See also :need:`doc_concept__wp_inspections` for further information about reviews in general and inspection in particular.
 
    .. list-table:: Component Requirement Inspection Checklist
       :header-rows: 1
@@ -96,7 +96,7 @@ Requirement Inspection Checklist
         -
         -
       * - REQ_03_01
-        - Is the *linkage to the parent feature/component requirement* correct?
+        - Is the *linkage to the parent requirement* correct?
         - Linkage to correct levels and ASIL attributes is checked automatically, but it needs checking if the child requirement implements (at least) a part of the parent requirement.
         -
         -
@@ -127,7 +127,7 @@ Requirement Inspection Checklist
         -
       * - REQ_07_02
         - Is the attribute *security* set correctly?
-        - For component requirements this checklist item is supported by automated check: "Every requirement which satisfies a feature requirement with security attribute set to YES inherits this". But the component requirements/architecture may additionally also be subject to a :ref:`Software Security Analysis <security_analysis>`..
+        - For component requirements this checklist item is supported by automated check: "Every requirement which satisfies a feature requirement with security attribute set to YES inherits this". But the component requirements/architecture may additionally also be subject to a :need:`wp__sw_component_security_analysis`.
         -
         -
         -
@@ -153,8 +153,9 @@ Requirement Inspection Checklist
 
 .. attention::
     The above checklist entries must be filled according to your component requirements in scope.
+    It is mandatory to fill remarks also for checklist entries which are passed, to be able to understand the verdict.
 
-Note: If a Review ID is not applicable for your requirement, then state ""n/a" in status and comment accordingly in remarks. For example "no stakeholder requirement (no rationale needed)"
+Note: If a Review ID is not applicable for your requirement, then state ""n/a" in status and comment accordingly in remarks.
 
 The following requirements in "valid" state and with "inspected" tag set are in the scope of this inspection:
 
@@ -167,7 +168,7 @@ The following requirements in "valid" state and with "inspected" tag set are in
    :colwidths: 25,25,25
    :sort: title
 
-And also the following AoUs in "valid" state and with "inspected" tag set (for these please answer the questions above as if the AoUs are requirements, except questions REQ_03_01 and REQ_03_02):
+And also the following AoUs in "valid" state and with "inspected" tag set (for these please answer the questions above as if the AoUs are requirements, except question REQ_03_01):
 
 .. needtable::
    :filter: "component_name" in docname and "requirements" in docname and docname is not None and status == "valid"

@@ -13,19 +13,17 @@
    # *******************************************************************************
 
 
-.. document:: [Your Stakeholder Name] Requirements Inspection Checklist
-   :id: doc__stakeholder_name_req_inspection
+.. document:: Stakeholder Requirements Inspection Checklist
+   :id: doc__stakeholder_req_inspection
    :status: draft
    :safety: ASIL_B
    :security: YES
    :realizes: wp__requirements_inspect
    :tags: template
 
 .. attention::
-    The above directive must be updated according to your Stakeholder.
+    The above directive must be updated according to your Stakeholder requirements.
 
-    - Modify ``Your Stakeholder Name`` to be your Stakeholder Name
-    - Modify ``id`` to be your Stakeholder Name in lower snake case preceded by ``doc__`` and followed by ``_req_inspection``
     - Adjust ``status`` to be ``valid``
     - Adjust ``safety``, ``security`` and ``tags`` according to your needs
 
@@ -40,14 +38,14 @@ Stakeholder Requirement Inspection Checklist
 
    As described in the concept :need:`doc_concept__wp_inspections` the following "inspection roles" are expected to be filled:
 
-   - author: <contributor/committer(s) explicitly named here, who is/are the content responsible(s)>
-   - reviewer: these are all persons committing into this inspection document or giving a pull request verdict on it (can be derived from version mgt tool)
-   - moderator: only needed for conflict resolution between author and reviewers, is the safety manager, security manager or quality manager called in as a reviewer (can be derived from version mgt tool)
+   - 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: <contributor/committer explicitly named here, who is is the safety manager, security manager or quality manager initiating the inspection>
    - test expert: <one of the reviewers explicitly named here, to cover REQ_08_01 as described>
 
    **Checklist**
 
-   See also :ref:`review_concept` for further information about reviews in general and inspection in particular.
+   See also :need:`doc_concept__wp_inspections` for further information about reviews in general and inspection in particular.
 
    .. list-table:: Stakeholder Requirement Inspection Checklist
       :header-rows: 1
@@ -97,13 +95,7 @@ Stakeholder Requirement Inspection Checklist
         -
       * - REQ_03_01
         - Is the *rationale* correct?
-        - Rationales explain why the top level requirements were created. Do those cover the requirement?
-        -
-        -
-        -
-      * - REQ_03_02
-        - Is the *linkage to the parent requirement* correct?
-        - Linkage to correct levels and ASIL attributes is checked automatically, but it needs checking if the child requirement implements (at least) a part of the parent requirement.
+        - Rationales explain why the stakeholder level requirements were created. Do those cover the requirement?
         -
         -
         -
@@ -150,31 +142,27 @@ Stakeholder Requirement Inspection Checklist
         -
         -
 
-Note: If a Review ID is not applicable for your requirement, then state ""n/a" in status and comment accordingly in remarks. For example "no stakeholder requirement (no rationale needed)"
+Note: If a Review ID is not applicable for your requirement, then state ""n/a" in status and comment accordingly in remarks.
 
 The following requirements in "valid" state and with "inspected" tag set are in the scope of this inspection:
 
 .. needtable::
-   :filter: "stakeholder_name" in docname and "requirements" in docname and docname is not None and status == "valid"
+   :filter: "stakeholder" in docname and "requirements" in docname and docname is not None and status == "valid"
    :style: table
    :types: stkh_req
-   :tags: stakeholder_name
    :columns: id;status;tags
    :colwidths: 25,25,25
    :sort: title
 
-And also the following AoUs in "valid" state and with "inspected" tag set (for these please answer the questions above as if the AoUs are requirements, except questions REQ_03_01 and REQ_03_02):
+And also the following AoUs in "valid" state and with "inspected" tag set (for these please answer the questions above as if the AoUs are requirements, except question REQ_03_01):
 
 .. needtable::
-   :filter: "stakeholder_name" in docname and "requirements" in docname and docname is not None and status == "valid"
+   :filter: "platform" in docname and "assumptions" in docname and docname is not None and status == "valid"
    :style: table
    :types: aou_req
-   :tags: stakeholder_name
    :columns: id;status;tags
    :colwidths: 25,25,25
    :sort: title
 
 .. attention::
-    The above tables filtering must be updated according to your Stakeholder.
-
-    - Modify ``stakeholder_name`` to be your Stakeholder Name in lower snake case
+    The above tables filtering must be updated according to your Stakeholder requirements document names.
@@ -42,6 +42,9 @@ In this project there are inspections on the following work products, which are
         * - :need:`wp__requirements_comp`
           - :need:`gd_chklst__req_inspection`
 
+        * - :need:`wp__requirements_sw_platform_aou`
+          - :need:`gd_chklst__req_inspection`
+
         * - :need:`wp__requirements_feat_aou`
           - :need:`gd_chklst__req_inspection`
 
@@ -69,40 +72,59 @@ Inspection Conduct
 Inspections are conducted by using version management tooling mechanisms and files based on inspection templates.
 We expect that the requirement and architecture work products need to mature during implementation and testing
 and that the inspection checklists also contain questions which can not be answered already at creation of the work product,
-because also other work products content also has to be taken into account (which is not available at the beginning,
+because also other work products content also has to be taken into account (which is not available at the beginning),
 therefore we use a two-step approach for the review and inspection for these.
 
 The detailed design and coding inspection is also done in this two-step approach, at least for the
 initial development of a feature/component. This is also to have a unified approach for the inspections
 and reduce initial tooling support effort.
 
-The initial step for review and inspection is the (informal) version management tooling review on every Pull-Request
+The initial activity for review and inspection is the (informal) version management tooling review on every Pull-Request
 (resp. Change Request, see :need:`gd_guidl__change_change_request`)
 which creates or modifies one of these work products (subject to inspection).
 After this review the work products are in status "valid", which means they can be used
 for further development and verification steps (note that merged code is always "valid").
-In this review the checklist entries shall be considered which are tagged as "incremental".
 
-The last step is initiated by the safety manager, security manager or quality manager:
-He asks the main work product author to set the work product's status to "valid(inspected)" and start a Pull-Request (PR).
+The next activity is the formal inspection, which follows the following workflow (see illustration below):
+
+.. figure:: _assets/score_inspection_workflow.drawio.svg
+    :width: 80%
+    :align: center
+    :alt: Inspections Workflow
+
+    Inspections Workflow
+
+1. Inspection initiation
+
+The inspection is initiated by the safety manager, security manager or quality manager who will be the moderator for the inspection.
+He sets the work product's status to "valid(inspected)" and starts a Pull-Request (PR).
 This marks the scope of the inspection but also the work product's version.
-For documentation of the review either the PR comments are used (based on inspection templates),
-or the author creates/updates an inspection documentation file based on the respective templates in the same PR
-containing the same information (scope/version of work products under inspection, author/reviewer/moderator, findings).
+For documentation of the review either the PR comments are used (based on latest inspection templates),
+or the safety manager creates/updates an inspection documentation file based on the latest respective templates in the same PR
+containing the same information (role assignment = author/reviewer(s)/moderator and checklist items).
 The latter option is not preferred but needs to be used in case the PR data can/could not be stored.
 When opening the PR, Version management tooling will automatically ask for a review by the defined one or more reviewer
 implemented by the codeowner mechanism of the work product.
 In the PR (resp. inspection documentation file) the inspection result will be documented for each checklist item
 (pass/fail - with link to a ticket for the corrections).
-The reviewers will fill out the checklist and add their findings on the work product in the PR.
+
+2. Inspection review
+
+The reviewers will fill out the checklist and add their findings on the work product in the PR (by adding an own commit into the PR).
 They close their review activity by documenting their verdict as "Approve" or "Request Changes".
-Any one "Request Changes" will block the PR from being merged. Note that the PR author cannot "Approve" or "Request Changes".
-After all requested reviews were done, the author answers the findings and/or performs corrections of the work products
+Any "Request Changes" will block the PR from being merged. Note that the PR author cannot "Approve" or "Request Changes" (his own PR).
+
+3. Inspection corrections
+
+After all requested reviewers are done, the author answers the findings and/or performs corrections of the work products
 - either directly or by creating a Bug ticket to resolve.
-Then the reviewer(s) re-review and adapt their verdict accordingly.
+
+4. Inspection approval
+
+The reviewer(s) re-review and adapt their verdict accordingly (to "Approve").
 In case the author or the reviewer(s) cannot agree on a solution, the safety/security/quality manger
-who initiated the inspection will be asked to moderate this by requesting also his review.
-After all the required reviewers approved, the PR is merged.
+who initiated the inspection will be asked to moderate this.
+After all the required reviewers approved including the CODEOWNER of the work product, the PR is merged.
 
 In future the project will try to establish (also) incremental inspections based on version management tooling only,
 i.e. the inspection template, findings documentation and storage will be part of this tooling.
@@ -111,12 +133,12 @@ But this is currently not implemented.
 The following picture shall illustrate how a status lifecycle of a requirement work product will look like.
 The lifecycle for other work product should be similar.
 
-.. figure:: _assets/inspection_workflow.drawio.svg
+.. figure:: _assets/score_req_review_workflow.drawio.svg
     :width: 80%
     :align: center
-    :alt: Inspections Workflow
+    :alt: Req Review Workflow
 
-    Review Inspections Workflow - Requirement Example
+    Review Workflow - Requirement Example
 
 #. Create requirement
 #. (Informal) Pull-Request Review