Add artifacts for requirements analysis

pahmann · pahmann · commit 65ab6c5b2df4 · 2025-12-16T20:42:55.000+01:00
Resolves: eclipse-score/score#577 Signed-off-by: Philipp Ahmann <Philipp.Ahmann@de.bosch.com>
diff --git a/process/folder_templates/features/feature_name/index.rst b/process/folder_templates/features/feature_name/index.rst
@@ -194,3 +194,4 @@ Footnotes
    safety_analysis/fmea.rst
    safety_analysis/dfa.rst
    safety_planning/index.rst
+   verification/req_analysis.rst
diff --git a/process/folder_templates/features/feature_name/verification/req_analysis.rst b/process/folder_templates/features/feature_name/verification/req_analysis.rst
@@ -0,0 +1,38 @@
+..
+   # *******************************************************************************
+   # Copyright (c) 2025 Contributors to the Eclipse Foundation
+   #
+   # See the NOTICE file(s) distributed with this work for additional
+   # information regarding copyright ownership.
+   #
+   # This program and the accompanying materials are made available under the
+   # terms of the Apache License Version 2.0 which is available at
+   # https://www.apache.org/licenses/LICENSE-2.0
+   #
+   # SPDX-License-Identifier: Apache-2.0
+   # *******************************************************************************
+
+.. _feature_req_analysis_template:
+
+Requirement Analysis
+####################
+
+.. document:: [Your Feature Name] Requirement Analysis
+   :id: doc__feature_name_req_analysis
+   :status: draft
+   :safety: ASIL_B
+   :security: YES
+   :realizes: wp__verification_req_analysis
+   :tags: template
+
+.. attention::
+    The above directive must be updated according to your Feature.
+
+    - Modify ``Your Feature Name`` to be your Feature Name
+    - Modify ``id`` to be your Feature Name in upper snake case preceded by ``doc__`` and succeeded by ``_req_analysis``
+    - Adjust ``status`` to be ``valid``
+    - Adjust ``safety`` and ``tags`` according to your needs
+
+
+Rational
+--------
diff --git a/process/folder_templates/modules/module_name/component_name/docs/index.rst b/process/folder_templates/modules/module_name/component_name/docs/index.rst
@@ -183,3 +183,4 @@ Footnotes
    requirements/chklst_req_inspection.rst
    safety_analysis/fmea.rst
    safety_analysis/dfa.rst
+   verification/req_analysis.rst
diff --git a/process/folder_templates/modules/module_name/component_name/docs/verification/req_analysis.rst b/process/folder_templates/modules/module_name/component_name/docs/verification/req_analysis.rst
@@ -0,0 +1,38 @@
+..
+   # *******************************************************************************
+   # Copyright (c) 2025 Contributors to the Eclipse Foundation
+   #
+   # See the NOTICE file(s) distributed with this work for additional
+   # information regarding copyright ownership.
+   #
+   # This program and the accompanying materials are made available under the
+   # terms of the Apache License Version 2.0 which is available at
+   # https://www.apache.org/licenses/LICENSE-2.0
+   #
+   # SPDX-License-Identifier: Apache-2.0
+   # *******************************************************************************
+
+.. _component_req_analysis_template:
+
+Requirement Analysis
+####################
+
+.. document:: [Your Component Name] Requirement Analysis
+   :id: doc__component_name_req_analysis
+   :status: draft
+   :safety: ASIL_B
+   :security: YES
+   :realizes: wp__verification_req_analysis
+   :tags: template
+
+.. attention::
+    The above directive must be updated according to your Component.
+
+    - Modify ``Your Component Name`` to be your Component Name
+    - Modify ``id`` to be your Component Name in upper snake case preceded by ``doc__`` and succeeded by ``_req_analysis``
+    - Adjust ``status`` to be ``valid``
+    - Adjust ``safety`` and ``tags`` according to your needs
+
+
+Rational
+--------
diff --git a/process/process_areas/verification/verification_concept.rst b/process/process_areas/verification/verification_concept.rst
@@ -167,7 +167,7 @@ stakeholder requirements as stakeholder requirements describe the platform behav
 
 Note that all the above tests shall only link to requirements of type "Functional" and "Interface".
 The verification of requirements of types "Process" and "Non-Functional" will be done via Analysis,
-which is a verification method still to be defined. ``[TODO: Link to Analysis process once available. See ticket #577]``
+which is a verification method described in :need:`wf__verification_req_analysis`.
 
 Requirements always include Assumptions Of Use.
 
diff --git a/process/process_areas/verification/verification_workflows.rst b/process/process_areas/verification/verification_workflows.rst
@@ -111,6 +111,35 @@ For a detailed explanation of workflows and their role within the process model,
    The tests are automatically executed as part of the CI after PR merge.
    In case of changes at inputs, the workflow need to be executed again as part of maintenance.
 
+.. workflow:: Perform/Maintain Requirements Analysis
+   :id: wf__verification_req_analysis
+   :status: valid
+   :tags: verification
+   :responsible: rl__contributor
+   :approved_by: rl__committer, rl__testing_community
+   :supported_by: rl__safety_manager, rl__testing_community
+   :input: wp__feature_arch, wp__requirements_feat, wp__requirements_feat_aou,
+           wp__component_arch, wp__requirements_comp, wp__requirements_comp_aou,
+           wp__sw_implementation, wp__verification_plan
+   :output: wp__verification_req_analysis
+   :contains: gd_req__verification_link_tests, gd_req__verification_independence, gd_guidl__verification_specification
+   :has: doc_concept__verification_process, doc_getstrt__verification_process
+
+   This only applies in the special case that some requirements cannot be feasibly tested.
+
+   In such cases – and only such cases – it is acceptable to indicate in the Requirements Analysis Report
+   that not a test but a review shall verify the correct implementation of the related requirement.
+   To signal this special situation to the test engineers (who do not need to specify a test case for the related requirement then),
+   one or both of the following fixed texts shall be entered in the Requirements Analysis Report:
+
+     Tag: **Covered-by-design-review.**
+     The fulfillment of this requirement shall be verified as part of feature/component design reviews
+     (for feature/component requirements) respective software architectural design or software detailed design reviews.
+
+     Tag: **Covered-by-code-review.**
+     The fulfillment of this requirement shall be verified as part of code reviews.
+
+
 .. workflow:: Create Verification Plan
    :id: wf__verification_plan
    :status: valid
diff --git a/process/process_areas/verification/verification_workproducts.rst b/process/process_areas/verification/verification_workproducts.rst
@@ -145,6 +145,21 @@ Component
    The compiled tests run against the actual source code compiled for the component or reference integration and their
    targeted HW architecture (e.g. arm64 or x86).
 
+.. workproduct:: Requirement Analysis
+   :id: wp__verification_req_analysis
+   :status: valid
+   :complies: std_wp__iso26262__software_951
+
+   Requirement Analysis is performed for non-functional requirements (NFRs) which cannot be (feasibly) tested.
+   As example performance requirements may not be functional requirements, but they still can be tested.
+   Though, some requirements cannot be feasibly tested in such cases – and only such cases – it is acceptable
+   to perform a requirements analysis.
+
+   This work product provides the evidence about the NFR for the project.
+
+   Note, that there is also the DerivationTechnique named "requirements-analysis" which can be used for "requirements-based" TestTypes.
+   It is described in :ref:`verification_concept_types_methods`.
+
 Inspection
 **********
 
