resolves warnings

add SCORE_ for the links to the SCORE Project Management Plan
add is_external == False or docname is not None to filter out needs from score repo
add SCORE_ for references, which can not be solved in process_description

Author: masc2023

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:`doc__verification_plan`)
+Note that for testcases on unit, component and feature level (as defined in :need:`SCORE_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:`doc__contr_guideline`)
+(resp. Change Request, see :need:`SCORE_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".

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:
 
-:ref:`contribute`
+:ref:`SCORE_contribute`
 
 Standards
 ---------

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:`doc__contr_guideline`)
+6. We aim for an iterative collaboration model initiated by change requests (compare :need:`SCORE_doc__contr_guideline`)
 
 
 .. figure:: _assets/score_process_model.drawio.svg

process/process_areas/architecture_design/guidance/architecture_guideline.rst

@@ -33,7 +33,7 @@ Attributes
 For all architectural need elements following mandatory attributes are defined:
 
 .. needtable:: Overview of mandatory attributes
-   :filter: "mandatory" in tags and "attribute" in tags and "architecture_design" in tags and type == "gd_req"
+   :filter: "mandatory" in tags and "attribute" in tags and "architecture_design" in tags and type == "gd_req" and is_external == False
    :style: table
    :columns: title; id
    :colwidths: 30,70
@@ -45,7 +45,7 @@ Checks
 For architectural elements following checks are defined:
 
 .. needtable:: Overview of checks on architectural elements
-   :filter: "check" in tags and "attribute" in tags and "architecture_design" in tags and type == "gd_req"
+   :filter: "check" in tags and "attribute" in tags and "architecture_design" in tags and type == "gd_req" and is_external == False
    :style: table
    :columns: title; id
    :colwidths: 30,70
@@ -106,8 +106,8 @@ Based on this template the feature architecture shall describe the concept of th
 
 For this step following guidances are available:
 
-* :ref:`Branch Naming Conventions <branch_naming>`
-* :ref:`Git Guidelines <git_guidelines>`
+* :ref:`Branch Naming Conventions <SCORE_branch_naming>`
+* :ref:`Git Guidelines <SCORE_git_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:
 
-* :ref:`Branch Naming Conventions <branch_naming>`
-* :ref:`Git Guidelines <git_guidelines>`
+* :ref:`Branch Naming Conventions <SCORE_branch_naming>`
+* :ref:`Git Guidelines <SCORE_git_guidelines>`
 * :need:`[[title]] <gd_temp__arch__comp>`
 
 .. _allocate_component_requirements:

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: :ref:`naming_convention_needs`
+   The naming convention is defined here: :ref:`SCORE_naming_convention_needs`
 
 .. gd_req:: Architecture attribute: security
    :id: gd_req__arch_attr_security
@@ -179,7 +179,7 @@ Checks for Architectural Design
    It shall be checked if all mandatory attributes for each architectural element is provided by the user. For all elements following attributes shall be mandatory:
 
    .. needtable:: Overview mandatory requirement attributes
-      :filter: "mandatory" in tags and "attribute" in tags and "architecture_design" in tags and type == "gd_req"
+      :filter: "mandatory" in tags and "attribute" in tags and "architecture_design" in tags and type == "gd_req" and is_external == False
       :style: table
       :columns: title
       :colwidths: 30

process/process_areas/architecture_design/index.rst

@@ -30,5 +30,5 @@ Architecture Design
    _assets/architecture_modeling_example
 
 
-.. needextend:: "process_areas/architecture_design" in docname
+.. needextend:: docname is not None and "process_areas/architecture_design" in docname
    :+tags: architecture_design

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:`doc__contr_guideline`)
+A Change Request is the **ONLY** way to contribute (compare :need:`SCORE_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.

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 :ref:`Platform Management Plan <pmp>`, here especially with :need:`Change Management Plan <doc__platform_change_management_plan>`
+* 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>`

process/process_areas/change_management/change_management_workproducts.rst

@@ -62,5 +62,5 @@ Work Products Change Management
    | which changes the scope of the component.
    | Software Modules are also Components (top-level component).
 
-.. needextend:: "docs/process/change_management" in docname
+.. needextend:: docname is not None and "process_areas/change_management" in docname
    :+tags: change_management

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]]<doc__platform_change_management_plan>`.
+The detailed implementation of the Change Management for **S-CORE** is described in the :need:`[[title]]<SCORE_doc__platform_change_management_plan>`.
 
 Templates
 ---------
@@ -55,7 +55,7 @@ For all Change Requests following mandatory attributes need to be defined:
 
 .. needtable:: Overview of mandatory change request attributes
    :tags: change_management
-   :filter: "mandatory" in tags and "attribute" in tags and "chm" in tags
+   :filter: "mandatory" in tags and "attribute" in tags and "chm" in tags and is_external == False
    :style: table
    :columns: title
    :colwidths: 30
@@ -80,7 +80,7 @@ Split may required, if
 
 | 2. Affected work products are in different locations.
 
-Refer to the :need:`Change Management Plan <doc__platform_change_management_plan>` for examples
+Refer to the :need:`Change Management Plan <SCORE_doc__platform_change_management_plan>` for examples
 how to create simple or more complex Change Requests.
 
 .. list-table:: Activities for Change Request