diff --git a/process/folder_templates/features/feature_name/architecture/chklst_arc_inspection.rst b/process/folder_templates/features/feature_name/architecture/chklst_arc_inspection.rst
index 2a7344cef5..7a10c882f0 100644
--- a/process/folder_templates/features/feature_name/architecture/chklst_arc_inspection.rst
+++ b/process/folder_templates/features/feature_name/architecture/chklst_arc_inspection.rst
@@ -81,7 +81,7 @@ See also :need:`doc_concept__wp_inspections` for further information about revie
-
* - ARC_01_03
- If the architectural element is related to any supplier manuals (including safety and security), are the relevant parts covered?
- - If the architecture makes use of supplied elements, their manuals (like safety) have to be considered (i.e. its provided functionality matches the expectation and assumptions are fulfilled). Note that in case of safety component this means that assumed Technical Safety Requirements and AoUs of the safety manual are covered.
+ - If the architecture makes use of supplied elements, their manuals (like safety) have to be considered (i.e. its provided functionality matches the expectation and assumptions are satisfied). Note that in case of safety component this means that assumed Technical Safety Requirements and AoUs of the safety manual are covered.
-
-
-
diff --git a/process/folder_templates/features/feature_name/requirements/chklst_req_inspection.rst b/process/folder_templates/features/feature_name/requirements/chklst_req_inspection.rst
index 62ec0dff59..550bea405e 100644
--- a/process/folder_templates/features/feature_name/requirements/chklst_req_inspection.rst
+++ b/process/folder_templates/features/feature_name/requirements/chklst_req_inspection.rst
@@ -132,7 +132,7 @@ See also :need:`doc_concept__wp_inspections` for further information about revie
-
* - REQ_07_02
- Is the *security* attribute set correctly?
- - For feature requirements this checklist item is supported by automated check: "Every requirement which satisfies a stakeholder requirement with security attribute set to YES inherits this". But the feature requirements/architecture may additionally also be subject to a :need:`wp__feature_security_analysis`
+ - For feature requirements this checklist item is supported by automated check: "Every requirement which is derived from a stakeholder requirement with security attribute set to YES inherits this". But the feature requirements/architecture may additionally also be subject to a :need:`wp__feature_security_analysis`
-
-
-
diff --git a/process/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.rst b/process/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.rst
index 781ad63bd9..0e772c35b6 100644
--- a/process/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.rst
+++ b/process/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.rst
@@ -82,7 +82,7 @@ See also :need:`doc_concept__wp_inspections` for further information about revie
* - ARC_01_03
- If the architectural element is related to any supplier manuals (incl. safety and security)
are the relevant parts covered?
- - If the architecture makes use of supplied elements, their manuals (like safety) have to be considered (i.e. its provided functionality matches the expectation and assumptions are fulfilled). Note that in case of safety component this means that assumed Technical Safety Requirements and AoUs of the safety manual are covered.
+ - If the architecture makes use of supplied elements, their manuals (like safety) have to be considered (i.e. its provided functionality matches the expectation and assumptions are satisfied). Note that in case of safety component this means that assumed Technical Safety Requirements and AoUs of the safety manual are covered.
-
-
-
diff --git a/process/folder_templates/modules/module_name/component_name/docs/requirements/chklst_req_inspection.rst b/process/folder_templates/modules/module_name/component_name/docs/requirements/chklst_req_inspection.rst
index 0136a8b5d3..c7d22cdf06 100644
--- a/process/folder_templates/modules/module_name/component_name/docs/requirements/chklst_req_inspection.rst
+++ b/process/folder_templates/modules/module_name/component_name/docs/requirements/chklst_req_inspection.rst
@@ -132,7 +132,7 @@ See also :need:`doc_concept__wp_inspections` for further information about revie
-
* - REQ_07_02
- Is the attribute *security* set correctly?
- - For component requirements this checklist item is supported by automated check: "Every requirement which satisfies a feature requirement with security attribute set to YES inherits this". But the component requirements/architecture may additionally also be subject to a :need:`wp__sw_component_security_analysis`.
+ - For component requirements this checklist item is supported by automated check: "Every requirement which derives from a feature requirement with security attribute set to YES inherits this". But the component requirements/architecture may additionally also be subject to a :need:`wp__sw_component_security_analysis`.
-
-
-
diff --git a/process/general_concepts/_assets/score_building_blocks_meta_model.drawio.svg b/process/general_concepts/_assets/score_building_blocks_meta_model.drawio.svg
index 6655290a55..d8d91cb79d 100644
--- a/process/general_concepts/_assets/score_building_blocks_meta_model.drawio.svg
+++ b/process/general_concepts/_assets/score_building_blocks_meta_model.drawio.svg
@@ -1,4 +1,4 @@
-
+
diff --git a/process/general_concepts/_assets/score_building_blocks_meta_model_deployment_example.drawio.svg b/process/general_concepts/_assets/score_building_blocks_meta_model_deployment_example.drawio.svg
index 3dbdbc450b..9e184d5334 100644
--- a/process/general_concepts/_assets/score_building_blocks_meta_model_deployment_example.drawio.svg
+++ b/process/general_concepts/_assets/score_building_blocks_meta_model_deployment_example.drawio.svg
@@ -1,4 +1,4 @@
-
+
-
\ No newline at end of file
+
diff --git a/process/general_concepts/_assets/score_traceability_model_cmp_overview_1.drawio.svg b/process/general_concepts/_assets/score_traceability_model_cmp_overview_1.drawio.svg
index e353683ec6..4ebe20e967 100644
--- a/process/general_concepts/_assets/score_traceability_model_cmp_overview_1.drawio.svg
+++ b/process/general_concepts/_assets/score_traceability_model_cmp_overview_1.drawio.svg
@@ -1,4 +1,4 @@
-
+
diff --git a/process/general_concepts/_assets/score_traceability_model_cmp_overview_2.drawio.svg b/process/general_concepts/_assets/score_traceability_model_cmp_overview_2.drawio.svg
index f83d4c29c2..3d8a757b5e 100644
--- a/process/general_concepts/_assets/score_traceability_model_cmp_overview_2.drawio.svg
+++ b/process/general_concepts/_assets/score_traceability_model_cmp_overview_2.drawio.svg
@@ -1,4 +1,4 @@
-
+
diff --git a/process/general_concepts/_assets/score_traceability_model_cmp_overview_3.drawio.svg b/process/general_concepts/_assets/score_traceability_model_cmp_overview_3.drawio.svg
index 92b647b770..316c93c683 100644
--- a/process/general_concepts/_assets/score_traceability_model_cmp_overview_3.drawio.svg
+++ b/process/general_concepts/_assets/score_traceability_model_cmp_overview_3.drawio.svg
@@ -1,4 +1,4 @@
-
+
-
\ No newline at end of file
+
diff --git a/process/general_concepts/_assets/score_traceability_model_feat_overview.drawio.svg b/process/general_concepts/_assets/score_traceability_model_feat_overview.drawio.svg
index a2135d9bb8..db384b26e5 100644
--- a/process/general_concepts/_assets/score_traceability_model_feat_overview.drawio.svg
+++ b/process/general_concepts/_assets/score_traceability_model_feat_overview.drawio.svg
@@ -1,4 +1,4 @@
-
+
diff --git a/process/general_concepts/_assets/score_traceability_model_wp_overview.drawio.svg b/process/general_concepts/_assets/score_traceability_model_wp_overview.drawio.svg
index 3acd77918c..deca68e4f7 100644
--- a/process/general_concepts/_assets/score_traceability_model_wp_overview.drawio.svg
+++ b/process/general_concepts/_assets/score_traceability_model_wp_overview.drawio.svg
@@ -1,4 +1,4 @@
-
+
diff --git a/process/general_concepts/score_building_blocks_concept.rst b/process/general_concepts/score_building_blocks_concept.rst
index 645d340ef5..d37d2201d3 100644
--- a/process/general_concepts/score_building_blocks_concept.rst
+++ b/process/general_concepts/score_building_blocks_concept.rst
@@ -92,11 +92,11 @@ Features have **Logical Architecture Interfaces** (green box, middle, 3rd column
are implemented (and can be used) by the components.
**Assumptions of Use** are not specific for a level as it is not fixed where they will be
-fulfilled and verified, so they are depicted "white". In the picture one can also see two
+satisfied and verified, so they are depicted "white". In the picture one can also see two
variants of Assumptions of Use: "own" AoU required by the own element towards other elements and
-the "other" AoU asked from other element towards the own element and fulfilled by it.
+the "other" AoU asked from other element towards the own element and satisfied by it.
Generally the metamodel refers only within own architecture element (=component/feature), but
-AoUs need the fulfills link own -> other.
+AoUs need the satisfies link own -> other.
.. figure:: _assets/score_building_blocks_meta_model.drawio.svg
:width: 100%
diff --git a/process/process_areas/architecture_design/_assets/architecture_workflow.drawio.svg b/process/process_areas/architecture_design/_assets/architecture_workflow.drawio.svg
index bf392be01f..1340c8a753 100644
--- a/process/process_areas/architecture_design/_assets/architecture_workflow.drawio.svg
+++ b/process/process_areas/architecture_design/_assets/architecture_workflow.drawio.svg
@@ -1,4 +1,4 @@
-
\ No newline at end of file
+
diff --git a/process/process_areas/architecture_design/architecture_concept.rst b/process/process_areas/architecture_design/architecture_concept.rst
index 435b8cd7b3..ea58b7cc54 100644
--- a/process/process_areas/architecture_design/architecture_concept.rst
+++ b/process/process_areas/architecture_design/architecture_concept.rst
@@ -51,7 +51,7 @@ Use Cases which require architectural information
#. **Security Analysis**
- * The architecture created to fulfill the requirements does not introduce possible vulnerabilities
+ * The architecture created to satisfy the requirements does not introduce possible vulnerabilities
#. **Safety Planning**
@@ -384,7 +384,7 @@ Following attributes need to be filled manually for each requirement:
- This attribute describes the impact of the architectural element on functional safety. Currently only following values are defined [QM, ASIL_B]. Other values are not required at the moment as *ASIL decomposition* is not used so far.
* - Security
- This attribute describes if the architectural element has any impact on the security of the platform. [YES,NO]
- * - Fulfils
+ * - Satisfies
- With this attribute the relations to the corresponding requirements shall be described
For creating architectural elements also templates for each level are available:
@@ -397,7 +397,7 @@ For creating architectural elements also templates for each level are available:
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 **fulfils**.
+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**.
.. _reviews of the architecture:
@@ -556,7 +556,7 @@ The following section is an example, how an component looks like and how the det
:status: valid
:safety: ASIL_B
:security: NO
- :fulfils: comp_req__example_feature__archex_example_req
+ :satisfies: comp_req__example_feature__archex_example_req
:belongs_to: comp__component_component_getstrt
.. needarch::
@@ -630,7 +630,7 @@ To make *needuml* work we have to replace the *need()* call with a different fun
:safety: ASIL_B
:security: NO
:uses: logic_arc_int__example_feature__archex_logical_interface_1
- :fulfils: comp_req__example_feature__archex_example_req
+ :satisfies: comp_req__example_feature__archex_example_req
:belongs_to: comp__component_component_manual_getstrt
.. needuml::
diff --git a/process/process_areas/architecture_design/guidance/architecture_guideline.rst b/process/process_areas/architecture_design/guidance/architecture_guideline.rst
index c698da8b75..ea09f3f171 100644
--- a/process/process_areas/architecture_design/guidance/architecture_guideline.rst
+++ b/process/process_areas/architecture_design/guidance/architecture_guideline.rst
@@ -141,7 +141,7 @@ In the next step, the already derived feature requirements shall be allocated to
If needed, additional feature requirements, which may arise due to architectural decisions, should be created and allocated to the feature architecture itself.
-These links shall be established from architectural elements to feature requirements via the attribute *fulfils*.
+These links shall be established from architectural elements to feature requirements via the attribute *satisfies*.
.. _review_architectural_design:
@@ -174,7 +174,7 @@ For this step, the following guidance is available: :need:`Feature Architecture
Allocate component requirements to architectural elements
---------------------------------------------------------
-In this step, the component requirements shall be derived (see :need:`[[title]] `) and allocated to the architectural elements via the attribute *fulfils*.
+In this step, the component requirements shall be derived (see :need:`[[title]] `) and allocated to the architectural elements via the attribute *satisfies*.
.. _model_component_architecture:
@@ -233,7 +233,7 @@ architecture description.
Generally dynamic views are expected in the feature view and the component view based on the following considerations:
-- Do not use dynamic views, if the fulfillment of the requirements by the architecture is already understandable with the static view.
+- Do not use dynamic views, if the satisfying of the requirements by the architecture is already understandable with the static view.
- Simple caller/callee relation is not expected to be modelled (this would mean that the examples would be too simple for modelling).
- There should be more than two components involved.
- In case of safety-related calls/communication, the error cases shall also be displayed (see the "alt" boxes in the examples).
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 12e641b34c..c156c03849 100644
--- a/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst
+++ b/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst
@@ -161,8 +161,8 @@ Attributes of Architectural Elements
Traceability to Requirements and AoU
------------------------------------
-.. gd_req:: Architecture attribute: fulfils
- :id: gd_req__arch_attr_fulfils
+.. gd_req:: Architecture attribute: satisfies
+ :id: gd_req__arch_attr_satisfies
:status: valid
:tags: manual_prio_1, attribute, mandatory
:complies: std_req__iso26262__support_6425, std_req__aspice_40__SWE-2-BP4
@@ -170,14 +170,14 @@ Traceability to Requirements and AoU
Each architectural view (feature/comp_arc_sta, feature/comp_arc_dyn) and interface (logic/real_arc_int) shall be linked to a requirement.
-.. gd_req:: Architecture attribute: fulfils (AoU)
- :id: gd_req__arch_attr_fulfils_aou
+.. gd_req:: Architecture attribute: satisfies (AoU)
+ :id: gd_req__arch_attr_satisfies_aou
:status: valid
:tags: manual_prio_1, attribute, mandatory
:complies: std_req__iso26262__support_6425, std_req__aspice_40__SWE-2-BP4
:satisfies: wf__cr_mt_featarch, wf__cr_mt_comparch
- Each architectural static view (feature/comp_arc_sta) shall be linked to AoUs if the element (feature/comp) fulfills these.
+ Each architectural static view (feature/comp_arc_sta) shall be linked to AoUs if the element (feature/comp) satisfies these.
.. gd_req:: Architecture traceability
:id: gd_req__arch_traceability
@@ -186,7 +186,7 @@ Traceability to Requirements and AoU
:complies: std_req__iso26262__support_6432, std_req__aspice_40__SWE-2-BP4
:satisfies: wf__cr_mt_featarch, wf__cr_mt_comparch
- Requirements shall be fulfilled by an architectural element on the corresponding level.
+ Requirements shall be satisfied by an architectural element on the corresponding level.
**Examples:**
diff --git a/process/process_areas/change_management/guidance/change_management_reqs.rst b/process/process_areas/change_management/guidance/change_management_reqs.rst
index b30fb42537..e05e1b2c97 100644
--- a/process/process_areas/change_management/guidance/change_management_reqs.rst
+++ b/process/process_areas/change_management/guidance/change_management_reqs.rst
@@ -182,7 +182,7 @@ Change Request Traceability Impact Analysis Tool
The picture is derived from the building blocks metamodel containing all the work products
(:ref:`general_concepts_building_blocks`). Its arrows show how every work product is
linked (manually) to other work products (e.g. feature requirements are linked to
- stakeholder requirements via "satisfies"). The color code describes which of these Links
+ stakeholder requirements via "derived_from"). The color code describes which of these Links
need to be followed for the impact analysis (so for the example this means: if a stakeholder
requirement is changed, the feature requirements linked are affected, but not the other way round).
"Black" links do not need to be followed, these are the "verifies" links. And these are
diff --git a/process/process_areas/implementation/guidance/implementation_guideline.rst b/process/process_areas/implementation/guidance/implementation_guideline.rst
index 41a1dc54ee..0a6abd9d5a 100644
--- a/process/process_areas/implementation/guidance/implementation_guideline.rst
+++ b/process/process_areas/implementation/guidance/implementation_guideline.rst
@@ -54,7 +54,7 @@ the static and the dynamic view for unit interactions is described.
:width: 30%
:name: static_view_fig
-The static diagram statisfies the architecture and implements the requirements of the related component. The static diagram includes Unit1+2.
+The static diagram satisfies the architecture and implements the requirements of the related component. The static diagram includes Unit1+2.
.. figure:: _assets/dynamic_view.drawio.svg
diff --git a/process/process_areas/process_management/guidance/process_management_templates.rst b/process/process_areas/process_management/guidance/process_management_templates.rst
index 8235ffd31c..6f8a5b22d4 100644
--- a/process/process_areas/process_management/guidance/process_management_templates.rst
+++ b/process/process_areas/process_management/guidance/process_management_templates.rst
@@ -175,7 +175,7 @@ Templates
:id: gd_req___<...>
:status:
:tags:
- :satisfies: >, ..., >
+ :derived_from: >, ..., >
:complies: >, ..., >
diff --git a/process/process_areas/requirements_engineering/_assets/aou_traceability.drawio.svg b/process/process_areas/requirements_engineering/_assets/aou_traceability.drawio.svg
index 6539053380..5c193afa75 100644
--- a/process/process_areas/requirements_engineering/_assets/aou_traceability.drawio.svg
+++ b/process/process_areas/requirements_engineering/_assets/aou_traceability.drawio.svg
@@ -1,4 +1,4 @@
-
+
diff --git a/process/process_areas/requirements_engineering/_assets/requirements_versioning.drawio.svg b/process/process_areas/requirements_engineering/_assets/requirements_versioning.drawio.svg
index 2adc5603bb..cea2669e24 100644
--- a/process/process_areas/requirements_engineering/_assets/requirements_versioning.drawio.svg
+++ b/process/process_areas/requirements_engineering/_assets/requirements_versioning.drawio.svg
@@ -1,4 +1,4 @@
-
\ No newline at end of file
+
diff --git a/process/process_areas/requirements_engineering/_assets/requirements_workflow.drawio.svg b/process/process_areas/requirements_engineering/_assets/requirements_workflow.drawio.svg
index a06cc5452a..09873202b3 100644
--- a/process/process_areas/requirements_engineering/_assets/requirements_workflow.drawio.svg
+++ b/process/process_areas/requirements_engineering/_assets/requirements_workflow.drawio.svg
@@ -1,4 +1,4 @@
-
\ No newline at end of file
+
diff --git a/process/process_areas/requirements_engineering/guidance/requirements_guideline.rst b/process/process_areas/requirements_engineering/guidance/requirements_guideline.rst
index 16d6d16dd8..a443af9543 100644
--- a/process/process_areas/requirements_engineering/guidance/requirements_guideline.rst
+++ b/process/process_areas/requirements_engineering/guidance/requirements_guideline.rst
@@ -220,9 +220,9 @@ In this workflow (as it describes SEooC development) these AoUs are created both
AoUs can be of different class and shall be handled by tracing those
-* to Feature/Component (via satisfies), if those are on (external) Component Level and can be fulfilled by (internal) Feature/Component
-* to Stakeholder Requirements (via satisfies), if AoU are of general nature and can be fulfilled by platform
-* or by containing those in Platform(s) Safety Manual(s), if AoU cannot be fulfilled by platform or its components (alone) but need to be satisfied by the user of the platform
+* to Feature/Component (architecture) (via satisfies), if those are on (external) Component Level and can be fulfilled by (internal) Feature/Component
+* to Stakeholder Requirements (via covers), if AoU are of general nature and can be fulfilled by platform
+* or by containing those in Platform(s) Safety Manual(s), if AoU cannot be satisfied by platform or its components (alone) but need to be satisfied by the user of the platform
.. figure:: ../_assets/aou_traceability.drawio.svg
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 63b137fcf5..1ddf71bd41 100644
--- a/process/process_areas/requirements_engineering/guidance/requirements_process_reqs.rst
+++ b/process/process_areas/requirements_engineering/guidance/requirements_process_reqs.rst
@@ -185,7 +185,7 @@ Process Requirement Linkage
:complies: std_req__iso26262__support_6432, std_req__aspice_40__SWE-1-BP5
:satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool
- Requirements shall be linked to its adjacent level via the attribute satisfies.
+ Requirements shall be linked to its adjacent level via the attribute derived_from.
* stakeholder requirements <- feature requirements
* feature requirements <- component requirements
@@ -214,7 +214,7 @@ Process Requirement Linkage
:complies: std_req__iso26262__support_6432, std_req__aspice_40__SWE-1-BP5
:satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool
- Bi-directional traceability shall be provided by adding a "back-link" via attribute satisfied by (i.e. make a <-> out of the <- in :need:`gd_req__req_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
diff --git a/process/process_areas/requirements_engineering/guidance/requirements_templates.rst b/process/process_areas/requirements_engineering/guidance/requirements_templates.rst
index 624c3205dd..27b8a9e540 100644
--- a/process/process_areas/requirements_engineering/guidance/requirements_templates.rst
+++ b/process/process_areas/requirements_engineering/guidance/requirements_templates.rst
@@ -54,7 +54,7 @@ Templates
.. gd_req::
:id: gd_req____
- :satisfies:
+ :derived_from:
:complies:
:status:
@@ -69,7 +69,7 @@ Templates
:id: tool_req____
:security:
:safety:
- :satisfies:
+ :derived_from:
:status:
:implemented:
diff --git a/process/process_areas/requirements_engineering/requirements_concept.rst b/process/process_areas/requirements_engineering/requirements_concept.rst
index c8d6caf0c0..3529875e72 100644
--- a/process/process_areas/requirements_engineering/requirements_concept.rst
+++ b/process/process_areas/requirements_engineering/requirements_concept.rst
@@ -49,7 +49,7 @@ Stakeholders for the requirements
#. :need:`Tester `
- * Verify that the specification is fulfilled by the elements under test
+ * Verify that the specification is satisfied by the elements under test
* Consider AoUs for test case specification
#. :need:`Safety Architect `
@@ -131,7 +131,7 @@ However the detailed interaction of the underlying components itself which is re
Component Requirements
======================
-The lowest abstraction level is represented by the *component requirements*. They are derived from *feature requirements* and describe component specific implementation details. It is described which behaviour a component itself needs to fulfil in the context of the feature, for example:
+The lowest abstraction level is represented by the *component requirements*. They are derived from *feature requirements* and describe component specific implementation details. It is described which behaviour a component itself needs to satisfy in the context of the feature, for example:
.. code-block:: text
@@ -140,7 +140,7 @@ The lowest abstraction level is represented by the *component requirements*. The
Assumption of Use Requirements
==============================
-Last but not least a requirement type is needed which describes e.g. the boundary conditions which need to be fulfilled when using a software element. Those requirements are called *Assumption of Use* (AoUs) and can be defined on every level (stakeholder/SW-platform, feature, component). Example:
+Last but not least a requirement type is needed which describes e.g. the boundary conditions which need to be satisfied when using a software element. Those requirements are called *Assumption of Use* (AoUs) and can be defined on every level (stakeholder/SW-platform, feature, component). Example:
.. code-block:: text
@@ -205,13 +205,13 @@ Following attributes are automatically generated:
* - Attribute
- Description
- Tool
- * - Satisfied by
- - This attribute is automatically generated into the parent requirement based on the attribute satisfies of the current requirement
+ * - 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
- * - Satisfies Hash
+ * - 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
@@ -256,7 +256,7 @@ During docs build it shall be checked if the attribute hash matches the actual h
Linking child requirements including hashes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-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 *satisfies hash*. Upon docs build it shall be checked if the attribute *satisfies hash* matches the calculated hash of the requirement which is linked via *satisfies*.
+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*.
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.
diff --git a/process/process_areas/safety_analysis/safety_analysis_concept.rst b/process/process_areas/safety_analysis/safety_analysis_concept.rst
index ad22f2bd5e..e7b40508fd 100644
--- a/process/process_areas/safety_analysis/safety_analysis_concept.rst
+++ b/process/process_areas/safety_analysis/safety_analysis_concept.rst
@@ -33,7 +33,7 @@ To have a structured DFA the failure initiators have to be applied :need:`gd_gui
| - Unintended impact: Unintended impacts to function due to various failures like deadlocks or memory depletion.
| - Development failure initiators: Failures that occur during the development process, potentially leading to safety issues.
-The objective of the **FMEA** is to show that the architecture created to fulfil the requirements does not introduce possible errors which would
+The objective of the **FMEA** is to show that the architecture created to satisfy the requirements does not introduce possible errors which would
break the safety requirements. Or rather that the possibility of these errors is reduced to an acceptable level. This can be done by detection, prevention or mitigation.
The FMEA is used to find possible failures and their effects. The possible failures are systematically identified by applying fault models :need:`gd_guidl__fault_models`.
diff --git a/process/process_areas/safety_management/safety_management_workproducts.rst b/process/process_areas/safety_management/safety_management_workproducts.rst
index 7b8f9162df..77315ff2e0 100644
--- a/process/process_areas/safety_management/safety_management_workproducts.rst
+++ b/process/process_areas/safety_management/safety_management_workproducts.rst
@@ -93,7 +93,7 @@ Safety Management Work Products
* The Assumed Platform Requirements (Safety related);
* the safety concept of the SEooC (i.e. which faults are taken care of);
- * the Assumptions of Use (of the platform level), including AoU of external components to be fulfilled also by the user;
+ * the Assumptions of Use (of the platform level), including AoU of external components to be satisfied also by the user;
* links to all the module safety manuals of the platform integration;
* a link to the (platform) user manual;
* the reactions of the implemented functions under anomalous operating conditions; and