remove links to score

masc2023 · masc2023 · commit 06a17e5d9b7b · 2025-06-02T12:48:31.000+02:00
Set REPLACE_ as reminder to change the context
diff --git a/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_plan.rst b/process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_plan.rst
@@ -122,8 +122,8 @@ Module Workproducts List
           - <WP status (manual)>
 
         * - :need:`wp__module_sw_build_config`
-          - :need:`SCORE_doc__software_development_plan`
-          - :ndf:`copy('status', need_id='SCORE_doc__software_development_plan')`
+          - `REPLACE_doc__software_development_plan`
+          - `copy('status', need_id='REPLACE_doc__software_development_plan')`
           - <Link to issue>
           - <Link to WP>
           - <automated>
diff --git a/process/folder_templates/modules/module_name/docs/verification/module_verification_report.rst b/process/folder_templates/modules/module_name/docs/verification/module_verification_report.rst
@@ -33,7 +33,7 @@ Verification Report
     - Adjust ``safety`` and ``tags`` according to your needs
 
 
-This verification report is based on the :need:`SCORE_doc__verification_plan`.
+This verification report is based on the `REPLACE_doc__verification_plan`.
 It covers all the components of the above stated module.
 
 Verification Report contains:
diff --git a/process/general_concepts/score_review_concept.rst b/process/general_concepts/score_review_concept.rst
@@ -60,7 +60,7 @@ In this project there are inspections on the following work products, which are
         * - :need:`wp__sw_implementation`
           - :need:`gd_chklst__impl_inspection_checklist`
 
-Note that for testcases on unit, component and feature level (as defined in :need:`SCORE_doc__verification_plan`)
+Note that for testcases on unit, component and feature level (as defined in `REPLACE_doc__verification_plan`)
 also a review checklist is provided for guidance, but no formal inspection is required. The same is true for Safety Analysis and DFA.
 The independence of testing respectively of test case review is covered by the use of GitHub also for the review of test cases.
 Which means that at least the test case definition or the test case review is performed by
@@ -83,7 +83,7 @@ based on the CODEOWNER(s) definition of the modified files. In case the fixing o
 between reviewer(s) and author, the safety manager or quality manager can be added to the review to moderate a solution.
 
 The initial step for requirements and architecture is the (informal) GitHub review on every Pull-Request
-(resp. Change Request, see :need:`SCORE_doc__contr_guideline`)
+(resp. Change Request, see `REPLACE_doc__contr_guideline`)
 which creates or modifies one of these work products (subject to inspection).
 After this review the work products are in status "valid", which means they can be used for further development and verification steps.
 In this review the checklist entries shall be considered which are tagged as "incremental".
diff --git a/process/index.rst b/process/index.rst
@@ -90,7 +90,7 @@ How To Contribute
 
 How to contribute to the S-CORE project (e.g. naming convention, folder structure, IDE setup) can be found here:
 
-:need:`SCORE_doc__contr_guideline`
+`REPLACE_doc__contr_guideline`
 
 Standards
 ---------
diff --git a/process/introduction/index.rst b/process/introduction/index.rst
@@ -42,7 +42,7 @@ Approach
 3. We aim to develop the process in conformance to the targeted standards (compare figure below).
 4. We aim to establish traceability from the begin (compare figure below, :ref:`wp_traceability_model`).
 5. We aim to verify conformity and traceability by tool automation as much as possible (compare figure below).
-6. We aim for an iterative collaboration model initiated by change requests (compare :need:`SCORE_doc__contr_guideline`)
+6. We aim for an iterative collaboration model initiated by change requests (compare `REPLACE_doc__contr_guideline`)
 
 
 .. figure:: _assets/score_process_model.drawio.svg
diff --git a/process/process_areas/architecture_design/guidance/architecture_guideline.rst b/process/process_areas/architecture_design/guidance/architecture_guideline.rst
@@ -106,8 +106,8 @@ Based on this template the feature architecture shall describe the concept of th
 
 For this step following guidances are available:
 
-* :need:`Branch Naming Conventions <SCORE_doc__naming_conventions>`
-* :need:`Git Guidelines <SCORE_doc__git_coding_guidelines>`
+* `Branch Naming Conventions <REPLACE_doc__naming_conventions>`
+* `Git Guidelines <REPLACE_doc__git_coding_guidelines>`
 * :need:`[[title]] Feature Architecture <gd_temp__arch__feature>`
 
 .. _model_feature_architecture:
@@ -178,8 +178,8 @@ Based on the *feature architecture* the concept for the *component architecture*
 
 For this step following guidances are available:
 
-* :need:`Branch Naming Conventions <SCORE_doc__naming_conventions>`
-* :need:`Git Guidelines <SCORE_doc__git_coding_guidelines>`
+* `Branch Naming Conventions <REPLACE_doc__naming_conventions>`
+* `Git Guidelines <REPLACE_doc__git_coding_guidelines>`
 * :need:`[[title]] <gd_temp__arch__comp>`
 
 .. _allocate_component_requirements:
diff --git a/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst b/process/process_areas/architecture_design/guidance/architecture_process_reqs.rst
@@ -105,7 +105,7 @@ Attributes of Architectural Elements
       * last part of the feature tree
       * keyword describing the content of the requirement.
 
-   The naming convention is defined here: :need:`SCORE_doc__naming_conventions`
+   The naming convention is defined here: `REPLACE_doc__naming_conventions`
 
 .. gd_req:: Architecture attribute: security
    :id: gd_req__arch_attr_security
diff --git a/process/process_areas/change_management/change_management_concept.rst b/process/process_areas/change_management/change_management_concept.rst
@@ -26,7 +26,7 @@ including the requirements of the different stakeholders for the Change Manageme
 
 Key concept
 ***********
-A Change Request is the **ONLY** way to contribute (compare :need:`SCORE_doc__contr_guideline`)
+A Change Request is the **ONLY** way to contribute (compare `REPLACE_doc__contr_guideline`)
 new features or to modify the scope of existing features in the **S-CORE** project.
 As features are built-up by Components a Change Request is also needed to add new Components or
 to modify the scope of existing Components.
diff --git a/process/process_areas/change_management/change_management_getstrt.rst b/process/process_areas/change_management/change_management_getstrt.rst
@@ -25,4 +25,4 @@ In case you want to contribute a change to **S-CORE** consider to:
 * Contact the :need:`Technical Lead <rl__technical_lead>` for your contribution to establish planning and reporting
 * Create your change requests according to :need:`wf__change__cr_an_change_request`
 * Make familiar with the development and supporting process descriptions in :ref:`process_description`
-* Make familiar with the relevant sections of the :need:`Platform Management Plan <SCORE_doc__platform_mgt_plan>`, here especially with :need:`Change Management Plan <SCORE_doc__platform_change_management_plan>`
+* Make familiar with the relevant sections of the `Platform Management Plan <REPLACE_doc__platform_mgt_plan>`, here especially with `Change Management Plan <REPLACE_doc__platform_change_management_plan>`
diff --git a/process/process_areas/change_management/guidance/change_management_guideline.rst b/process/process_areas/change_management/guidance/change_management_guideline.rst
@@ -25,7 +25,7 @@ This document describes the general guidances for Change Management based on the
 General Hints
 =============
 
-The detailed implementation of the Change Management for **S-CORE** is described in the :need:`[[title]]<SCORE_doc__platform_change_management_plan>`.
+The detailed implementation of the Change Management for **S-CORE** is described in the `[[title]]<REPLACE_doc__platform_change_management_plan>`.
 
 Templates
 ---------
@@ -80,7 +80,7 @@ Split may required, if
 
 | 2. Affected work products are in different locations.
 
-Refer to the :need:`Change Management Plan <SCORE_doc__platform_change_management_plan>` for examples
+Refer to the `Change Management Plan <REPLACE_doc__platform_change_management_plan>` for examples
 how to create simple or more complex Change Requests.
 
 .. list-table:: Activities for Change Request
diff --git a/process/process_areas/configuration_management/index.rst b/process/process_areas/configuration_management/index.rst
@@ -56,7 +56,7 @@ needed for the building of the documentation and verification reports (e.g. tool
 Work Products
 ^^^^^^^^^^^^^
 
-:need:`SCORE_doc__config_mgt_plan` is a document and part of the work product :need:`wp__platform_mgmt`.
+`REPLACE_doc__config_mgt_plan` is a document and part of the work product :need:`wp__platform_mgmt`.
 
 
 Configuration Management Tooling
@@ -78,11 +78,11 @@ Getting started
 In case you are appointed as a :need:`Technical Lead <rl__technical_lead>` by the :need:`rl__project_lead` in the S-CORE project:
 
 * On platform level, process community already provided a draft configuration management plan,
-  see :need:`SCORE_doc__config_mgt_plan`, just set it to "valid"
+  see `REPLACE_doc__config_mgt_plan`, just set it to "valid"
 * On module level, create a configuration management plan using the platform one as a template.
   If no configuration management plan on module level is created, the platform one is adopted.
 
-As a normal contributor or committer consult the :need:`SCORE_doc__config_mgt_plan`, but this should not
+As a normal contributor or committer consult the `REPLACE_doc__config_mgt_plan`, but this should not
 differ from normal usage of github as a configuration management tool.
 
 Workflows
@@ -98,7 +98,7 @@ Guidance
 --------
 
 The configuration management guideline is contained within the configuration management plan,
-to have all relevant information in one space, see :need:`SCORE_gd_guidl__configuration`
+to have all relevant information in one space, see `REPLACE_gd_guidl__configuration`
 
 Some process requirements to be automated are available:
 
diff --git a/process/process_areas/documentation_management/documentation_getstrt.rst b/process/process_areas/documentation_management/documentation_getstrt.rst
@@ -22,6 +22,6 @@ Getting Started
 In case you are appointed as a :need:`Technical Lead <rl__technical_lead>` by the :need:`rl__project_lead` in the S-CORE project:
 
 * On platform level, process community already provided a draft documentation management plan,
-  see :need:`SCORE_doc__documentation_mgt_plan`, just set it to "valid"
+  see `REPLACE_doc__documentation_mgt_plan`, just set it to "valid"
 * On module level, create a documentation management plan using the platform one as a template
 * On both levels: make sure only the documents in your scope appear in the documents list within the plan
diff --git a/process/process_areas/documentation_management/guidance/documentation_guideline.rst b/process/process_areas/documentation_management/guidance/documentation_guideline.rst
@@ -22,7 +22,7 @@ Guideline
 
 The planning for the documents is part of the Platform Management Plan.
 
-The formal elements for documentations in S-CORE are described here: :need:`SCORE_doc__documentation_mgt_plan`.
+The formal elements for documentations in S-CORE are described here: `REPLACE_doc__documentation_mgt_plan`.
 
 For manual review of the formal elements the
 :need:`Documentation Review Checklist <gd_chklst__documentation__review>` may used.
diff --git a/process/process_areas/implementation/guidance/implementation_guideline.rst b/process/process_areas/implementation/guidance/implementation_guideline.rst
@@ -28,12 +28,12 @@ Workflow for Implementation
 Detailed description which steps are need for implementation.
 
 #. Consult which programming languages, design/coding guidelines and tools are used for Software
-   development within the Software Development Plan :need:`SCORE_doc__software_development_plan`.
+   development within the Software Development Plan `REPLACE_doc__software_development_plan`.
 #. Create a Detailed Design by using the template :need:`gd_temp__detailed_design`.
    In this step, the components are broken down into smaller, independent units that can be tested
    separately during the unit testing phase. The detailed design shall be so exact, that test and
    implementation can be run simultaneously.
-#. Implement the source code, by using the coding guidelines :need:`SCORE_doc__cpp_coding_guidelines` for C++,
+#. Implement the source code, by using the coding guidelines `REPLACE_doc__cpp_coding_guidelines` for C++,
    or <TBD> for Rust.
 #. Create a pull request for your change.
 #. Detail Design and Code Inspection is done to review the code of the software and detect errors in it.
diff --git a/process/process_areas/platform_management/guidance/platform_management_guideline.rst b/process/process_areas/platform_management/guidance/platform_management_guideline.rst
@@ -25,7 +25,7 @@ This document describes the general guidances for Platform Management based on t
 General Hints
 =============
 
-The detailed implementation of the Platform Management Plan for **S-CORE** is described in the :need:`[[title]]<SCORE_doc__platform_mgt_plan>`.
+The detailed implementation of the Platform Management Plan for **S-CORE** is described in the `[[title]]<REPLACE_doc__platform_mgt_plan>`.
 
 An iterative and incremental development model shall be used.
 
diff --git a/process/process_areas/platform_management/platform_management_getstrt.rst b/process/process_areas/platform_management/platform_management_getstrt.rst
@@ -24,4 +24,4 @@ In case you want to manage contributions to **S-CORE** consider to:
 
 * Contact the :need:`Technical Lead <rl__technical_lead>` for your contribution to establish planning and reporting
 * Make familiar with the management, development and supporting process descriptions in :ref:`process_description`
-* Make familiar with the relevant sections of the :need:`Platform Management Plan <SCORE_doc__platform_mgt_plan>`, especially :need:`SCORE_doc__project_mgt_plan`
+* Make familiar with the relevant sections of the `Platform Management Plan <REPLACE_doc__platform_mgt_plan>`, especially `REPLACE_doc__project_mgt_plan`
diff --git a/process/process_areas/problem_resolution/guidance/problem_resolution_guideline.rst b/process/process_areas/problem_resolution/guidance/problem_resolution_guideline.rst
@@ -25,7 +25,7 @@ This document describes the general guidances for Problem Resolution based on th
 General Hints
 =============
 
-The detailed implementation of the Problem Resolution for **S-CORE** is described in the :need:`[[title]]<SCORE_doc__platform_problem_resolution_plan>`.
+The detailed implementation of the Problem Resolution for **S-CORE** is described in the `[[title]]<REPLACE_doc__platform_problem_resolution_plan>`.
 
 Templates
 ---------
@@ -54,7 +54,7 @@ Activities for Problem Resolution
 
 This section describes in detail which steps need to be performed for a Problem resolution.
 
-Refer to the :need:`Problem Resolution Plan <SCORE_doc__platform_problem_resolution_plan>` for examples
+Refer to the `Problem Resolution Plan <REPLACE_doc__platform_problem_resolution_plan>` for examples
 how to create problem reports.
 
 .. list-table:: Activities for Problem Resolution
diff --git a/process/process_areas/problem_resolution/guidance/problem_resolution_template.rst b/process/process_areas/problem_resolution/guidance/problem_resolution_template.rst
@@ -31,7 +31,7 @@ Problem status
 [“open”, “in review”, “in implementation”, “closed”, “rejected”]
 
 If possible, use for problem status the properties of the selected Issue Tracking System
-(for implementation see here :need:`SCORE_doc__platform_problem_resolution_plan`)
+(for implementation see here `REPLACE_doc__platform_problem_resolution_plan`)
 
 | (to be filled out during :need:`wf__problem__create_pr`)
 | (to be updated during :need:`wf__problem__analyse_pr`)
@@ -42,7 +42,7 @@ Problem submitter
 [Who is the reporter of the problem?]
 
 If possible, use for problem submitter the properties of the selected Issue Tracking System
-(for implementation see here :need:`SCORE_doc__platform_problem_resolution_plan`)
+(for implementation see here `REPLACE_doc__platform_problem_resolution_plan`)
 
 (to be filled out during :need:`wf__problem__create_pr`)
 
@@ -83,7 +83,7 @@ Problem stakeholder
 Add affected feature, if possible
 
 If possible, use for problem stakeholder the properties of the selected Issue Tracking System
-(see implementation here :need:`SCORE_doc__platform_problem_resolution_plan`)
+(see implementation here `REPLACE_doc__platform_problem_resolution_plan`)
 
 (to be filled out during :need:`wf__problem__create_pr`)
 
@@ -106,7 +106,7 @@ Bug:
 Safety, Security, Quality: Additional qualifier to highlight, if safety, security or quality is affected
 
 If possible, use for problem category the properties of the selected Issue Tracking System
-(for implementation see here :need:`SCORE_doc__platform_problem_resolution_plan`)
+(for implementation see here `REPLACE_doc__platform_problem_resolution_plan`)
 
 (to be filled out during :need:`wf__problem__create_pr`)
 
@@ -145,7 +145,7 @@ Problem expected closure date
 [Milestone when the problem should be resolved]
 
 If possible, use for problem closure date the properties of the selected Issue Tracking System
-(for implementation see here :need:`SCORE_doc__platform_problem_resolution_plan`)
+(for implementation see here `REPLACE_doc__platform_problem_resolution_plan`)
 
 (to be filled out during :need:`wf__problem__create_pr`)
 
diff --git a/process/process_areas/problem_resolution/problem_resolution_concept.rst b/process/process_areas/problem_resolution/problem_resolution_concept.rst
@@ -26,7 +26,7 @@ including the requirements of the different stakeholders for the Problem Resolut
 
 Key concept
 ***********
-A Problem Report is the **ONLY** way to report (compare :need:`SCORE_doc__contr_guideline`)
+A Problem Report is the **ONLY** way to report (compare `REPLACE_doc__contr_guideline`)
 deviations of an expected result for existing features in the **S-CORE** project.
 Deviations include problems found by user, bugs found during verification activites by tester,
 quality issues found by quality checks, safety anomalies, vulnerabilites or any other malfunction.
diff --git a/process/process_areas/problem_resolution/problem_resolution_getstrt.rst b/process/process_areas/problem_resolution/problem_resolution_getstrt.rst
@@ -24,5 +24,5 @@ In case you want to report a Problem to **S-CORE** consider to:
 
 * Create your Problem Report according to :need:`wf__problem__create_pr`
 * Make familiar with the development and supporting process descriptions in :ref:`process_description`
-* Make familiar with the relevant sections of the :need:`Platform Management Plan <SCORE_doc__platform_mgt_plan>`, here especially with :need:`Problem Resolution Plan <SCORE_doc__platform_problem_resolution_plan>`
+* Make familiar with the relevant sections of the `Platform Management Plan <REPLACE_doc__platform_mgt_plan>`, here especially with `Problem Resolution Plan <REPLACE_doc__platform_problem_resolution_plan>`
 * In case of any questions, contact the :need:`Technical Lead <rl__technical_lead>` for your problem to establish reporting and planning
diff --git a/process/process_areas/release_management/guidance/release_guideline.rst b/process/process_areas/release_management/guidance/release_guideline.rst
@@ -44,7 +44,7 @@ Software Module Release
 
 4. **Release Preparation**:
 
-   * Update the version number according to the versioning policy (defined in :need:`SCORE_doc__platform_release_management_plan`).
+   * Update the version number according to the versioning policy (defined in `REPLACE_doc__platform_release_management_plan`).
    * Prepare release notes documenting the changes, improvements, and bug fixes.
    * Ensure the relevant safety packages are available and complete.
    * Tag the release in the GitHub repository.
@@ -79,7 +79,7 @@ Platform Release
 4. **Release Preparation**:
 
    * Check if modules are released.
-   * Update the platform version number according to the versioning policy (defined in :need:`SCORE_doc__platform_release_management_plan`).
+   * Update the platform version number according to the versioning policy (defined in `REPLACE_doc__platform_release_management_plan`).
    * Prepare platform release notes summarizing the updates from all integrated software modules.
    * Ensure the relevant safety packages are available and complete.
    * Tag the platform release in the GitHub repository.
@@ -103,7 +103,7 @@ Tracking and Communication
 
    * Regularly update all stakeholders on the release status as part of the project lead circle.
    * Hold periodic meetings to discuss progress, issues, and dependencies within the tech lead circle.
-   * meeting definition and schedule see :need:`Steering committees <SCORE_doc__project_mgt_plan>`.
+   * meeting definition and schedule see `Steering committees <REPLACE_doc__project_mgt_plan>`.
 
 
 Templates
diff --git a/process/process_areas/requirements_engineering/guidance/requirements_guideline.rst b/process/process_areas/requirements_engineering/guidance/requirements_guideline.rst
@@ -69,7 +69,7 @@ For all requirements following mandatory attributes need to be 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 :need:`here <SCORE_doc__naming_conventions>`.
+* ID: The naming convention for the ID is defined `here <REPLACE_doc__naming_conventions>`.
 * 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`
 
@@ -133,8 +133,8 @@ In this step the parent requirements shall be created. Stakeholder- and feature
 
 Therefore following guidelines are available:
 
-* :need:`Branch Naming Conventions <SCORE_doc__naming_conventions>`
-* :need:`Git Guidelines <SCORE_doc__git_coding_guidelines>`
+* `Branch Naming Conventions <REPLACE_doc__naming_conventions>`
+* `Git Guidelines <REPLACE_doc__git_coding_guidelines>`
 * :ref:`Requirement Templates <requirement templates>`
 
 .. _review_parent_requirement:
@@ -159,8 +159,8 @@ In an upcoming step the child requirements shall be derived from the parent requ
 
 Following guidelines are available:
 
-* :need:`Branch Naming Conventions <SCORE_doc__naming_conventions>`
-* :need:`Git Guidelines <SCORE_doc__git_coding_guidelines>`
+* `Branch Naming Conventions <REPLACE_doc__naming_conventions>`
+* `Git Guidelines <REPLACE_doc__git_coding_guidelines>`
 * :ref:`Requirement Templates <requirement templates>`
 
 .. _review_child_requirement:
diff --git a/process/process_areas/requirements_engineering/guidance/requirements_process_reqs.rst b/process/process_areas/requirements_engineering/guidance/requirements_process_reqs.rst
@@ -52,7 +52,7 @@ Process Requirement Attributes
       * last part of the feature tree
       * keyword describing the content of the requirement.
 
-   The naming convention is defined here: :need:`SCORE_doc__naming_conventions`
+   The naming convention is defined here: `REPLACE_doc__naming_conventions`
 
 .. gd_req:: Requirement attribute: title
    :id: gd_req__requirements_attr_title
diff --git a/process/process_areas/requirements_engineering/requirements_getstrt.rst b/process/process_areas/requirements_engineering/requirements_getstrt.rst
diff --git a/process/process_areas/safety_management/guidance/guideline_safety_management.rst b/process/process_areas/safety_management/guidance/guideline_safety_management.rst
diff --git a/process/process_areas/safety_management/index.rst b/process/process_areas/safety_management/index.rst
diff --git a/process/process_areas/tool_management/tool_management_getstrt.rst b/process/process_areas/tool_management/tool_management_getstrt.rst
diff --git a/process/process_areas/verification/guidance/verification_guideline.rst b/process/process_areas/verification/guidance/verification_guideline.rst
diff --git a/process/process_areas/verification/guidance/verification_methods.rst b/process/process_areas/verification/guidance/verification_methods.rst
diff --git a/process/process_areas/verification/guidance/verification_plan_template.rst b/process/process_areas/verification/guidance/verification_plan_template.rst
diff --git a/process/process_areas/verification/guidance/verification_report_template.rst b/process/process_areas/verification/guidance/verification_report_template.rst
