Merge pull request #431 from etas-contrib/add_linking_to_process_req

masc2023 · web-flow · commit 581e2ae721ac · 2025-12-04T14:00:43.000+01:00
add linkage to process requirements
diff --git a/process/folder_templates/features/feature_name/architecture/chklst_arc_inspection.rst b/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>`.
       -
       -
       -
diff --git a/process/folder_templates/features/feature_name/requirements/chklst_req_inspection.rst b/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 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.
         -
         -
diff --git a/process/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.rst b/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>`.
       -
       -
       -
diff --git a/process/folder_templates/modules/module_name/component_name/docs/requirements/chklst_req_inspection.rst b/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,13 @@ 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.
         -
         -
diff --git a/process/process_areas/verification/verification_workproducts.rst b/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

Original file line number	Diff line number	Diff line change
`@@ -59,7 +59,7 @@ Checklist`
`59`	`59`	`- Is the traceability from software architectural elements to requirements, and other level architectural`
`60`	`60`	elements (e.g. component to interface) established according to the "Relations between the architectural elements" as described in :need:`doc_concept__arch_process`?
`61`	`61`	`- automated`
`62`		`- - Trace should be checked by Sphinx. Will be removed from checklist once requirement is implemented.`
	`62`	+ - 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.
`63`	`63`	`-`
`64`	`64`	`-`
`65`	`65`	`-`
`@@ -74,8 +74,8 @@ Checklist`
`74`	`74`	`* - ARC_01_03`
`75`	`75`	`- Is the architectural element traceable to the lower level artifacts as defined by the workproduct traceability?`
`76`	`76`	`- automated`
`77`		`- - Will be removed from checklist once requirement is implemented by automated tool check.`
`78`		- Details of possible linking can be depicted from `traceability concept <https://eclipse-score.github.io/process_description/main/general_concepts/score_traceability_concept.html>`_
	`77`	+ - 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>`_.
	`78`	+ Details of possible linking can be depicted from :ref:`traceability concept <general_concepts_traceability>`.
`79`	`79`	`-`
`80`	`80`	`-`
`81`	`81`	`-`
Original file line number	Diff line number	Diff line change
`@@ -100,7 +100,7 @@ Requirement Inspection Checklist`
`100`	`100`	`-`
`101`	`101`	`-`
`102`	`102`	`* - REQ_03_02`
`103`		`- - For feature/component requirements: Is the linkage to the parent requirement correct?`
	`103`	`+ - Is the linkage to the parent requirement correct?`
`104`	`104`	`- 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.`
`105`	`105`	`-`
`106`	`106`	`-`
`@@ -131,7 +131,7 @@ Requirement Inspection Checklist`
`131`	`131`	`-`
`132`	`132`	`* - REQ_07_02`
`133`	`133`	`- Is the attribute security set correctly?`
`134`		`- - 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).`
	`134`	+ - 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>`.
`135`	`135`	`-`
`136`	`136`	`-`
`137`	`137`	`-`
`@@ -143,12 +143,12 @@ Requirement Inspection Checklist`
`143`	`143`	`-`
`144`	`144`	`* - REQ_09_01`
`145`	`145`	`- For stakeholder requirements: Do those cover assumed safety mechanisms needed by the hardware and system?`
`146`		- - 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`
	`146`	+ - Note that stakeholder requirements covering safety mechanisms come from rationales, whereas feature requirements are covering safety mechanisms coming from :need:`gd_chklst__safety_analysis`
`147`	`147`	`-`
`148`	`148`	`-`
`149`	`149`	`-`
`150`	`150`	`* - REQ_09_02`
`151`		`- - For feature/component requirements: Do the requirements defining a safety mechanism contain the error reaction leading to a safe state?`
	`151`	`+ - Do the feature requirements defining a safety mechanism contain the error reaction leading to a safe state?`
`152`	`152`	`- Alternatively to the safe state there could also be "repair" mechanisms. Also do not forget to consider REQ_05_01 for these.`
`153`	`153`	`-`
`154`	`154`	`-`