Improvement: Fix audit findings

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

@@ -45,6 +45,8 @@ communication and documentation of architectural decisions to stakeholders.
 Checklist
 ---------
 
+Please note that it is mandatory to fill in the "passed" column with "yes" or "no" for each checklist item and additional 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. See also :ref:`review_concept` for further information about reviews in general and inspection in particular.
+
 .. list-table:: Architecture Design Review Checklist
     :header-rows: 1
 

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

@@ -35,16 +35,16 @@ Feature Architecture
 
 Overview
 --------
-Brief summary
+<Brief summary>
 
 Description
 -----------
 
-General Description
+<General Description>
 
-Design Decisions - For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used.
+<Design Decisions - For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used.>
 
-Design Constraints
+<Design Constraints>
 
 Requirements
 ------------
@@ -58,9 +58,17 @@ Requirements
       :colwidths: 70,30
 
 
+.. needtable:: Overview of Feature Requirements
+   :style: table
+   :columns: title;id
+   :filter: search("feat_arch_sta__archdes$", "fulfils_back")
+   :colwidths: 70,30
+
+
 Rationale Behind Architecture Decomposition
 *******************************************
-mandatory: a motivation for the decomposition
+
+Mandatory: A motivation for the decomposition
 
 .. note:: Common decisions across features / cross cutting concepts is at the high level.
 
@@ -72,18 +80,18 @@ Static Architecture
    :security: YES
    :safety: ASIL_B
    :status: invalid
-   :includes: logic_arc_int__feature_name__interface_name
-   :consists_of: comp__component_name
+   :includes: logic_arc_int__feature_name__interface_name1
+   :consists_of: comp__component_name_template
 
    General Feature Description
 
-.. feat_arc_sta:: Static View
+.. feat_arc_sta:: Feature Static View
    :id: feat_arc_sta__feature_name__static_view
    :security: YES
    :safety: ASIL_B
    :status: invalid
    :fulfils: feat_req__feature_name__some_title
-   :includes: logic_arc_int__feature_name__interface_name
+   :includes: logic_arc_int__feature_name__interface_name1
 
    .. needarch::
       :scale: 50
@@ -107,7 +115,7 @@ Logical Interfaces
 ------------------
 
 .. logic_arc_int:: Interface Name
-   :id: logic_arc_int__feature_name__interface_name
+   :id: logic_arc_int__feature_name__interface_name1
    :security: YES
    :safety: ASIL_B
    :status: invalid
@@ -125,7 +133,7 @@ Logical Interfaces
    :security: YES
    :safety: ASIL_B
    :status: invalid
-   :included_by: logic_arc_int__feature_name__interface_name
+   :included_by: logic_arc_int__feature_name__interface_name1
 
    General Operation Description
 
@@ -135,9 +143,14 @@ Module Viewpoint
 The following modules are needed to be defined to be able to draw the static feature view.
 They will be replaced by linking the proper module definitions in the used module's repositories as soon as those exist.
 
-.. mod_view_sta:: Module Name
+.. mod:: Module Name
+   :id: mod__module_name
+   :includes: comp__component_name_template
+
+
+.. mod_view_sta:: Module Name Static View
    :id: mod_view_sta__feature_name__module_name
-   :includes: comp_arc_sta__feature_name__component_name
+   :includes: comp__component_name_template
 
    .. needarch::
       :scale: 50
@@ -151,18 +164,19 @@ Used Components
 The following components are needed to be defined to be able to draw the static feature view.
 They will be replaced by linking the proper SW component definitions in the used module's repositories as soon as those exist.
 
-.. comp_arc_sta:: Component Name
-   :id: comp_arc_sta__feature_name__component_name
-   :safety: ASIL_B
-   :security: YES
-   :status: invalid
-   :fulfils: comp_req__component_name__some_title
-   :implements: logic_arc_int__feature_name__interface_name
+.. code-block:: rst
+
+   .. comp:: Component Name
+      :id: comp__component_name_template
+      :safety: ASIL_B
+      :security: YES
+      :status: invalid
+      :implements: logic_arc_int__feature_name__interface_name1
 
 .. note::
    Architecture can be split into multiple files, it is an high level architecture design
    which can be shown without actual c++/rust interfaces and data types
-   and there will be link to lower level architecture till code to get actual api descriptions.
+   and there will be link to internal architecture till code to get actual api descriptions.
 
 .. attention::
     The above directives must be updated according to your feature architecture.

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

@@ -47,6 +47,8 @@ Requirement Inspection Checklist
 
    **Checklist**
 
+   See also :ref:`review_concept` for further information about reviews in general and inspection in particular.
+
    .. list-table:: Feature Requirement Inspection Checklist
       :header-rows: 1
       :widths: 10,30,50,6,6,8

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

@@ -45,6 +45,8 @@ communication and documentation of architectural decisions to stakeholders.
 Checklist
 ---------
 
+Please note that it is mandatory to fill in the "passed" column with "yes" or "no" for each checklist item and additional 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. See also :ref:`review_concept` for further information about reviews in general and inspection in particular.
+
 .. list-table:: Architecture Design Review Checklist
     :header-rows: 1
 

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

@@ -35,7 +35,7 @@ Component Architecture
 
 Overview
 --------
-Brief summary
+<Brief summary>
 
 Requirements Linked to Component Architecture
 ---------------------------------------------
@@ -51,16 +51,16 @@ Requirements Linked to Component Architecture
 Description
 -----------
 
-General Description
+<General Description>
 
-Design Decisions - For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used.
+<Design Decisions - For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used.>
 
-Design Constraints
+<Design Constraints>
 
 Rationale Behind Architecture Decomposition
 *******************************************
 
-Mandatory: a motivation for the decomposition or reason for not further splitting it into lower level components.
+Mandatory: A motivation for the decomposition or reason for not further splitting it into internal components.
 
 .. note:: Common decisions across components / cross cutting concepts is at the higher level.
 
@@ -71,18 +71,18 @@ The components are designed to cover the expectations from the feature architect
 (i.e. if already exists a definition it should be taken over and enriched).
 
 .. comp:: Component Name
-   :id: comp__component_name
+   :id: comp__component_name_template
    :security: YES
    :safety: ASIL_B
    :status: invalid
-   :implements: logic_arc_int__feature_name__interface_name
+   :implements: logic_arc_int__feature_name__interface_name1
 
 .. comp_arc_sta:: Component Name (Static View)
    :id: comp_arc_sta__component_name__static_view
    :security: YES
    :safety: ASIL_B
    :status: invalid
-   :implements: logic_arc_int__feature_name__interface_name
+   :implements: logic_arc_int__feature_name__interface_name1
    :fulfils: comp_req__component_name__some_title
    :includes: comp_arc_sta__component_name__2
 
@@ -117,16 +117,16 @@ Interfaces
       :fulfils: <link to component requirement id>
       :language: cpp
 
-Lower Level Components
-----------------------
+Internal Components
+-------------------
 
-.. comp_arc_sta:: Component Name 2
+.. comp_arc_sta:: Component Name Static View
    :id: comp_arc_sta__component_name__2
    :status: invalid
    :safety: ASIL_B
    :security: YES
    :fulfils: comp_req__component_name__some_title
-   :implements: logic_arc_int__feature_name__interface_name
+   :implements: logic_arc_int__feature_name__interface_name1
 
    No architecture but detailed design
 

process/folder_templates/modules/module_name/component_name/docs/detailed_design/chklst_impl_inspection.rst

@@ -43,6 +43,8 @@ by linking to C++ or Rust specific documentation.
 Checklist
 ---------
 
+See also :ref:`review_concept` 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

process/folder_templates/modules/module_name/component_name/docs/index.rst

@@ -46,11 +46,11 @@ Motivation
 
 [Clearly explain why the existing platform/project solution is inadequate to address the topic that the CR solves.]
 
-    .. note::
-     The motivation is critical for CRs that want to change the existing components.
-     It should clearly explain why the existing solution is inadequate to address the topic that the CR solves.
-     Motivation may based on criteria as resource requirements, scheduling issues, risks, benefits, etc.
-     CRs submissions without sufficient motivation may be rejected.
+.. note::
+   The motivation is critical for CRs that want to change the existing components.
+   It should clearly explain why the existing solution is inadequate to address the topic that the CR solves.
+   Motivation may based on criteria as resource requirements, scheduling issues, risks, benefits, etc.
+   CRs submissions without sufficient motivation may be rejected.
 
 
 
@@ -59,21 +59,19 @@ Rationale
 
 [Describe why particular design decisions were made.]
 
-
-   .. note::
-      The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
-      For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used.
+.. note::
+   The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
+   For the documentation of the decision the :need:`gd_temp__change_decision_record` can be used.
 
 Specification
 =============
 
 [Describe the requirements, architecture of any new component.] or
 [Describe the change to requirements, architecture, implementation, documentation of any change request.]
 
-   .. note::
-      A CR shall specify the component requirements as part of our platform/project.
-      Thereby the :need:`rl__project_lead` will approve these requirements as part of accepting the CR (e.g. merging the PR with the CR).
-
+.. note::
+   A CR shall specify the component requirements as part of our platform/project.
+   Thereby the :need:`rl__project_lead` will approve these requirements as part of accepting the CR (e.g. merging the PR with the CR).
 
 
 Backwards Compatibility
@@ -87,43 +85,43 @@ Security Impact
 
 [How could a malicious user take advantage of this new/modified component?]
 
-   .. note::
-      If there are security concerns in relation to the CR, those concerns should be explicitly written out to make sure reviewers of the CR are aware of them.
+.. note::
+   If there are security concerns in relation to the CR, those concerns should be explicitly written out to make sure reviewers of the CR are aware of them.
 
 Which security requirements are affected or has to be changed?
 Could the new/modified component enable new threat scenarios?
 Could the new/modified component enable new attack paths?
 Could the new/modified component impact functional safety?
 If applicable, which additional security measures must be implemented to mitigate the risk?
 
-    .. note::
-     Use Security Software Critically Analysis, Vulnerability Analysis.
-     [Methods will be defined later in Process area Security Analysis]
+.. note::
+   Use Security Software Critically Analysis, Vulnerability Analysis.
+   [Methods will be defined later in Process area Security Analysis]
 
 
 Safety Impact
 =============
 
 [How could the safety be impacted by the new/modified component?]
 
-   .. note::
-      If there are safety concerns in relation to the CR, those concerns should be explicitly written out to make sure reviewers of the CR are aware of them.
+.. note::
+   If there are safety concerns in relation to the CR, those concerns should be explicitly written out to make sure reviewers of the CR are aware of them.
 
 Which safety requirements are affected or has to be changed?
 Could the new/modified component be a potential common cause or cascading failure initiator?
 If applicable, which additional safety measures must be implemented to mitigate the risk?
 
-    .. note::
-     Use Dependency Failure Analysis and/or Safety Software Critically Analysis.
-     [Methods will be defined later in Process area Safety Analysis]
+.. note::
+   Use Dependency Failure Analysis and/or Safety Software Critically Analysis.
+   [Methods will be defined later in Process area Safety Analysis]
 
 For new feature/component contributions:
 
 [What is the expected ASIL level?]
 [What is the expected classification of the contribution?]
 
-   .. note::
-      Use the component classification method here to classify your component, if it shall to be used in a safety context: :need:`gd_temp__component_classification`.
+.. note::
+   Use the component classification method here to classify your component, if it shall to be used in a safety context: :need:`gd_temp__component_classification`.
 
 License Impact
 ==============
@@ -136,21 +134,19 @@ How to Teach This
 
 [How to teach users, new and experienced, how to apply the CR to their work.]
 
-   .. note::
-      For a CR that adds new functionality or changes behavior, it is helpful to include a section on how to teach users, new and experienced, how to apply the CR to their work.
-
-
+.. note::
+   For a CR that adds new functionality or changes behavior, it is helpful to include a section on how to teach users, new and experienced, how to apply the CR to their work.
 
 Rejected Ideas
 ==============
 
 [Why certain ideas that were brought while discussing this CR were not ultimately pursued.]
 
-   .. note::
-      Throughout the discussion of a CR, various ideas will be proposed which are not accepted.
-      Those rejected ideas should be recorded along with the reasoning as to why they were rejected.
-      This both helps record the thought process behind the final version of the CR as well as preventing people from bringing up the same rejected idea again in subsequent discussions.
-      In a way this section can be thought of as a breakout section of the Rationale section that is focused specifically on why certain ideas were not ultimately pursued.
+.. note::
+   Throughout the discussion of a CR, various ideas will be proposed which are not accepted.
+   Those rejected ideas should be recorded along with the reasoning as to why they were rejected.
+   This both helps record the thought process behind the final version of the CR as well as preventing people from bringing up the same rejected idea again in subsequent discussions.
+   In a way this section can be thought of as a breakout section of the Rationale section that is focused specifically on why certain ideas were not ultimately pursued.
 
 
 
@@ -159,10 +155,10 @@ Open Issues
 
 [Any points that are still being decided/discussed.]
 
-   .. note::
-       While a CR is in draft, ideas can come up which warrant further discussion.
-       Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution.
-       This helps make sure all issues required for the CR to be ready for consideration are complete and reduces people duplicating prior discussion.
+.. note::
+   While a CR is in draft, ideas can come up which warrant further discussion.
+   Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution.
+   This helps make sure all issues required for the CR to be ready for consideration are complete and reduces people duplicating prior discussion.
 
 
 

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

@@ -47,6 +47,8 @@ Requirement Inspection Checklist
 
    **Checklist**
 
+   See also :ref:`review_concept` for further information about reviews in general and inspection in particular.
+
    .. list-table:: Component Requirement Inspection Checklist
       :header-rows: 1
       :widths: 10,30,50,6,6,8

process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_analysis_fdr.rst

@@ -38,6 +38,8 @@ The purpose of this Safety Analysis (DFA and FMEA) checklist template is to coll
 
 **Checklist**
 
+Please note that it is mandatory to fill in the "passed" column with "yes" or "no" for each checklist item and additional 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. See also :ref:`review_concept` for further information about reviews in general and inspection in particular.
+
 .. list-table:: Safety Analysis Checklist
       :header-rows: 1
       :widths: 10,30,30,15,8,8