Merge pull request #224 from eclipse-score/aschemmel-tech-move-platform-aou

Move platform AoU to req process

Author: aschemmel-tech

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

process/process_areas/requirements_engineering/guidance/requirements_templates.rst

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

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
 

process/process_areas/requirements_engineering/requirements_workflow.rst

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

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

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