update general concpets

process/general_concepts/score_building_blocks_concept.rst

@@ -17,6 +17,10 @@
 Building blocks concept
 -----------------------
 
+.. doc_concept:: Building Block Concept
+   :id: doc_concept__general_building_blocks
+   :status: valid
+   :tags: process_management
 
 Building blocks meta model
 ++++++++++++++++++++++++++
@@ -42,9 +46,9 @@ also implemented by the **Source Code** (grey box, bottom, 3rd column). The Deta
 verified by **Unit Tests** (grey box, middle, 5th column).
 
 Components are defined by **Component Requirements** (green box, middle, 3rd column) and the
-**Component Architecture** (green box, middle, 4th column). A **Component Safety Analysis**
+**Component Architecture** (green box, middle, 4th column). A **Component Safety/Security Analysis**
 (green box, middle, 6th column) is required to verify the Component Architecture, whereby
-violations of safety requirements must be documented. Potential faults
+violations of safety/security requirements must be documented. Potential faults
 may mitigated by updating the Component Requirements or by the **Component Assumptions of Use**
 (green box, middle, 8nd column). The latter one must be considered by the user of the Component.
 **Component Tests** (green box, middle, 5th column) verify the Component requirements, and
@@ -54,8 +58,8 @@ as well as the Integration of multiple Units to a Component.
 As mentioned above a Software Module is defined as a Component or a set of components realizing a
 Feature of the platform. Features consists of Components and are defined by **Feature Requirements**
 (yellow box, middle, 3rd column) and the **Feature Architecture** (yellow box, middle, 4th column).
-A **Feature Safety Analysis** (yellow box, middle, 6th column) is required to verify the Feature
-Architecture, whereby violations of safety requirements must be documented. Potential
+A **Feature Safety/Security Analysis** (yellow box, middle, 6th column) is required to verify the Feature
+Architecture, whereby violations of safety/security requirements must be documented. Potential
 faults may mitigated by updating the Feature Requirements or by the
 **Feature Assumptions of Use** (yellow box, middle, 8nd column). The latter one must be considered
 by the user of the Feature. **Feature Integration Tests** (yellow box, middle, 5th column) verify

process/general_concepts/score_lifecycle_concept.rst

@@ -17,6 +17,11 @@
 Lifecycle concept
 -----------------
 
+.. doc_concept:: Lifecycle Concept
+   :id: doc_concept__general_lifecycle
+   :status: valid
+   :tags: process_management
+
 Contributions to the project are driven by feature/component requests.
 
 As features and components are the main structuring elements of the project, new

process/general_concepts/score_traceability_concept.rst

@@ -17,6 +17,11 @@
 Traceability concept
 --------------------
 
+.. doc_concept:: Traceability Concept
+   :id: doc_concept__general_traceability
+   :status: valid
+   :tags: process_management
+
 Traceability is the key to ensure consistency between work products.
 Furthermore, traceability supports impact analysis, dependency analysis, coverage determination
 for requirements and verification, and tracking of implementation status.
@@ -33,7 +38,7 @@ High level traceability overview
 The following figure shows the traceability between the major project work products on each
 requirements level. Starting from top, the platform level, going down to feature, component
 to the bottom the unit level. The concept is based on the classical V-model approach.
-Note also that this decribes the traceability of functional (and interface) type requirements.
+Note also that this describes the traceability of functional (and interface) type requirements.
 
 Change request are traced to all affected work products.
 
@@ -46,7 +51,7 @@ Change request are traced to all affected work products.
   High level traceability overview for project work products
 
 The next figure sets the focus on the feature level and adds the traceability from the Feature
-Requirements to the Feature Architecture, Feature Safety Analysis and the Feature Assumption
+Requirements to the Feature Architecture, Feature Safety/Security Analysis and the Feature Assumption
 of use. For convenience also the traceability to upper and lower lever requirements is shown.
 
 .. figure:: _assets/score_traceability_model_feat_overview.drawio.svg
@@ -57,7 +62,7 @@ of use. For convenience also the traceability to upper and lower lever requireme
   High level traceability overview for project feature work products
 
 The next figures sets the focus on the component level and adds the traceability from the
-Component Requirements to the Component Architecture, Component Safety Analysis
+Component Requirements to the Component Architecture, Component Safety/Security Analysis
 and the Component Assumption of use. Further the traceability to Component Assumptions of use
 from external Components is included.
 

process/introduction/index.rst

@@ -17,6 +17,11 @@
 Introduction
 ============
 
+.. doc_concept:: Process Meta Model
+   :id: doc_concept__process_meta_model
+   :status: valid
+   :tags: process_management
+
 .. toctree::
    :maxdepth: 2
    :caption: Contents: