Skip to content

Move platform AoU to req process #224

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
aschemmel-tech merged 1 commit into from
Oct 23, 2025
Merged

Move platform AoU to req process #224

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions process/process_areas/requirements_engineering/guidance/requirements_guideline.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -205,8 +205,9 @@ Following roles should be included in the review:
Workflow for Creating and Linking Assumption of Use (AoU)
=========================================================

An AoU is a category of requirement which is originates from a safety concept of an architectural element (and thus it is confirmed by a safety analysis).
As it can not be fulfilled by the architecture element (e.g. component) itself, it needs to be fulfilled by the user of the module.
An AoU is a category of requirement which originates from a safety concept of an architectural element (and thus it is confirmed by a safety analysis).
This is different for AoU created on SW-platform level, these are also coming from the scope of the project (i.e. the knowledge which safety activities are not part of a project).
As it can not be fulfilled by the architecture element (e.g. component) itself, it needs to be fulfilled by the user of the element.
In Safety Elements out of Context (SEooC) the AoUs will normally be part of the safety manual.
In this process description (as it describes SEooC development) these AoUs are created both internally and externally - the latter if existing SEooCs are integrated into the platform (e.g. a qualified Operating System).
For AoU which arise internally (i.e. from project specific modules) the template is almost identical to the one for feature/component requirements. The only difference is that it is defined such that the attribute "satisfies" is replaced with the attribute "mitigates" (see picture below).
Expand Down
2 changes: 1 addition & 1 deletion process/process_areas/requirements_engineering/guidance/requirements_templates.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -59,7 +59,7 @@ Templates
.. code-block:: rst

.. comp_req:: <Title>
:id: comp_req__<Component>__<Title>
:id: comp_req__<platform|Feature|Component>__<Title>
:reqtype: <Functional|Interface|Process|Non-Functional>
:security: <YES|NO>
:safety: <QM|ASIL_B>
Expand Down
2 changes: 1 addition & 1 deletion process/process_areas/requirements_engineering/requirements_concept.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -133,7 +133,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 module. Those requirements are called *Assumption of Use* (AoUs)
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).

.. code-block:: text

Expand Down
7 changes: 4 additions & 3 deletions process/process_areas/requirements_engineering/requirements_workflow.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,19 +16,20 @@
Workflow Requirements Engineering
#################################

.. workflow:: Create/Maintain Stakeholder requirements
.. workflow:: Create/Maintain Stakeholder requirements and SW-Platform AoU
:id: wf__req_stkh_req
:status: valid
:tags: requirements_engineering
:responsible: rl__contributor
:approved_by: rl__technical_lead
:supported_by: rl__safety_manager
:input: wp__policies, wp__issue_track_system
:output: wp__requirements_stkh
:output: wp__requirements_stkh, wp__requirements_sw_platform_aou
:contains: gd_temp__req_stkh_req, gd_temp__req_formulation
:has: doc_concept__req_process, doc_getstrt__req_process

Stakeholder requirements can be created during a change request. Any contributor can create a stakeholder requirement and propose it for approval.
Stakeholder requirements and SW-Platform Assumptions of Use (AoU) can be created during a change request.
Any contributor can create a stakeholder requirement (or AoU) and propose it for approval.

.. workflow:: Create/Maintain Feature requirements
:id: wf__req_feat_req
Expand Down
9 changes: 8 additions & 1 deletion process/process_areas/requirements_engineering/requirements_workproducts.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ Workproducts Requirements Engineering
:status: valid
:complies: std_wp__iso26262__system_651

Technical requirements from a stakeholder viewpoint and assumptions of use based on the integration as SW platform SEooC in an assumed context.
Technical requirements from a stakeholder viewpoint on SW-platform level, contain "assumed Technical Safety Requirements" in SW-Platform SEooC development.
Copy link
Contributor

@masc2023 masc2023 Oct 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only cosmetic, here SW-platform in other places also WP Definition, SW-Platform


.. workproduct:: Feature Requirements
:id: wp__requirements_feat
Expand All @@ -36,6 +36,13 @@ Workproducts Requirements Engineering

SW Requirements for components, broken down from feature requirements to the realizing component. These include configuration specification.

.. workproduct:: SW-Platform Assumptions of Use
:id: wp__requirements_sw_platform_aou
:status: valid
:complies: std_wp__iso26262__software_651

SW Safety Requirements for the user of the platform, exportable requirements for the user to integrate in their requirements management system.

.. workproduct:: Feature Assumptions of Use
:id: wp__requirements_feat_aou
:status: valid
Expand Down
8 changes: 0 additions & 8 deletions process/workproducts/index.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -65,14 +65,6 @@ Product development
Platform development
^^^^^^^^^^^^^^^^^^^^

.. workproduct:: SW-Platform Assumptions of Use
:id: wp__platform_sw_aou
:status: valid
:complies: std_wp__iso26262__software_651

SW Safety Requirements for the user of the platform, exportable requirements for the user to integrate in their requirements management system.


.. workproduct:: Platform Build Configuration
:id: wp__platform_sw_build_config
:status: draft
Expand Down
Loading