Process: Remove S-CORE links and tools from Req Mgt

process/process_areas/requirements_engineering/guidance/requirements_guideline.rst

@@ -20,7 +20,7 @@ Guideline
    :status: valid
    :complies: std_req__isopas8926__44421, std_req__isopas8926__44422, std_req__isopas8926__44423
 
-This document describes the general guidances for requirements based on the concept which is defined :need:`[[title]]<doc_concept__req_process>`.
+This document describes the general guidances for requirements based on the concept which is defined in :need:`[[title]]<doc_concept__req_process>`.
 
 General Hints
 =============
@@ -72,7 +72,7 @@ For all requirements following mandatory attributes are defined:
 
 
 * Title and description: For the formulation of requirements following template shall be used :need:`[[title]]<gd_temp__req_formulation>`
-* ID: The naming convention for the ID is defined `here <REPLACE_doc__naming_conventions>`.
+* 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`
 * 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 ...
@@ -81,11 +81,11 @@ For all requirements following mandatory attributes are defined:
 Checks
 ------
 
-During the sphinx build checks will be performed on the requirements. Those are specified via following process requirements:
+During the docs build checks will be performed on the requirements. Those are specified via following process requirements:
 
 .. needtable:: Overview checks for requirement
    :tags: requirements_engineering
-   :filter: "check" in tags and "attribute" in tags and type == "gd_req" and is_external == False
+   :filter: "check" in tags and type == "gd_req" and is_external == False
    :style: table
    :columns: title;id
    :colwidths: 60,40
@@ -110,7 +110,7 @@ This section describes in detail which steps need to be performed to create a re
    * - :ref:`2. <review_parent_requirement>`
      - Review parent requirement
      - :need:`[[title]] <rl__committer>`
-   * - 3.
+   * - :ref:`3. <review_parent_requirement>`
      - Merge valid parent requirement to main branch
      - :need:`[[title]] <rl__committer>`
    * - :ref:`4. <derive_child_requirement>`
@@ -119,7 +119,7 @@ This section describes in detail which steps need to be performed to create a re
    * - :ref:`5. <review_child_requirement>`
      - Review child requirement
      - :need:`[[title]] <rl__committer>`
-   * - 6.
+   * - :ref:`6. <review_child_requirement>`
      - Merge valid child requirement to main branch
      - :need:`[[title]] <rl__committer>`
    * - :ref:`7. <generate_linkage_document>`
@@ -134,20 +134,21 @@ This section describes in detail which steps need to be performed to create a re
 Create parent requirement
 -------------------------
 
-In this step the parent requirements shall be created. Stakeholder- and feature requirements should be generated in the score repository.
+In this step the parent requirements shall be created. Stakeholder- and feature requirements should be generated in the project's main repository.
 
-Therefore following guidelines are available:
+For this the following templates are available:
 
-* `Branch Naming Conventions <REPLACE_doc__naming_conventions>`
-* `Git Guidelines <REPLACE_doc__git_coding_guidelines>`
 * :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)
+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 score 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 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.
 
 Following roles should be included in the review:
 
@@ -160,12 +161,10 @@ 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 score repository again, while component requirements shall be placed in the module 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 again, while component requirements shall be placed in the module repository. During this process the derived requirements shall also be linked according to the defined traceability matrix to the parent requirements.
 
-Following guidelines are available:
+For this the following templates are available:
 
-* `Branch Naming Conventions <REPLACE_doc__naming_conventions>`
-* `Git Guidelines <REPLACE_doc__git_coding_guidelines>`
 * :ref:`Requirement Templates <requirement templates>`
 
 .. _review_child_requirement:
@@ -200,10 +199,11 @@ 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 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.
 In Safety Elements out of Context (SEooC) the AoUs will normally be part of the safety manual.
-In this project (as it develops SEooCs) these AoUs are created both internally and externally - if existing SEooCs are integrated into the platform (e.g. a qualified Operating System).
-For AoU which arise from S-CORE specific modules the template is almost identical to the one for feature/component requirements. The only difference is that it defined such that the attribute "satisfies" is replaced with the attribute "mitigates" (see picture below).
+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).
 For externally provided AoUs of course the sentence template cannot be taken into account, as these are only imported from an external safety manual. It is also not possible to link it to other development artifacts via the attribute "mitigates".
 
 AoUs can be of different class and shall be handled by tracing those

process/process_areas/requirements_engineering/guidance/requirements_inspection_checklist.rst

@@ -25,7 +25,7 @@ Requirement Inspection Checklist
 
    **Purpose**
    The purpose of this requirement inspection template is to collect the topics to be checked during requirements inspection.
-   It will be filled out within the github "inspection" pull request review of every requirement type.
+   It will be filled out within the "inspection" pull request review of every requirement type.
 
    **Checklist**
 

process/process_areas/requirements_engineering/guidance/requirements_process_reqs.rst

@@ -204,7 +204,7 @@ Process Requirement Linkage
    :tags: prio_2_automation, attribute
    :satisfies: wf__req_feat_req, wf__req_comp_req
 
-   It shall be possible to link requirements to code and include a link to github to the respective line of code in an attribute of the requirement.
+   It shall be possible to link requirements to code (to the respective line of code in an attribute of the requirement).
 
 .. gd_req:: Requirement attribute: link to test
    :id: gd_req__req_attr_testlink

process/process_areas/requirements_engineering/requirements_concept.rst

@@ -194,22 +194,22 @@ Following attributes are automatically generated:
      - Tool
    * - Satisfied by
      - This attribute is automatically generated into the parent requirement based on the attribute satisfies of the current requirement
-     - Sphinx Needs Build
+     - Docs-as-Code
    * - Hash
      - This attribute contains a hash value which is calculated over all mandatory requirement attributes. However this script needs to be executed manually, as this information is required to be present in the rst file.
-     - Script / Bazel Target
+     - Script
    * - Satisfies Hash
      - It contains the hash of the parent requirement. If the parent requirement is changed the hash will also change and the linkage has to be revisited again. A more detailed description is provided here: :need:`gd_req__req_attr_version`
-     - Script / Bazel Target
+     - Script
    * - Implemented by
      - During Build the code files are parsed for a defined tag which includes the requirement id. If this is located a link to the code will be added in the requirement
-     - Sphinx Needs Build
+     - Docs-as-Code
    * - Verified by
      - During build the junit test files are parsed for a defined marker which includes the requirement id. If the marker is located in the test a link to the test case will be added to the requirement
-     - Sphinx Needs Build
+     - Docs-as-Code
    * - Requirement Covered
      - During build it will be checked if the requirements hashes which are mentioned in the coverage file match the hashes of the linked child requirements. If so then this attribute will be set to yes.
-     - Sphinx Needs Build
+     - Docs-as-Code
 
 More details about the generation of the automated attributes are explained in the following chapter where the general workflow for generating requirements including their status is shown.
 
@@ -221,7 +221,7 @@ Requirements Versioning
 Individual Requirements
 =======================
 
-For the requirements the version management is basically provided by the git history. However it needs to be identified if the content of a requirement changed. So this concept aims only at identifying a change in the mandatory attributes of a requirement.
+For the requirements the version management is basically provided by version managemnt tooling (e.g. git history). However it needs to be identified if the content of a requirement changed. So this concept aims only at identifying a change in the mandatory attributes of a requirement.
 
 Calculate hash for current requirements
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -238,14 +238,14 @@ For each requirement a hash shall be calculated and stored in its dedicated own
 
 There shall be a tooling available which can be executed by the user during the creation of the requirements. This tooling shall calculate the hashes based on the mandatory attributes, calculate the hash values and enter the calculated hash values into the rst file for each requirement in the attribute *hash*.
 
-During Sphinx build it shall be checked if the attribute hash matches the actual has value of the requirement.
+During docs build it shall be checked if the attribute hash matches the actual has value of the requirement.
 
 Linking child requirements including hashes
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-If a requirement is linked to a top level requirement also the hash of the target requirement shall be part of the link. It shall automatically be written into the attribute *satisfies hash*. Upon Sphinx Build it shall be checked if the attribute *satisfies hash* matches the calculated hash of the requirement which is linked via *satisfies*.
+If a requirement is linked to a top level requirement also the hash of the target requirement shall be part of the link. It shall automatically be written into the attribute *satisfies hash*. Upon docs build it shall be checked if the attribute *satisfies hash* matches the calculated hash of the requirement which is linked via *satisfies*.
 
-As this check is included in the sphinx build as a warning it can be guaranteed that a change of a parent requirement can only be merged if the `linkhashes` in the requirements are also updated in a `Depends-On` PR.
+As this check is included in the docs build as a warning it can be guaranteed that a change of a parent requirement can only be merged if the `linkhashes` in the requirements are also updated in a `Depends-On` PR.
 
 .. figure:: _assets/requirements_versioning.drawio.svg
    :alt: Requirements Versioning
@@ -254,17 +254,18 @@ As this check is included in the sphinx build as a warning it can be guaranteed
 
    Versioning of Requirements
 
-.. _reviews of the requirements:
 
 Sets of Requirements / Baselines
 ================================
 
-GitHub standard functionality provides the means to version sets of requirements, as those are collected in files.
+Version management tooling standard functionality provides the means to version sets of requirements, as those are collected in files:
 
 * The files commit history can be displayed, to show change date, author and differences
-* via git "Blame" also the changes on every line are available
+* Also the changes on every line are available (e.g. via git "Blame")
+
+Requirement baseline generation is part of the configuration management, it is done by tagging a complete set of artifacts/files in a repository.
 
-Requirement baseline generation is part of the configuration management, it is also done with GitHub means by tagging a complete set of artifacts/files in a repository.
+.. _reviews of the requirements:
 
 Reviews of the Requirements
 ***************************

process/process_areas/requirements_engineering/requirements_getstrt.rst

@@ -22,7 +22,7 @@ Getting Started
 
 This document describes the steps which need to be done to create requirements, derive child requirements and finally to perform the formal requirement inspection.
 
-Therefore both a :need:`[[title]] <gd_guidl__req_engineering>` and a :need:`[[title]] <doc_concept__req_process>` are available.
+For this a :need:`[[title]] <gd_guidl__req_engineering>`, :ref:`requirement templates` and a :need:`[[title]] <doc_concept__req_process>` are available.
 
 The subsequent steps of linking requirements to code and test cases are described in different guidelines:
 
@@ -46,36 +46,6 @@ The details of what needs to be done in each steps are described in the :ref:`wo
 Tooling Support
 ***************
 
-Linking Requirements to Source Code
-===================================
-
-For linking requirements to source code a tool is available:
-
-<TBD Linking Reqs to Source>
-
-Linking Requirements to Tests
-=============================
-
-For linking Requirements to tests metatags shall be used :need:`gd_req__verification_link_tests`
-
-
-Developer Experience
-====================
-
-Additionally tooling is provided to assist the :need:`[[title]] <rl__contributor>` to define the requirements in spinx needs. The current feature set is described as IDE requirements:
-
-.. needtable:: Implemented IDE Requirements
-   :tags: sphinx, ide
-   :style: table
-   :columns: title;id
-   :filter: "ide" in tags and type == "tool_req" and is_external == False
-   :colwidths: 70,30
-
-A *HowTo* which describes the setup of the development environment for Sphinx Needs is available `here <REPLACE_doc__develop_environment>`.
-
-For all RST files also a linter is configured, it will be automatically run in the CI upon check-in.
-Locally it can be run via
-
-.. code-block:: shell
-
-   bazel test //:format.check
+The requirements templates and examples are built by using the means of a specific "Docs-as-Code" tool,
+but this does not mean that projects are required to use this, as long as the content (e.g. attributes)
+and functionality described in :ref:`process_requirements` is covered by the selected tool.

process/process_areas/requirements_engineering/requirements_workflow.rst

@@ -70,4 +70,4 @@ Workflow Requirements Engineering
    :output: wp__issue_track_system, wp__requirements_inspect
    :contains: gd_chklst__req_inspection
 
-   The requirements are monitored and verified. The inspection shall be implemented as integral part of the review in GitHub.
+   The requirements are monitored and verified. The inspection shall be implemented as integral part of the review in version management tool.

process/process_areas/requirements_engineering/requirements_workproducts.rst

@@ -55,10 +55,9 @@ Workproducts Requirements Engineering
    :status: draft
    :complies: std_wp__iso26262__software_653
 
-   | Depends on requirements management tooling, expect text based requirements maintained in git.
-   | - github review with integrated inspection checklist, only valid requirements get merged
-   |
-   | Compare also `Gitub documentationt <https://docs.github.com/en>`_
+   Depends on requirements management tooling, expect text based requirements.
+
+   Review done with inspection checklist. This checklist may be integrated in requirements/version management tooling.
 
 .. needextend:: docname is not None and "process_areas/requirements_engineering" in docname
    :+tags: requirements_engineering