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 index 0c455509dd..de15c94fe3 100644 --- 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 `) is implemented. Refer to `Tool Requirements `_ 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 `_ + - Will be removed from checklist once the requirement (:need:`Correlations of the architectural building blocks `) is implemented by automated tool check. See `Tool Requirements `_. + Details of possible linking can be depicted from :ref:`traceability concept `. - - - 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 index e232d2760e..c7d02c0bd3 100644 --- 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 `. - - - @@ -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 index ec8b4999ca..b1421449c4 100644 --- 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 `) is implemented. Refer to `Tool Requirements `_ 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 `_ + - Will be removed from checklist once the requirement (:need:`Correlations of the architectural building blocks `) is implemented by automated tool check. See `Tool Requirements `_. + Details of possible linking can be depicted from :ref:`traceability concept `. - - - 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 index 0370558762..e2dfe9d774 100644 --- 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 `.. - - - @@ -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 index 97b4535354..d913dbfe4b 100644 --- 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