Extend versioned links concept for reqs and arch

process/process_areas/architecture_design/architecture_concept.rst

@@ -340,6 +340,51 @@ Establish traceability between requirements and architectural elements
 
 During the architectural design process all feature and component requirements shall be allocated to a single architecture element at the corresponding level via the attribute **satisfies**.
 
+.. _architecture_versioning:
+
+Architecture Versioning
+***********************
+
+Individual Architecture Elements and Views
+==========================================
+
+For the architecture the version management is basically provided by version management tooling (e.g. git history).
+However to support impact analysis via versioned links also a "version" attribute is maintained for architectural elements (feat, comp, logic_arc_int) and views (feat/comp_arch_sta, feat/comp_arch_dyn).
+
+.. _significant_architecture_changes:
+
+Versioning on Significant Changes
+---------------------------------
+
+Only significant changes to the attributes of a requirement (or AoU) shall result in a version change,
+generally this is everything which may affect the content of the child requirements or other linked work products like the architecture:
+
+.. list-table:: Significant Attributes
+   :header-rows: 1
+   :widths: 30,35, 35
+
+   * - Attribute
+     - What is significant
+     - What is not significant
+   * - description
+     - Addition/deletion/modification of elements in a view, operations in an interface, feature/component request functional changes for feat/comp elements
+     - typo corrections, formal adaptions (e.g. layout)
+   * - :need:`gd_req__arch_attr_safety`
+     - every change
+     - n/a
+   * - :need:`gd_req__arch_attr_security`
+     - every change
+     - n/a
+
+Linking child elements including versions
+-----------------------------------------
+
+If an element/view is linked to a "parent" also the version of the parent shall be part of the link. Upon docs build it is checked if the version contained in the link matches the *version* attribute of parent.
+
+As this check is included in the docs build as a warning it can be guaranteed that a change of a parent can only be merged if the derived child are also updated accordingly.
+
+All links to and from architecture elements/views as depicted in :ref:`Building Blocks Overwiew <general_concepts_building_blocks>` shall use versioing.
+
 .. _reviews of the architecture:
 
 Reviews of the architecture

process/process_areas/architecture_design/guidance/architecture_process_reqs.rst

@@ -173,6 +173,28 @@ Attributes of Architectural Elements
    * valid
    * invalid
 
+.. gd_req:: Architecture attribute: version
+   :id: gd_req__arch_attr_version
+   :status: valid
+   :version: 1
+   :tags: manual_prio_2, attribute, mandatory
+   :satisfies:  wf__cr_mt_featarch[version==1], wf__cr_mt_comparch[version==1]
+   :complies: std_req__iso26262__support_8453[version==1]
+
+   A version attribute for architectural elements (feat, feat_arch_sta, feat_arch_dyn, logic_arc_int, comp, comp_arch_sta, comp_arch_dyn) shall be provided.
+
+.. gd_req:: Architecture attribute: versioning hash
+   :id: gd_req__arch_attr_version_hash
+   :status: valid
+   :version: 1
+   :tags: prio_2_automation
+   :satisfies:  wf__cr_mt_featarch[version==1], wf__cr_mt_comparch[version==1]
+   :complies: std_req__iso26262__support_8453[version==1]
+
+   For automatically created views a hash shall be calculated from the generated image source code and documented as a version.
+
+   Note: Automatically created views are for example supported for static views and interfaces.
+
 Diagram Linkage
 '''''''''''''''
 
@@ -194,7 +216,7 @@ Diagram Linkage
    :complies: std_req__iso26262__support_6421[version==1], std_req__iso26262__support_6425[version==1]
    :satisfies: wf__sw_detailed_design[version==1]
 
-   Each diagram shall be automatically linked (inverse direction) to the corresponding component id via the "belongs by" linkage.
+   Each diagram shall be automatically linked (inverse direction) to the corresponding component id via the "has" linkage.
 
 Traceability to Requirements and AoU
 ------------------------------------
@@ -208,13 +230,15 @@ Traceability to Requirements and AoU
    :satisfies: wf__cr_mt_featarch[version==1], wf__cr_mt_comparch[version==1]
 
    Architectural views (feature/comp_arc_sta, feature/comp_arc_dyn) and interfaces (logic/real_arc_int)
-   should be linked to a requirement on the corresponding level.
+   shall be linked to its corresponding requirement on the corresponding level.
 
    **Examples:**
 
    * feat_req <-> feat_arc_(sta|dyn), logic_arc_int
    * comp_req <-> comp_arc_(sta|dyn), real_arc_int
 
+   Note: This supports change impact analysis (via versioned links) and is not redundant to the "belongs_to" backlink as there can be multiple views/interfaces.
+
 .. gd_req:: Architecture attribute: fulfils (AoU)
    :id: gd_req__arch_attr_fulfils_aou
    :status: valid

process/process_areas/requirements_engineering/guidance/requirements_process_reqs.rst

@@ -308,9 +308,9 @@ Process Requirement Linkage
    :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]
+   :complies: std_req__iso26262__support_6425[version==1], std_req__iso26262__support_6434[version==1], std_req__iso26262__support_8453[version==1]
 
-   A versioning for requirements shall be provided. For this all significant attributes shall be taken into account: see :ref:`requirement_versioning`
+   A versioning for requirements and AoU shall be provided. For this all significant attributes shall be taken into account: see :ref:`requirement_versioning`
 
 .. _process_requirement_checks:
 
@@ -320,15 +320,12 @@ Process Requirements Checks
 .. gd_req:: Requirement check: suspicious
    :id: gd_req__req_suspicious
    :status: valid
-   :version: 3
+   :version: 4
    :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]
+   :complies: 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 requirement was updated but not the linked tests.
-   In case an update was detected the attribute `complete test coverage` shall be set to "No"
-
-   Note: This refers to :need:`gd_req__req_attr_test_covered`
+   Based on the requirement versioning it shall be checked if a requirement was updated but not the linked tests and code.
 
 .. gd_req:: Requirements mandatory attributes provided
    :id: gd_req__req_check_mandatory

process/process_areas/requirements_engineering/requirements_concept.rst

@@ -236,8 +236,8 @@ For the requirements the version management is basically provided by version man
 Versioning on Significant Changes
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-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:
+Only significant changes to the attributes of a requirement (or AoU) shall result in a version change,
+generally this is everything which may affect the content of the child requirements or other linked work products like the architecture:
 
 .. list-table:: Significant Attributes
    :header-rows: 1
@@ -262,7 +262,7 @@ generally this is everything which may affect the content of the child requireme
 Linking child requirements including versions
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-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*.
+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 is checked if the version contained in the link matches the *version* attribute of the requirement which is linked via *derived_from*.
 
 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.
 

process/process_areas/verification/verification_workflows.rst

@@ -213,7 +213,7 @@ For a detailed explanation of workflows and their role within the process model,
             wp__requirements_feat_aou[version==1],
             wp__requirements_comp[version==1],
             wp__requirements_comp_aou[version==1]
-   :contains: gd_req__req_attr_test_covered[version==1], gd_req__req_suspicious[version==3], gd_guidl__verification_guide[version==2]
+   :contains: gd_req__req_attr_test_covered[version==1], gd_req__req_suspicious[version==4], gd_guidl__verification_guide[version==2]
    :has: doc_concept__verification_process[version==1], doc_getstrt__verification_process[version==1]
 
    The requirement attribute `complete test coverage` is set to `yes` by a :need:`rl__committer` when it is verified