diff --git a/process/process_areas/requirements_engineering/guidance/requirements_guideline.rst b/process/process_areas/requirements_engineering/guidance/requirements_guideline.rst index df83cbd644..5529193236 100644 --- a/process/process_areas/requirements_engineering/guidance/requirements_guideline.rst +++ b/process/process_areas/requirements_engineering/guidance/requirements_guideline.rst @@ -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). diff --git a/process/process_areas/requirements_engineering/guidance/requirements_templates.rst b/process/process_areas/requirements_engineering/guidance/requirements_templates.rst index aa827745d0..9557d69873 100644 --- a/process/process_areas/requirements_engineering/guidance/requirements_templates.rst +++ b/process/process_areas/requirements_engineering/guidance/requirements_templates.rst @@ -59,7 +59,7 @@ Templates .. code-block:: rst .. comp_req:: - :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> diff --git a/process/process_areas/requirements_engineering/requirements_concept.rst b/process/process_areas/requirements_engineering/requirements_concept.rst index 90e6a6935e..ab41b10a01 100644 --- a/process/process_areas/requirements_engineering/requirements_concept.rst +++ b/process/process_areas/requirements_engineering/requirements_concept.rst @@ -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 diff --git a/process/process_areas/requirements_engineering/requirements_workflow.rst b/process/process_areas/requirements_engineering/requirements_workflow.rst index bdf4f8ec6e..0130cde34a 100644 --- a/process/process_areas/requirements_engineering/requirements_workflow.rst +++ b/process/process_areas/requirements_engineering/requirements_workflow.rst @@ -16,7 +16,7 @@ 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 @@ -24,11 +24,12 @@ Workflow Requirements Engineering :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 diff --git a/process/process_areas/requirements_engineering/requirements_workproducts.rst b/process/process_areas/requirements_engineering/requirements_workproducts.rst index 1ab17e3999..e30e6e4c46 100644 --- a/process/process_areas/requirements_engineering/requirements_workproducts.rst +++ b/process/process_areas/requirements_engineering/requirements_workproducts.rst @@ -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. .. workproduct:: Feature Requirements :id: wp__requirements_feat @@ -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 diff --git a/process/workproducts/index.rst b/process/workproducts/index.rst index c137a501ae..80de76800f 100644 --- a/process/workproducts/index.rst +++ b/process/workproducts/index.rst @@ -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