eclipse-score · aschemmel-tech · Mar 26, 2026
@@ -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.
       -
       -
       -

@@ -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`
       -
       -
       -

@@ -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.
       -
       -
       -

@@ -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`.
       -
       -
       -

@@ -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%

@@ -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::

@@ -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]] <gd_guidl__req_engineering>`) and allocated to the architectural elements via the attribute *fulfils*.
+In this step, the component requirements shall be derived (see :need:`[[title]] <gd_guidl__req_engineering>`) 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).

@@ -161,23 +161,23 @@ 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
    :satisfies: wf__cr_mt_featarch, wf__cr_mt_comparch
 
    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:**
 

@@ -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

@@ -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

@@ -175,7 +175,7 @@ Templates
          :id: gd_req__<process area or abbreviation>_<...>
          :status: <draft|valid>
          :tags: <process area or abbreviation>
-         :satisfies: <defined workflow:wf__<...>>, ..., <defined workflow:wf__<...>>
+         :derived_from: <defined workflow:wf__<...>>, ..., <defined workflow:wf__<...>>
          :complies: <standard requirement:std_req__<...>>, ..., <standard requirement:std_req__<...>>
 
 

@@ -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

@@ -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

@@ -54,7 +54,7 @@ Templates
 
       .. gd_req:: <Title>
          :id: gd_req__<process>__<Title>
-         :satisfies: <link to guidance id>
+         :derived_from: <link to guidance id>
          :complies: <link to standard requirement>
          :status: <valid|invalid>
 
@@ -69,7 +69,7 @@ Templates
          :id: tool_req__<tool>__<Title>
          :security: <YES|NO>
          :safety: <QM|ASIL_B>
-         :satisfies: <link to process req id>
+         :derived_from: <link to process req id>
          :status: <valid|invalid>
          :implemented: <YES|PARTIAL|NO>
 

@@ -49,7 +49,7 @@ Stakeholders for the requirements
 
 #. :need:`Tester <rl__committer>`
 
-   * 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 <rl__safety_engineer>`
@@ -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.
 

@@ -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`.