Update req attribute and workflow for test coverage

This is triggered by the meeting minutes and discussion with the testing community. See here for details:
https://github.com/orgs/eclipse-score/discussions/2234?sort=new#discussioncomment-16050359

Signed-off-by: Philipp Ahmann <philipp.ahmann@de.bosch.com>

Author: pahmann

process/process_areas/requirements_engineering/guidance/requirements_process_reqs.rst

@@ -245,14 +245,14 @@ Process Requirement Linkage
 
    It shall be possible to link requirements to tests and automatically include a link to the test case in the attribute testlink.
 
-.. gd_req:: Requirement attribute: test covered
+.. gd_req:: Requirement attribute: complete test coverage
    :id: gd_req__req_attr_test_covered
    :status: valid
    :tags: manual_prio_1, attribute
    :satisfies: wf__req_feat_req, wf__req_comp_req
    :complies: std_req__iso26262__support_6433, std_req__iso26262__software_944, std_req__aspice_40__iic-13-51
 
-   It shall be possible to specify if requirements are completely covered by the linked test cases.
+   It shall be possible to specify if a requirement is completely satisfied by the linked test case(s).
 
       * Yes
       * No
@@ -279,7 +279,7 @@ Process Requirements Checks
    :complies: std_req__iso26262__support_6425, std_req__iso26262__support_6434, std_req__aspice_40__iic-13-51
 
    Based on the requirement versioning it shall be checked if a parent requirement was updated but not the linked child requirements (or tests).
-   In case an update was detected, the attribute requirement (or test) covered shall be set to "No"
+   In case an update was detected, the attribute `requirement covered` (or `complete test coverage`) shall be set to "No"
 
    Note: This refers to :need:`gd_req__req_attr_req_cov` and :need:`gd_req__req_attr_test_covered`
 

process/process_areas/verification/guidance/verification_guideline.rst

@@ -84,6 +84,8 @@ For multiple test cases having a "partial coverage" a review has to be conducted
 that a requirement is fully covered. The pull request description should indicate which requirements
 are fully covered by the PR commits and which test cases are needed to fully cover the test case.
 This is important, as multiple PRs may be needed to fully verify a single requirement.
+This information is later on used to set the requirement attribute to `yes` as mentioned by :need:`gd_req__req_attr_test_covered`
+which shows that the set of partially covering test cases in sum fully satisfy the requirement.
 
 
 Test case execution

process/process_areas/verification/verification_workflows.rst

@@ -150,6 +150,28 @@ For a detailed explanation of workflows and their role within the process model,
    Note that during the initial creation of the verification plan in :need:`wf__verification_plan`
    not every input down to component level may be available.
 
+.. workflow:: Set Requirement Test Coverage
+   :id: wf__verification_req_test_coverage
+   :status: valid
+   :tags: verification
+   :responsible: rl__committer, rl__testing_community
+   :approved_by: rl__project_lead
+   :supported_by: rl__safety_manager, rl__infrastructure_tooling_community
+   :input: wp__requirements_stkh, wp__requirements_feat, wp__requirements_feat_aou,
+           wp__requirements_comp, wp__requirements_comp_aou,
+           wp__verification_plan, wp__verification_sw_unit_test,
+           wp__verification_comp_int_test, wp__verification_feat_int_test, wp__verification_platform_int_test
+   :output: wp__requirements_stkh, wp__requirements_feat, wp__requirements_feat_aou,
+            wp__requirements_comp, wp__requirements_comp_aou
+   :contains: gd_req__req_attr_test_covered, gd_req__req_suspicious, gd_guidl__verification_guide
+   :has: doc_concept__verification_process, doc_getstrt__verification_process
+
+   The requirement attribute `complete test coverage` is set to `yes` by a :need:`rl__committer` when it is verified
+   that the requirement is fully covered by test cases. This means the linked test cases in sum fully satisfy the requirement.
+
+   A fully covered requirement will be set to `no` automatically via the implementation of the check described in :need:`gd_req__req_suspicious`.
+   A recheck is needed in this case to get the status back to `yes`.
+
 .. workflow:: Create Module Verification Report
    :id: wf__verification_mod_ver_report
    :status: valid