PR to fix issue_164

process/general_concepts/score_building_blocks_concept.rst

@@ -25,9 +25,9 @@ The following figure gives an overview about the building blocks of the project
 (blue box, top, 2nd column). The objectives of the project platform include
 enabling of feature integration for different use cases and domains. This includes safety-critical
 applications. Thus the intention is, that the platform can be developed as a Safety
-Element out of Context (**SEooC**) (green box, top, 1 column). The objectives of the platform are
+Element out of Context (**SEooC**) (green box, top, 1st column). The objectives of the platform are
 expressed as concrete **Stakeholder Requirements** (blue box, top, 2nd column), which can be tested
-by provided **Platform Tests** (blue box, top, 5nd column) for reference hardware platforms. The
+by provided **Platform Integration Tests** (blue box, top, 5th column) for reference hardware platforms. The
 platform consists of **Features** (yellow box, middle, 2nd column).
 
 Further the project provides **Software Modules** (red box, middle, 1st column), which can also be
@@ -37,28 +37,28 @@ highest level component in our model. A Software Module represents e.g. executab
 
 Components are the major building blocks of the platform. Components consists of **Units**
 (grey box, bottom, 2nd column), the lowest level in our model. The represent the source code,
-which implements the Unit. Units has a **Detailed Design** (grey box, middle, 3nd column), which is
-also implemented by the **Source Code** (grey box, bottom, 3nd column). The Detailed Design is
-verified by **Unit Tests** (grey box, middle, 5nd column).
+which implements the Unit. Units has a **Detailed Design** (grey box, middle, 3rd column), which is
+also implemented by the **Source Code** (grey box, bottom, 3rd column). The Detailed Design is
+verified by **Unit Tests** (grey box, middle, 5th column).
 
-Components are defined by **Component Requirements** (green box, middle, 3nd column) and the
-**Component Architecture** (green box, middle, 4nd column). A **Component Safety Analysis**
-(green box, middle, 6nd column) is required to verify the Component Architecture, whereby
+Components are defined by **Component Requirements** (green box, middle, 3rd column) and the
+**Component Architecture** (green box, middle, 4th column). A **Component Safety Analysis**
+(green box, middle, 6th column) is required to verify the Component Architecture, whereby
 violations of safety requirements must be documented. Potential faults
 may mitigated by updating the Component Requirements or by the **Component Assumptions of Use**
 (green box, middle, 8nd column). The latter one must be considered by the user of the Component.
-**Component Tests** (green box, middle, 5nd column) verify the Component requirements, and
-**Component Integration Tests** (green box, middle, 7nd column) verify the Component Architecture
+**Component Tests** (green box, middle, 5th column) verify the Component requirements, and
+**Component Integration Tests** (green box, middle, 7th column) verify the Component Architecture
 as well as the Integration of multiple Units to a Component.
 
 As mentioned above a Software Module is defined as a Component or a set of components realizing a
 Feature of the platform. Features consists of Components and are defined by **Feature Requirements**
-(yellow box, middle, 3nd column) and the **Feature Architecture** (yellow box, middle, 4nd column).
-A **Feature Safety Analysis** (yellow box, middle, 6nd column) is required to verify the Feature
+(yellow box, middle, 3rd column) and the **Feature Architecture** (yellow box, middle, 4th column).
+A **Feature Safety Analysis** (yellow box, middle, 6th column) is required to verify the Feature
 Architecture, whereby violations of safety requirements must be documented. Potential
 faults may mitigated by updating the Feature Requirements or by the
 **Feature Assumptions of Use** (yellow box, middle, 8nd column). The latter one must be considered
-by the user of the Feature. **Feature Integration Tests** (yellow box, middle, 5nd column) verify
+by the user of the Feature. **Feature Integration Tests** (yellow box, middle, 5th column) verify
 the Feature Requirements and the Feature Architecture as well as the Integration of multiple Units
 to a Component.
 

process/process_areas/quality_management/guidance/quality_plan_guideline.rst

@@ -65,7 +65,7 @@ Guideline Quality Management Plan
    |
    | **Planning integration and verification:**
    | Integration on the target hardware is not done in the scope of the SW platform project, but SW/SW integration up to the feature level is performed and its test results are part of the :need:`wp__verification_platform_ver_report`.
-   | The integration on the target hardware, done by the distributor or OEM, is supported by delivering a set of HW/SW feature integration and platform tests which were already run successfully on a reference HW platform.
+   | The integration on the target hardware, done by the distributor or OEM, is supported by delivering a set of HW/SW feature integration and platform integration tests which were already run successfully on a reference HW platform.
    | This is planned by the respective workproducts:
    | * :need:`wp__verification_feat_int_test`
    | * :need:`wp__verification_platform_test`

process/process_areas/requirements_engineering/requirements_concept.rst

@@ -183,6 +183,11 @@ Following attributes need to be filled manually for each requirement:
    * - Requirements Type
      - The requirement type defines which category the requirement relates to. Following categories are defined: [Functional, Interface, Process, Non-Functional]
 
+       - Functional: If implemented can be verified by a test (unit, integration)
+       - Interface: Does not define a functionality but the API provided to use the functionality
+       - Process: If implemented can be verified by reviewing the process description (sub-type of non-functional)
+       - Non-Functional: If implemented can be checked by review/analysis (of e.g. code, documentation)
+
        Note that the linking to the requirements is affected by these types, see :need:`gd_req__req_linkage_architecture`
 
 Following attributes are automatically generated:

process/process_areas/verification/guidance/verification_process_toolreqs.rst

@@ -91,17 +91,17 @@ Test Linking to Requirements
     :complies: std_req__iso26262__support_6432
 
 
-    For linking python tests to requirements **metadata** shall be used. 
-    For this the 'add_test_properties' decorator has been provided. 
+    For linking python tests to requirements **metadata** shall be used.
+    For this the 'add_test_properties' decorator has been provided.
     You need to add it to the test and fill out:
-    
-    * partially_verifies OR fully_verifies 
-    * test_type 
+
+    * partially_verifies OR fully_verifies
+    * test_type
     * derivation_technique
 
     For allowed values for test_type & derivation_technique please check :need:`gd_req__verification_link_tests`
     Further more, this decorator will also check if your test has a `docstring` which should act as the description of the test.
-   
+
 
     .. code-block:: python
 
@@ -178,7 +178,7 @@ Test Linking to Requirements
 
     - TestType and DerivationTechnique shall be set
     - Description shall not be empty
-    - In a Platform Test Partially/FullyVerifies shall be set to a Platform Requirement
+    - In a platform integration test Partially/FullyVerifies shall be set to a Platform Requirement
     - If Partially/FullyVerifies are set in Feature Integration Test these shall link to Feature Requirements
     - If Partially/FullyVerifies are set in Component Integration Test these shall link to Component Requirements
     - If Partially/FullyVerifies are set in Unit Test these shall link to Component Requirements

process/process_areas/verification/verification_concept.rst

@@ -155,7 +155,7 @@ Following aspect should be considered when developing test cases:
     For integration testing, the ITF (Integration Test Framework) is used.
 
     For more information, see ``[TODO: Link to ITF documentation once available. Related feature request is #599]``.
-* **Platform Testing:** Test the platform with configured features as a whole.
+* **platform integration testing:** Test the platform with configured features as a whole.
 * **Regression Testing:** Ensure that changes do not introduce new defects.
   Automate regression tests where possible as they will get executed as part of the CI.
 * **Performance Testing (when applicable):** Evaluate the performance characteristics of the code,
@@ -173,7 +173,7 @@ integration tests linking to the component requirements and architecture.
 Traceability of feature integration tests shall be established through linking those test cases to
 feature requirements and architecture as features describe the integrated behavior of all components.
 
-Traceability of platform tests shall be established through linking those test cases to
+Traceability of platform integration tests shall be established through linking those test cases to
 stakeholder requirements as stakeholder requirements describe the platform behavior.
 
 Note that all the above tests shall only link to requirements of type "Functional" and "Interface".

process/process_areas/verification/workflows.rst

@@ -90,7 +90,7 @@ Workflow Verification
    The tests are automatically executed as part of the CI after PR merge.
    In case of changes at inputs, the workflow need to be executed again as part of maintenance.
 
-.. workflow:: Create/Maintain Platform Test
+.. workflow:: Create/Maintain platform integration test
    :id: wf__verification_platform_test
    :status: valid
    :tags: verification
@@ -102,8 +102,8 @@ Workflow Verification
    :contains: gd_req__verification_link_tests, gd_req__verification_link_tests_cpp, gd_req__verification_link_tests_python, gd_req__verification_link_tests_rust, gd_req__verification_independence, gd_guidl__verification_specification
    :has: doc_concept__verification_process, doc_getstrt__verification_process
 
-   Platform test cases are based on Stakeholder requirements. This is the highest test level.
-   Any contributor can create a platform test and create a PR for it.
+   platform integration test cases are based on Stakeholder requirements. This is the highest test level.
+   Any contributor can create a platform integration test and create a PR for it.
    During the review process the test cases will be approved by a committer.
    Committer and contributor need to differ.
    The tests are automatically executed as part of the CI after PR merge.

process/process_areas/verification/workproducts.rst

@@ -31,12 +31,12 @@ Platform
    technology maturity or risks.
    This also covers the work product Verification Specification.
 
-.. workproduct:: Platform test
+.. workproduct:: platform integration test
    :id: wp__verification_platform_test
    :status: valid
    :complies: std_wp__iso26262__support_952
 
-   Platform Testing verifies Stakeholder Requirements performed on reference HW.
+   Platform integration testing verifies Stakeholder Requirements performed on reference HW.
    Depending on the nature of the project, respective tailoring (e.g. for reduced requirements
    coverage) has to be reflected in the :need:`wp__verification_plan` and :need:`wp__platform_safety_plan`.