Remove Covered attribute from req process

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

@@ -16,7 +16,7 @@
 .. document:: [Your Feature Name] Requirements Inspection Checklist
    :id: doc__feature_name_req_inspection
    :status: draft
-   :version: 1
+   :version: 2
    :safety: ASIL_B
    :security: YES
    :realizes: wp__requirements_inspect[version==1]
@@ -155,7 +155,12 @@ See also :need:`doc_concept__wp_inspections` for further information about revie
       -
       -
       -
-
+    * - REQ_10_01
+      - Is the requirement description *complete* ?
+      - For every requirement in the inspection, follow to its parent (stakeholder) requirement(s) and then check if this/these are fulfilled completely by its/their linked children (feature requirements, including those which are not in scope of the inspection).
+      -
+      -
+      -
 
 .. attention::
     The above checklist entries must be filled according to your component requirements in scope.

process/process_areas/requirements_engineering/guidance/requirements_guideline.rst

@@ -18,7 +18,7 @@ Guideline
 .. gd_guidl:: Requirements Guideline
    :id: gd_guidl__req_engineering
    :status: valid
-   :version: 1
+   :version: 2
    :complies: std_req__isopas8926__44421[version==1],
               std_req__isopas8926__44422[version==1],
               std_req__isopas8926__44423[version==1],
@@ -75,7 +75,7 @@ For all requirements following mandatory attributes are defined:
 
 * Title and description: For formulating requirements, the following template shall be used :need:`[[title]]<gd_temp__req_formulation>`
 * ID: The naming convention for the ID is defined for every project in a central place (e.g. in the general contributor's guidelines)
-* Furthermore the requirements need to be versioned. Therefore, a hash value of the requirement will to be calculated. The concept is described: :ref:`traceability concept for requirements`
+* Furthermore the requirements need to be versioned to document content changes, see :ref:`significant_requirement_changes`
 * For the remaining attributes only predefined values can be used. A more detailed description can be found here: :ref:`attributes of the requirements`
 * Note that "rationale" is only mandatory for Stakeholder Requirements.
 * Process requirements do not need the security and safety attributes because these can be derived from the standards they comply with. Type attributes are also unnecessary, as these requirements are always non‑functional.
@@ -124,11 +124,8 @@ This section describes in detail which steps need to be performed to create a re
    * - :ref:`6. <review_child_requirement>`
      - Merge valid child requirement to main branch
      - :need:`[[title]] <rl__committer>`
-   * - :ref:`7. <generate_linkage_document>`
-     - Generate linkage document
-     - :need:`[[title]] <rl__contributor>`
-   * - :ref:`8. <formal_requirement_review>`
-     - Perform formal review of requirements
+   * - :ref:`7. <formal_requirement_review>`
+     - Perform formal review (inspection) of requirements (or start with the next iteration of requirements changes)
      - :need:`[[title]] <rl__committer>`
 
 .. _create_parent_requirement:
@@ -180,20 +177,12 @@ Review child requirement
 
 As soon as also the child requirements are in a mature state they can be :ref:`reviewed <review_concept>` and merged into the main branch of the respective repository. Again this is not a formal inspection as it will be performed in a later step.
 
-.. _generate_linkage_document:
-
-Generate linkage document
--------------------------
-
-As parent and child requirements are now available, the linkage of the requirements can be established. This should be performed as described in :ref:`coverage_of_requirements`
-
-
 .. _formal_requirement_review:
 
 Perform formal review of requirements
 -------------------------------------
 
-In a last step the requirements shall be formally inspected. Therefore a checklist exists: :need:`[[title]] <gd_chklst__req_inspection>`
+In a last step the requirements shall be formally inspected. For this a checklist exists: see :need:`[[title]] <gd_chklst__req_inspection>`
 
 Following roles should be included in the review:
 

process/process_areas/requirements_engineering/guidance/requirements_inspection_checklist.rst

@@ -30,7 +30,6 @@ Requirement Inspection Checklist
               std_req__aspice_40__SWE-1-BP3[version==1],
               std_req__aspice_40__SWE-1-BP4[version==1],
               std_req__aspice_40__SWE-1-BP6[version==1]
-   :tags: requirements_engineering
 
    For the content see here:
 

process/process_areas/requirements_engineering/guidance/requirements_process_reqs.rst

@@ -73,7 +73,7 @@ Process Requirement Attributes
    :id: gd_req__req_attr_title
    :status: valid
    :version: 1
-   :tags: manual_prio_1 attribute, mandatory
+   :tags: manual_prio_1, attribute, mandatory
    :satisfies: wf__req_stkh_req[version==1],
                wf__req_feat_req[version==1],
                wf__req_comp_req[version==1],
@@ -270,19 +270,6 @@ Process Requirement Linkage
 
    Bi-directional traceability shall be provided by adding a "back-link" via attribute derives (i.e. make a <-> out of the <- in :need:`gd_req__req_linkage`).
 
-.. gd_req:: Requirement attribute: requirement covered
-   :id: gd_req__req_attr_req_cov
-   :status: valid
-   :version: 1
-   :tags: manual_prio_1, attribute
-   :complies: std_req__iso26262__support_6423[version==1], std_req__aspice_40__iic-13-51[version==1]
-   :satisfies: wf__req_stkh_req[version==1], wf__req_feat_req[version==1]
-
-   It shall be possible to specify the requirement coverage, meaning the requirement is covered fully by its linked children.
-
-      * Yes
-      * No
-
 .. gd_req:: Requirement attribute: link to implementation
    :id: gd_req__req_attr_impl
    :status: valid
@@ -318,12 +305,12 @@ Process Requirement Linkage
 .. gd_req:: Requirement attribute: versioning
    :id: gd_req__req_attr_version
    :status: valid
-   :version: 1
-   :tags: prio_1_automation, attribute
+   :version: 2
+   :tags: manual_prio_1, attribute, mandatory
    :satisfies: wf__req_stkh_req[version==1], wf__req_feat_req[version==1], wf__req_comp_req[version==1]
    :complies: std_req__iso26262__support_6425[version==1], std_req__iso26262__support_6434[version==1]
 
-   A versioning for requirements shall be provided. For this all mandatory attributes shall be taken into account: see :need:`gd_req__req_check_mandatory`
+   A versioning for requirements shall be provided. For this all significant attributes shall be taken into account: see :ref:`requirement_versioning`
 
 .. _process_requirement_checks:
 
@@ -333,15 +320,15 @@ Process Requirements Checks
 .. gd_req:: Requirement check: suspicious
    :id: gd_req__req_suspicious
    :status: valid
-   :version: 1
+   :version: 2
    :tags: prio_2_automation, check
    :satisfies: wf__req_stkh_req[version==1], wf__req_feat_req[version==1], wf__req_comp_req[version==1]
    :complies: std_req__iso26262__support_6425[version==1], std_req__iso26262__support_6434[version==1], std_req__aspice_40__iic-13-51[version==1]
 
    Based on the requirement versioning it shall be checked if a parent requirement was updated but not the linked child requirements (or tests).
-   In case an update was detected, the attribute `requirement covered` (or `complete test coverage`) shall be set to "No"
+   In case an update was detected, additionally the attribute `complete test coverage` shall be set to "No"
 
-   Note: This refers to :need:`gd_req__req_attr_req_cov` and :need:`gd_req__req_attr_test_covered`
+   Note: This refers to :need:`gd_req__req_attr_test_covered`
 
 .. gd_req:: Requirements mandatory attributes provided
    :id: gd_req__req_check_mandatory
@@ -459,6 +446,3 @@ Process Requirements Checks
 
    Validity attributes (:need:`gd_req__req_attr_valid_from` and :need:`gd_req__req_attr_valid_until`) shall be checked for correctness (i.e. they denote an existing milestone) and consistent (e.g. the until is not before from)
    Several of the above checks are not to be executed on requirements not valid in the next milestone, these are TBD
-
-.. needextend:: docname is not None and "process_areas/requirements_engineering" in docname
-   :+tags: requirements_engineering

process/process_areas/requirements_engineering/requirements_concept.rst

@@ -18,8 +18,7 @@ Concept Description
 .. doc_concept:: Requirements Concept
    :id: doc_concept__req_process
    :status: valid
-   :version: 1
-   :tags: requirements_engineering
+   :version: 2
 
 In this section a concept for the requirements management will be discussed. Inputs for this concepts are both the requirements of ISO26262 Part-8 and ASPICE Requirements from SWE.1 additionally including the requirements of the different stakeholders for the requirement process.
 
@@ -181,6 +180,8 @@ Following attributes need to be filled manually for each requirement:
      - The title of the requirement shall be expressive and rely to the description of the requirement.
    * - Description
      - In this attribute the content for the requirement will be specified. Please be aware that a note in a requirement is not part of the requirement itself. This means that notes should only be used to give additional explanation or context to the requirement.
+   * - Version
+     - Version of the requirement adapted with each significat change, see :ref:`significant_requirement_changes`.
    * - Rationale / Linkage
      - In either of those attributes the reasoning for the requirement is included.
        For *Stakeholder Requirements* a rationale which provides some more background infos shall be provided.
@@ -211,21 +212,12 @@ Following attributes are automatically generated:
    * - Derives
      - This attribute is automatically generated into the parent requirement based on the attribute derived_from of the current requirement
      - Docs-as-Code
-   * - Hash
-     - This attribute contains a hash value which is calculated over all mandatory requirement attributes. However this script needs to be executed manually, as this information is required to be present in the rst file.
-     - Script
-   * - Derived Hash
-     - It contains the hash of the parent requirement. If the parent requirement is changed the hash will also change and the linkage has to be revisited again. A more detailed description is provided here: :need:`gd_req__req_attr_version`
-     - Script
    * - Implemented by
      - During Build the code files are parsed for a defined tag which includes the requirement id. If this is located a link to the code will be added in the requirement
      - Docs-as-Code
    * - Verified by
      - During build the test files are parsed for a defined marker which includes the requirement id. If the marker is located in the test a link to the test case will be added to the requirement
      - Docs-as-Code
-   * - Requirement Covered
-     - During build it will be checked if the requirements hashes which are mentioned in the coverage file match the hashes of the linked child requirements. If so then this attribute will be set to yes.
-     - Docs-as-Code
 
 More details about the generation of the automated attributes are explained in the following chapter where the general workflow for generating requirements including their status is shown.
 
@@ -237,38 +229,42 @@ Requirements Versioning
 Individual Requirements
 =======================
 
-For the requirements the version management is basically provided by version management tooling (e.g. git history). However it needs to be identified if the content of a requirement changed. So this concept aims only at identifying a change in the mandatory attributes of a requirement.
-
-Calculate hash for current requirements
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-For each requirement a hash shall be calculated and stored in its dedicated own attribute *Hash* in the RST file. It shall include all mandatory manual attributes:
+For the requirements the version management is basically provided by version management tooling (e.g. git history). However it needs to be identified if the content of a requirement changed. So this concept aims only at identifying a significant change in the attributes of a requirement.
 
-.. _requirement_mandatory_attributes:
+.. _significant_requirement_changes:
 
-.. needtable:: Overview mandatory requirement attributes
-   :filter: "mandatory" in tags and "attribute" in tags and "requirements_engineering" in tags and type == "gd_req" and is_external == False
-   :style: table
-   :columns: title;id
-   :colwidths: 60,40
+Versioning on Significant Changes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-There shall be a tooling available which can be executed by the user during the creation of the requirements. This tooling shall calculate the hashes based on the mandatory attributes, calculate the hash values and enter the calculated hash values into the rst file for each requirement in the attribute *hash*.
+Only significant changes to the attributes of a requirement shall result in a version change,
+generally this is everything which may affect the content of the child requirements:
 
-During docs build it shall be checked if the attribute hash matches the actual has value of the requirement.
-
-Linking child requirements including hashes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+.. list-table:: Significant Attributes
+   :header-rows: 1
+   :widths: 30,35, 35
 
-If a requirement is linked to a top level requirement also the hash of the target requirement shall be part of the link. It shall automatically be written into the attribute *derived hash*. Upon docs build it shall be checked if the attribute *derived hash* matches the calculated hash of the requirement which is linked via *derived_from*.
+   * - Attribute link
+     - What is significant
+     - What is not significant
+   * - :need:`gd_req__req_attr_description`
+     - Functional changes and also re-writes which might lead to a better understanding of the content
+     - typo corrections, formal adaptions (e.g. layout), modifications of the requirement's notes
+   * - :need:`gd_req__req_attr_safety`
+     - every change
+     - n/a
+   * - :need:`gd_req__req_attr_security`
+     - every change
+     - n/a
+   * - :need:`gd_req__req_attr_type`
+     - every change
+     - n/a
 
-As this check is included in the docs build as a warning it can be guaranteed that a change of a parent requirement can only be merged if the `linkhashes` in the requirements are also updated in a `Depends-On` PR.
+Linking child requirements including versions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-.. figure:: _assets/requirements_versioning.drawio.svg
-   :alt: Requirements Versioning
-   :align: center
-   :width: 50%
+If a requirement is linked to a top level requirement also the version of the target requirement shall be part of the link. Upon docs build it shall be checked if the version contained in the link matches the *version* attribute of the requirement which is linked via *derived_from*.
 
-   Versioning of Requirements
+As this check is included in the docs build as a warning it can be guaranteed that a change of a parent requirement can only be merged if the derived child requirements are also updated accordingly.
 
 
 Sets of Requirements / Baselines
@@ -295,19 +291,19 @@ In the general for the reviews a :ref:`guideline <review_concept>` exists.
 Coverage of Requirements
 ************************
 
-According to the standards, requirements shall be derived from top to bottom. This means that at the point in time when the parent requirement is generated the coverage for itself can not be evaluated. In a second step all the parent requirements need to be broken down into child requirements which are linked to the parent requirement again. If during the creation of the child requirements any of the parent requirements would be touched again the hash value of the parent requirement would change and the linkage from the child to the parent requirement would be invalid again.
+According to the standards, requirements shall be derived from top to bottom. This means that at the point in time when the parent requirement is generated the coverage (by child requirements) can not be evaluated. In a second step every parent requirements need to be completely broken down into child requirements which are linked to the parent requirement.
 
-Therefore the information concerning requirement coverage is stored in a config file located in the same folder as the requirements file. It contains the parent requirements and its links to child requirements including hashes to the of the child requirements. If it is merged to the main branch it will specify exactly the coverage of child requirements which are required to fulfil the coverage of the parent requirement.
+The completeness of all the child requirements (i.e. that their parent requirement is "covered") will be confirmed latest in the formal review (inspection) of the child requirements.
 
-If this file will now be merged to the main branch a review will be triggered again. During this review it will only be checked if the parent requirement is covered by its child requirements.
+If after the creation of the child requirements any of the parent requirements would be touched again the version of the parent requirement would change and the linkage from the child to the parent requirement would be invalid again.
 
-Additionally during build it shall be checked if exactly the requirements and hashes which are specified in this file are linked to the requirement in the current documentation. If all items match then the requirement can be seen as covered. If now a child requirement is changed its hash will also be changed and the requirement coverage needs to be revisited again.
+Therefore the link from child to parent also contains the version of the parent - a mismatch should be detected automatically (e.g. during the documentation build).
 
 .. _traceability concept for requirements:
 
 Traceability Concept for Requirements
 *************************************
 
-The standards require that a requirement can be traced throughout the complete hierarchy levels including its :ref:`implementation <implementation>` and :ref:`verification <process_verification>`. In this project it is implemented the following way:
+The standards require that a requirement can be traced throughout the complete hierarchy levels including its :ref:`implementation <implementation>` and :ref:`verification <process_verification>`.
 
 In general the traceability is visualized in main development work product traceability model (:ref:`general_concepts_traceability`).

process/process_areas/requirements_engineering/requirements_getstrt.rst

@@ -18,8 +18,7 @@ Getting Started
 .. doc_getstrt:: Getting Started on Requirements
    :id: doc_getstrt__req_process
    :status: valid
-   :version: 1
-   :tags: requirements_engineering
+   :version: 2
 
 This document describes the steps which need to be done to create requirements, derive child requirements and finally to perform the formal requirement inspection.