eclipse-score · masc2023 · May 13, 2026 · Mar 26, 2026
@@ -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`
       -
       -
       -

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

@@ -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 fulfil the requirements does not introduce possible vulnerabilities
 
 #. **Safety Planning**
 
@@ -337,7 +337,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:
 
@@ -525,7 +525,8 @@ To make *needuml* work we have to replace the *need()* call with a different fun
       :status: valid
       :safety: ASIL_B
       :security: NO
-      :uses: logic_arc_int__example_feature__archcon_logical_interface_1
+      :uses: logic_arc_int__example_feature__archex_logical_interface_1
+      :fulfils: comp_req__example_feature__archex_example_req
       :belongs_to: comp__component_component_manual_getstrt
 
       .. needuml::

@@ -216,7 +216,8 @@ 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 may be established from architectural views to feature requirements via the attribute *fulfills*
+but all the feature requirements must be allocated to the feature element via the attribute *satisfied_by*.
 
 .. _review_architectural_design:
 
@@ -249,7 +250,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 respective component element via the attribute *satisfied_by*.
 
 .. _model_component_architecture:
 

@@ -168,7 +168,13 @@ Traceability to Requirements and AoU
    :complies: std_req__iso26262__support_6425, std_req__aspice_40__SWE-2-BP4
    :satisfies: wf__cr_mt_featarch, wf__cr_mt_comparch
 
-   Architectural views (feature/comp_arc_sta, feature/comp_arc_dyn) and interfaces (logic/real_arc_int) should be linked to a requirement.
+   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.
+
+   **Examples:**
+
+   * feat_req <-> feat_arc_(sta|dyn), logic_arc_(int|int_op)
+   * comp_req <-> comp_arc_(sta|dyn), real_arc_(int|int_op)
 
 .. gd_req:: Architecture attribute: fulfils (AoU)
    :id: gd_req__arch_attr_fulfils_aou
@@ -182,16 +188,16 @@ Traceability to Requirements and AoU
 .. gd_req:: Architecture traceability
    :id: gd_req__arch_traceability
    :status: valid
-   :tags: manual_prio_2
+   :tags: manual_prio_1
    :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:**
 
-   * feat_req <-> feat_arc_(sta|dyn), logic_arc_(int|int_op)
-   * comp_req <-> comp_arc_(sta|dyn), real_arc_(int|int_op)
+   * feat_req <-> feat
+   * comp_req <-> comp
 
    .. note::
       In general the traceability is visualized in :ref:`general_concepts_traceability`

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

@@ -55,7 +55,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

@@ -50,9 +50,6 @@ Templates
    * - AoU Requirements
      - :need:`[[title]] <gd_temp__req_aou_req>`
      - ``aou_req__``
-   * - Process Requirements
-     - :need:`[[title]] <gd_temp__req_process_req>`
-     - ``gd_req__``
    * - Tool Requirements
      - :need:`[[title]] <gd_temp__req_tool_req>`
      - ``tool_req__``
@@ -170,7 +167,7 @@ For this the following templates are available:
 
 Note: For non-functional (and process) type requirements no children need to be derived (on lower requirement levels),
 these can mostly be directly fulfilled and verified.
-To ease verification a link to these ("process" type) requirements can be established from :need:`gd_temp__req_process_req`.
+To ease verification a link to these ("process" type) requirements can be established from :need:`gd_temp__process_requirement`.
 
 .. _review_child_requirement:
 
@@ -227,9 +224,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 (architecture) (via fulfills), if those are on (external) Component Level and can be fulfilled by (internal) Feature/Component
+* to Feature/Component (architecture) (via fulfils), 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 fulfilled by platform or its components (alone) but need to be satisfied by the user of the 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 fulfilled by the user of the platform
 
 
 .. figure:: ../_assets/aou_traceability.drawio.svg
@@ -246,6 +243,9 @@ Internal component's AoU can also be fulfilled (and linked) by other internal co
 External component's AoUs which cannot be fulfilled by the platform alone are contained in the platform safety manual, whereas the internal component's AoUs
 are part of the module safety manual.
 
+Note that it is not mandatory to have component architecture (in case the component has no "sub" components).
+Therefore the "component" architecture element is depicted, which is used to link external Component Assumption of Use.
+
 Like other requirements also an AoU needs to be verified - but by the user of the feature/component.
 To improve the usability of a feature/component, its responsible team should already provide
 integration tests the user has to run to prove the fulfillment of the AoU(s).

@@ -21,7 +21,7 @@ Process Requirements
    :id: gd_req__req_structure
    :status: valid
    :tags: done_automation, structure
-   :satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool, wf__req_feat_aou, wf__req_comp_aou
+   :satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_tool, wf__req_feat_aou, wf__req_comp_aou
    :complies: std_req__iso26262__support_6431, std_req__iso26262__support_6432
 
    Requirements shall be hierarchically grouped into three levels.
@@ -46,7 +46,7 @@ Process Requirement Attributes
    :id: gd_req__req_attr_uid
    :status: valid
    :tags: manual_prio_1, attribute, mandatory
-   :satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool, wf__req_feat_aou, wf__req_comp_aou
+   :satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_tool, wf__req_feat_aou, wf__req_comp_aou
    :complies: std_req__iso26262__support_6425, std_req__iso26262__support_6432
 
    Each requirement shall have a unique ID. It shall consist of three parts:
@@ -61,7 +61,7 @@ Process Requirement Attributes
    :id: gd_req__req_attr_title
    :status: valid
    :tags: manual_prio_1 attribute, mandatory
-   :satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool, wf__req_feat_aou, wf__req_comp_aou
+   :satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_tool, wf__req_feat_aou, wf__req_comp_aou
    :complies: std_req__iso26262__support_6424
 
    The title of the requirement shall provide a short summary of the description, but is not an "additional" requirement.
@@ -72,7 +72,7 @@ Process Requirement Attributes
    :id: gd_req__req_attr_description
    :status: valid
    :tags: manual_prio_1, attribute, mandatory
-   :satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool, wf__req_feat_aou, wf__req_comp_aou
+   :satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_tool, wf__req_feat_aou, wf__req_comp_aou
    :complies: std_req__iso26262__support_6424
 
    Each requirement shall have a description.
@@ -183,13 +183,12 @@ Process Requirement Linkage
    :status: valid
    :tags: manual_prio_1, attribute
    :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
+   :satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_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
-      * workflow or stakeholder requirements <- process requirements
       * process requirements or stakeholder requirements <- tool requirements
 
 .. gd_req:: Requirement Linkage to AoU
@@ -212,9 +211,9 @@ Process Requirement Linkage
    :status: valid
    :tags: done_automation, attribute
    :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
+   :satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_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
@@ -287,7 +286,7 @@ Process Requirements Checks
    :id: gd_req__req_check_mandatory
    :status: valid
    :tags: done_automation, check
-   :satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool, wf__req_feat_aou, wf__req_comp_aou
+   :satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_tool, wf__req_feat_aou, wf__req_comp_aou
 
    It shall be checked if all mandatory attributes for each requirement is provided by the user. For all requirements following attributes shall be mandatory:
 
@@ -303,7 +302,7 @@ Process Requirements Checks
    :id: gd_req__req_desc_weak
    :status: valid
    :tags: done_automation, check
-   :satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool, wf__req_feat_aou, wf__req_comp_aou
+   :satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_tool, wf__req_feat_aou, wf__req_comp_aou
 
    It shall be ensured that no *weak words* are contained in the requirement description for:
 

@@ -49,18 +49,6 @@ Templates
    See the Assumption of Use requirement snippets in the
    `module template documentation <https://eclipse-score.github.io/module_template/aou_requirements_template.html>`__.
 
-.. gd_temp:: Process Requirements Template
-   :id: gd_temp__req_process_req
-   :status: valid
-   :complies: std_req__iso26262__support_641, std_req__iso26262__support_6421, std_req__iso26262__support_6425
-
-   .. code-block:: rst
-
-      .. gd_req:: <Title>
-         :id: gd_req__<process>__<Title>
-         :satisfies: <link to guidance id>
-         :complies: <link to standard requirement>
-         :status: <valid|invalid>
 
 .. gd_temp:: Tool Requirements Template
    :id: gd_temp__req_tool_req
@@ -73,7 +61,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>`
@@ -133,7 +133,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
 
@@ -207,13 +207,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
@@ -258,7 +258,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.
 

@@ -89,19 +89,19 @@ For a detailed explanation of workflows and their role within the process model,
 
    Based on the safety concept on component level, component AoUs can be derived. See also :ref:`aou_workflow`
 
-.. workflow:: Create/Maintain Process and Tool Requirements
-   :id: wf__req_proc_tool
+.. workflow:: Create/Maintain Tool Requirements
+   :id: wf__req_tool
    :status: valid
    :tags: requirements_engineering
    :responsible: rl__contributor
    :approved_by: rl__committer
    :supported_by: rl__safety_manager, rl__security_manager
    :input: wp__process_description
    :output: wp__requirements_proc_tool
-   :contains: gd_temp__req_process_req, gd_temp__req_tool_req, gd_temp__req_formulation
+   :contains: gd_temp__req_tool_req, gd_temp__req_formulation
    :has: doc_concept__req_process, doc_getstrt__req_process
 
-   Based on the process descriptions (which comply to standards) and/or stakeholder/feature/component requirements process and tool requirements are derived.
+   Based on the process descriptions (which comply to standards) and/or stakeholder/feature/component requirements tool requirements are derived.
 
 .. workflow:: Monitor/Verify Requirements
    :id: wf__monitor_verify_requirements