Change to valid_inspected state

process/folder_templates/platform/features/feature_name/requirements/req_inspection.rst

@@ -19,7 +19,7 @@
 .. document:: [Feature Name] Requirements Inspection
    :id: doc__feature_name_req_inspection
    :status: draft
-   :version: 2
+   :version: 3
    :safety: ASIL_B
    :security: YES
    :realizes: wp__requirements_inspect[version==1]
@@ -190,10 +190,10 @@ Summary
 Inspected Requirements
 ^^^^^^^^^^^^^^^^^^^^^^
 
-The following requirements in "valid" state and with "inspected" tag set are in the scope of this inspection:
+The following requirements in "valid_inspected" state are in the scope of this inspection:
 
 .. needtable::
-   :filter: "feature_name" in docname and "requirements" in docname and docname is not None and status == "valid"
+   :filter: "feature_name" in docname and "requirements" in docname and docname is not None
    :style: table
    :types: feat_req
    :tags: feature_name
@@ -204,10 +204,10 @@ The following requirements in "valid" state and with "inspected" tag set are in
 Inspected Assumptions of Use
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-And also the following AoUs in "valid" state and with "inspected" tag set (for these please answer the questions above as if the AoUs are requirements, except question REQ_03_01):
+And also the following AoUs in "valid_inspected" state (for these please answer the questions above as if the AoUs are requirements, except question REQ_03_01):
 
 .. needtable::
-   :filter: "feature_name" in docname and "requirements" in docname and docname is not None and status == "valid"
+   :filter: "feature_name" in docname and "requirements" in docname and docname is not None
    :style: table
    :types: aou_req
    :tags: feature_name

process/folder_templates/platform/requirements/stakeholder/chklst_req_inspection.rst

@@ -16,7 +16,7 @@
 .. document:: Stakeholder Requirements Inspection Checklist
    :id: doc__stakeholder_req_inspection
    :status: draft
-   :version: 1
+   :version: 2
    :safety: ASIL_B
    :security: YES
    :realizes: wp__requirements_inspect[version==1]
@@ -149,20 +149,20 @@ See also :need:`doc_concept__wp_inspections` for further information about revie
 
 Note: If a Review ID is not applicable for your requirement, then state ""n/a" in status and comment accordingly in remarks.
 
-The following requirements in "valid" state and with "inspected" tag set are in the scope of this inspection:
+The following requirements in "valid_inspected" state are in the scope of this inspection:
 
 .. needtable::
-   :filter: "stakeholder" in docname and "requirements" in docname and docname is not None and status == "valid"
+   :filter: "stakeholder" in docname and "requirements" in docname and docname is not None
    :style: table
    :types: stkh_req
    :columns: id;status;tags
    :colwidths: 25,25,25
    :sort: title
 
-And also the following AoUs in "valid" state and with "inspected" tag set (for these please answer the questions above as if the AoUs are requirements, except question REQ_03_01):
+And also the following AoUs in "valid_inspected" state (for these please answer the questions above as if the AoUs are requirements, except question REQ_03_01):
 
 .. needtable::
-   :filter: "platform" in docname and "assumptions" in docname and docname is not None and status == "valid"
+   :filter: "platform" in docname and "assumptions" in docname and docname is not None
    :style: table
    :types: aou_req
    :columns: id;status;tags

process/general_concepts/score_review_concept.rst

@@ -98,7 +98,7 @@ The next activity is the formal inspection, which follows the following workflow
 1. Inspection initiation
 
 The inspection is initiated by the safety manager, security manager or quality manager who will be the moderator for the inspection.
-He sets the work product's status to "valid(inspected)" and starts a Pull-Request (PR).
+He sets the work product's status to "valid_inspected" and starts a Pull-Request (PR).
 This marks the scope of the inspection but also the work product's version.
 For documentation of the review either the PR comments are used (based on latest inspection templates),
 or the safety manager creates/updates an inspection documentation file based on the latest respective templates in the same PR
@@ -147,7 +147,7 @@ The lifecycle for other work product should be similar.
 #. During development and verification steps the requirement is reworked and again put to PR Review
 #. Implementation and verification work products are linked
 #. Safety manager initiates a (formal) Pull-Request Inspection
-#. After finding resolution, the requirement is merged in valid(inspected) state
+#. After finding resolution, the requirement is merged in valid_inspected state
 #. In case of changes the requirement returns in the valid state
 
 Note: This workflow can be shortcut in case an already mature work product (in this case requirement)
@@ -178,7 +178,7 @@ to be able to later explain what they considered during review
 (for example in case a requirement is found to be wrong after the release, to be able to do a lessons learned).
 
 Any work product which is subject to inspection and is modified after an inspection
-shall transition from "valid(inspected)" back to "valid" state. This shall be automatically checked.
+shall transition from "valid_inspected" back to "valid" state. This shall be automatically checked.
 
 Process Requirements
 ^^^^^^^^^^^^^^^^^^^^
@@ -234,7 +234,7 @@ Process Requirements
    :complies: std_req__iso26262__support_6433[version==1], std_req__iso26262__software_7414[version==1]
    :satisfies: wf__monitor_verify_requirements[version==1], wf__mr_vy_arch[version==1]
 
-   It shall be checked that only a PR with the inspection checklist filled out can set a status to valid(inspected).
+   It shall be checked that only a PR with the inspection checklist filled out can set a status to valid_inspected.
 
 .. gd_req:: Status Reset Check
    :id: gd_req__general_status_reset_check