Merge pull request eclipse-score#600 from Chidananda-Swamy/check_req_id_length

Improved sentence clarity, readability, and flow across sections

Author: masc2023

process/process_areas/requirements_engineering/guidance/requirements_guideline.rst

@@ -29,7 +29,7 @@ General Hints
 Templates
 ---------
 
-*Need* templates displaying the correct syntax and attribute definition are provided for each requirement type. For VScode code snippets are included in the workspace settings which will provide in-place the definition of requirements including all mandatory attributes:
+*Need* templates displaying the correct syntax and attribute definition are provided for each requirement type. For VScode, code snippets are included in the workspace settings which will provide in-place the definition of requirements including all mandatory attributes:
 
 .. list-table:: Overview
    :header-rows: 1
@@ -72,12 +72,12 @@ For all requirements following mandatory attributes are defined:
    :colwidths: 30
 
 
-* Title and description: For the formulation of requirements following template shall be used :need:`[[title]]<gd_temp__req_formulation>`
+* Title and description: For formulating requirements, the following template shall be used :need:`[[title]]<gd_temp__req_formulation>`
 * ID: The naming convention for the ID is defined for every project in a central place (e.g. in the general contributor's guidelines)
-* Furthermore the requirements need to be versioned. Therefore a hash value of the requirement will to be calculated. The concept is described: :ref:`traceability concept for requirements`
+* Furthermore the requirements need to be versioned. Therefore, a hash value of the requirement will to be calculated. The concept is described: :ref:`traceability concept for requirements`
 * For the remaining attributes only predefined values can be used. A more detailed description can be found here: :ref:`attributes of the requirements`
-* Note that "rationale" is only mandatory for Stakeholder Requirements ...
-* and process requirements do not need security and safety because these can be derived from the standards they comply to (as well type attributes as these would all be "Non-functional")
+* Note that "rationale" is only mandatory for Stakeholder Requirements.
+* Process requirements do not need the security and safety attributes because these can be derived from the standards they comply with. Type attributes are also unnecessary, as these requirements are always non‑functional.
 
 Checks
 ------
@@ -141,15 +141,15 @@ For this the following templates are available:
 
 * :ref:`Requirement Templates <requirement templates>`
 
-Note: The projec's way of contributing new content (how to branch, how to commit, how to merge with the selected version management tool)
+Note: The project's way of contributing new content (how to branch, how to commit, how to merge with the selected version management tool)
 has to be documented in a central place, stick to this guideline also for the requirement contributions.
 
 .. _review_parent_requirement:
 
 Review parent requirement
 -------------------------
 
-As soon as the parent requirements are in a mature state it can be :ref:`reviewed <review_concept>` and merged into the main branch of the main project's repository. However this is not the formal inspection of the requirements, this will follow in an upcoming step.
+As soon as the parent requirements are in a mature state, they can be :ref:`reviewed <review_concept>` and merged into the main branch of the main project's repository. However this is not the formal inspection of the requirements, this will follow in an upcoming step.
 
 Following roles should be included in the review:
 
@@ -162,7 +162,7 @@ Following roles should be included in the review:
 Derive child requirement and establish traceability
 ---------------------------------------------------
 
-In an upcoming step the child requirements shall be derived from the parent requirements. Feature requirements shall be placed in the main project's repository again, while component requirements shall be placed in the module's repository. During this process the derived requirements shall also be linked according to the defined traceability matrix to the parent requirements.
+In an upcoming step, the child requirements shall be derived from the parent requirements. Feature requirements shall be placed in the main project's repository, while component requirements shall be placed in the module's repository. During this process the derived requirements shall also be linked according to the defined traceability matrix to the parent requirements.
 
 For this the following templates are available:
 
@@ -184,7 +184,7 @@ As soon as also the child requirements are in a mature state they can be :ref:`r
 Generate linkage document
 -------------------------
 
-As parent and child requirements are now available the linkage of the requirements can be established. This should be performed as described in :ref:`coverage_of_requirements`
+As parent and child requirements are now available, the linkage of the requirements can be established. This should be performed as described in :ref:`coverage_of_requirements`
 
 
 .. _formal_requirement_review:
@@ -216,7 +216,7 @@ In Safety Elements out of Context (SEooC) the AoUs are part of the safety manual
 In this workflow (as it describes SEooC development) these AoUs are created both project internal and project external
 
 - internal:  For AoU which arise internally (i.e. from project specific architecture), 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).
-- external:  if externally provided SEooCs are integrated into the platform (e.g. a qualified Operating System). For these AoUs the sentence template cannot be taken into account, as these may be imported from an external safety manual. It is also not possible to link those to other platform development artifacts via the attribute "mitigates".
+- external:  If externally provided SEooCs are integrated into the platform (e.g. a qualified Operating System). For these AoUs the sentence template cannot be taken into account, as these may be imported from an external safety manual. It is also not possible to link those to other platform development artifacts via the attribute "mitigates".
 
 AoUs can be of different class and shall be handled by tracing those
 
@@ -249,7 +249,7 @@ Special cases
 Requirements for future (or past) milestones
 --------------------------------------------
 
-A project release is always consistent, i.e. all development artefacts linked to each other do not contradict each other
+A project release is always consistent, i.e. all linked development artifacts must be non-contradictory
 and complete, i.e. all requirements are derived into dependent work products down to the implementation.
 This is also the case for the selection of the scope of a platform by feature flags, as these
 select a part of the platform but this part is complete.