add linkage to process requirements

process/folder_templates/features/feature_name/architecture/chklst_arc_inspection.rst

@@ -59,7 +59,7 @@ Checklist
       - Is the traceability from software architectural elements to requirements, and other level architectural
         elements (e.g. component to interface) established according to the "Relations between the architectural elements" as described in :need:`doc_concept__arch_process`?
       - automated
-      - Trace should be checked by Sphinx. Will be removed from checklist once requirement is implemented.
+      - Trace should be checked automatically by tool support in the future. It 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.
       -
       -
       -
@@ -74,8 +74,8 @@ Checklist
     * - ARC_01_03
       - Is the architectural element traceable to the lower level artifacts as defined by the workproduct traceability?
       - automated
-      - Will be removed from checklist once requirement is implemented by automated tool check.
-        Details of possible linking can be depicted from `traceability concept <https://eclipse-score.github.io/process_description/main/general_concepts/score_traceability_concept.html>`_
+      - Will be removed from checklist once the requirement (:need:`Correlations of the architectural building blocks <gd_req__arch_build_blocks_corr>`) is implemented by automated tool check. See `Tool Requirements <https://eclipse-score.github.io/docs-as-code/main/internals/requirements/requirements.html>`_.
+        Details of possible linking can be depicted from :ref:`traceability concept <general_concepts_traceability>`.
       -
       -
       -

process/folder_templates/features/feature_name/requirements/chklst_req_inspection.rst

@@ -100,7 +100,7 @@ Requirement Inspection Checklist
         -
         -
       * - REQ_03_02
-        - For feature/component requirements: Is the *linkage to the parent 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.
         -
         -
@@ -131,7 +131,7 @@ Requirement Inspection Checklist
         -
       * - REQ_07_02
         - Is the attribute *security* set correctly?
-        - Stakeholder requirements security attribute should be set based on Threat Analysis and Risk Assessment (TARA) (process is TBD). For feature/component requirements this checklist item is supported by automated check: "Every requirement which satisfies a requirement with security attribute set to YES inherits this". But the feature/component requirements/architecture may additionally also be subject to a Software Security Criticality Analysis (process is TBD).
+        - For feature/component 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>`.
         -
         -
         -
@@ -143,12 +143,12 @@ Requirement Inspection Checklist
         -
       * - REQ_09_01
         - For stakeholder requirements: Do those cover assumed safety mechanisms needed by the hardware and system?
-        - Note that stakeholder requirements covering safety mechanisms come from rationales, whereas feature/component requirements are covering safety mechanisms coming from :need:`gd_chklst__safety_analysis`
+        - Note that stakeholder requirements covering safety mechanisms come from rationales, whereas feature requirements are covering safety mechanisms coming from :need:`gd_chklst__safety_analysis`
         -
         -
         -
       * - REQ_09_02
-        - For feature/component requirements: Do the requirements defining a safety mechanism contain the error reaction leading to a safe state?
+        - Do the feature requirements defining a safety mechanism contain the error reaction leading to a safe state?
         - Alternatively to the safe state there could also be "repair" mechanisms. Also do not forget to consider REQ_05_01 for these.
         -
         -

process/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.rst

@@ -59,7 +59,7 @@ Checklist
       - Is the traceability from software architectural elements to requirements, and other level architectural
         elements (e.g. component to interface) established according to the "Relations between the architectural elements" as described in :need:`doc_concept__arch_process`?
       - automated
-      - Trace should be checked by Sphinx. Will be removed from checklist once requirement is implemented.
+      - Trace should be checked automatically by tool support in the future. 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.
       -
       -
       -
@@ -74,8 +74,8 @@ Checklist
     * - ARC_01_03
       - Is the architectural element traceable to the lower level artifacts as defined by the workproduct traceability?
       - automated
-      - Will be removed from checklist once requirement is implemented by automated tool check.
-        Details of possible linking can be depicted from `traceability concept <https://eclipse-score.github.io/process_description/main/general_concepts/score_traceability_concept.html>`_
+      - Will be removed from checklist once the requirement (:need:`Correlations of the architectural building blocks <gd_req__arch_build_blocks_corr>`) is implemented by automated tool check. See `Tool Requirements <https://eclipse-score.github.io/docs-as-code/main/internals/requirements/requirements.html>`_.
+        Details of possible linking can be depicted from :ref:`traceability concept <general_concepts_traceability>`.
       -
       -
       -

process/folder_templates/modules/module_name/component_name/docs/requirements/chklst_req_inspection.rst

@@ -100,7 +100,7 @@ Requirement Inspection Checklist
         -
         -
       * - REQ_03_02
-        - For feature/component requirements: Is the *linkage to the parent requirement* correct?
+        - Is the *linkage to the parent feature/component 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.
         -
         -
@@ -131,7 +131,7 @@ Requirement Inspection Checklist
         -
       * - REQ_07_02
         - Is the attribute *security* set correctly?
-        - Stakeholder requirements security attribute should be set based on Threat Analysis and Risk Assessment (TARA) (process is TBD). For feature/component requirements this checklist item is supported by automated check: "Every requirement which satisfies a requirement with security attribute set to YES inherits this". But the feature/component requirements/architecture may additionally also be subject to a Software Security Criticality Analysis (process is TBD).
+        - 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>`..
         -
         -
         -
@@ -142,13 +142,12 @@ Requirement Inspection Checklist
         -
         -
       * - REQ_09_01
-        - For stakeholder requirements: Do those cover assumed safety mechanisms needed by the hardware and system?
-        - Note that stakeholder requirements covering safety mechanisms come from rationales, whereas feature/component requirements are covering safety mechanisms coming from :need:`gd_chklst__safety_analysis`
+        - Note that stakeholder requirements covering safety mechanisms come from rationales, whereas component requirements are covering safety mechanisms coming from :need:`gd_chklst__safety_analysis`
         -
         -
         -
       * - REQ_09_02
-        - For feature/component requirements: Do the requirements defining a safety mechanism contain the error reaction leading to a safe state?
+        - Do the requirements that define a safety mechanism specify the error reaction leading to a safe state?
         - Alternatively to the safe state there could also be "repair" mechanisms. Also do not forget to consider REQ_05_01 for these.
         -
         -

process/process_areas/verification/verification_workproducts.rst

@@ -72,7 +72,7 @@ Feature
 
    - all interfaces from Static view and
    - all flows from Dynamic View and
-   - performance: i.e. RAM and processor usage
+   - performance and resource consumption: i.e. RAM and processor usage
      on reference HW
 
 Module