From 9471e13d4b74e9ca38675d38a2974c8db553fe74 Mon Sep 17 00:00:00 2001 From: aschemmel-git Date: Fri, 2 Oct 2026 12:11:40 +0200 Subject: [PATCH] Extend versioning process for reqs and arch Refers: #785 --- .../architecture_concept.rst | 45 +++++++++++++++++++ .../guidance/architecture_process_reqs.rst | 28 +++++++++++- .../guidance/requirements_process_reqs.rst | 13 +++--- .../requirements_concept.rst | 6 +-- .../verification/verification_workflows.rst | 2 +- 5 files changed, 80 insertions(+), 14 deletions(-) diff --git a/process/process_areas/architecture_design/architecture_concept.rst b/process/process_areas/architecture_design/architecture_concept.rst index a1919112e0..87357c3f2a 100644 --- a/process/process_areas/architecture_design/architecture_concept.rst +++ b/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 ` shall use versioing. + .. _reviews of the architecture: Reviews of the architecture diff --git a/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst b/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst index 1357efcf69..f7d5cc1078 100644 --- a/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst +++ b/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 diff --git a/process/process_areas/requirements_engineering/guidance/requirements_process_reqs.rst b/process/process_areas/requirements_engineering/guidance/requirements_process_reqs.rst index 0a9aaeedc9..ef66677996 100644 --- a/process/process_areas/requirements_engineering/guidance/requirements_process_reqs.rst +++ b/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 diff --git a/process/process_areas/requirements_engineering/requirements_concept.rst b/process/process_areas/requirements_engineering/requirements_concept.rst index 0aa597d5af..0bea81046e 100644 --- a/process/process_areas/requirements_engineering/requirements_concept.rst +++ b/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. diff --git a/process/process_areas/verification/verification_workflows.rst b/process/process_areas/verification/verification_workflows.rst index 797cff51df..cebef53885 100644 --- a/process/process_areas/verification/verification_workflows.rst +++ b/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