add some basic descriptions of some chapters

docs/features/analysis-infra/logging/docs/glossary.rst

@@ -26,10 +26,10 @@ Glossary
       Framework is a structured and extensible foundation for developing specific types of functionality in this case, logging. It supplies a set of default behaviors and configurable options, allowing developers to tailor and extend its capabilities to meet their application and system need.
 
    platform
-      Platform is the execution environment on which S-Core runs. It includes, for example, hardware (HW), operating system (OS), ...
+      Platform is the execution environment on which S-CORE runs. It includes, for example, hardware (HW), operating system (OS), ...
 
    component
-      Component is a S-Core component
+      Component is a S-CORE component
 
    log level
       Log Level is the severity of a log message, necessary to categorize logs based on their importance e.g., FATAL, ERROR, WARN, INFO, DEBUG, VERBOSE such as in DLT

docs/features/index.rst

@@ -17,6 +17,10 @@
 Features
 ========
 
+A **Feature** is the highest-level logical entity, representing a set of interrelated components in respect of the S-CORE software platform. It is the primary unit of the management of these components and contains the belonging feature requirements and feature architecture for them. For further explanation see the `Building blocks concept <https://eclipse-score.github.io/process_description/main/general_concepts/score_building_blocks_concept.html>`_.
+
+The following features are defined:
+
 .. toctree::
    :maxdepth: 1
    :glob:

docs/features/lifecycle/architecture/launch_manager.rst

@@ -21,7 +21,7 @@ monitoring, and controlling processes based on defined configurations and
 requirements. As such, it is a central part of the lifecycle management in
 S-CORE and knows about the state of all processes in the system.
 
-It's foreseen ECU projects will need a custom state management to fulfill ECU-project specific requirements.  The S-Core stack will offer a framework to control application lifecycle, but will not specify the State Manager.
+It's foreseen ECU projects will need a custom state management to fulfill ECU-project specific requirements.  The S-CORE stack will offer a framework to control application lifecycle, but will not specify the State Manager.
 
 Overview
 ========

docs/modules/index.rst

@@ -17,6 +17,9 @@
 Modules
 =======
 
+A **Module** is a major architectural building block which is defined as a component or a set of components realizing a :ref:`feature <features>` of the platform.
+It is the physically compiled and packaged unit that results from the build process and is made available for delivery. For further explanation see the `Building blocks concept <https://eclipse-score.github.io/process_description/main/general_concepts/score_building_blocks_concept.html>`_.
+
 .. image:: _assets/module_architecture.drawio.svg
    :alt: Module Architecture
 
@@ -25,8 +28,6 @@ Modules
    For now, we store the modules documentation in the modules tree, because multi-repo docs are not yet supported.
    Once this support becomes available it will be moved to the right repo.
 
-
-
 .. toctree::
    :maxdepth: 1
    :glob:

docs/platform_management_plan/project_management.rst

@@ -130,13 +130,13 @@ Its current *DoD list* is always documented in the template. The most important
   Every *Feature Team* should have its own discussion section in the `Feature Teams section <https://github.com/orgs/eclipse-score/discussions>`_
   of the main *S-CORE* project.
 
-* **Adding a new Team to the main S-Core GitHub project**
+* **Adding a new Team to the main S-CORE GitHub project**
 
   Every *Feature Team* should be added as a further select option of the "Team" field
-  in the `main S-Core project <https://github.com/orgs/eclipse-score/projects/17/views/27>`_, so that *Technical Leads*
+  in the `main S-CORE project <https://github.com/orgs/eclipse-score/projects/17/views/27>`_, so that *Technical Leads*
   can assign tickets to the team and filter for the tickets of the new team.
   Additionally, every team is free to create its own GitHub project, but then the team tickets should be still
-  visible in the main S-Core project.
+  visible in the main S-CORE project.
 
 * **Creation of repository**
 

docs/platform_management_plan/software_verification.rst

@@ -126,10 +126,10 @@ There are the following different levels of integration and verification defined
 
 
   **Note:** These three levels translate to the levels of ISO 26262 part 6 clauses 9 to 11. The platform
-  testing will be executed by the integrator. S-Core project only executes tests on reference hardware.
+  testing will be executed by the integrator. S-CORE project only executes tests on reference hardware.
   These tests serve as an optional base for the integrator and will also be part of the
   :need:`wp__verification_platform_ver_report`, but more on an informative character. The full scope
-  of clause 11 is tailored out accordingly for S-Core. Practically, this means S-CORE will implement
+  of clause 11 is tailored out accordingly for S-CORE. Practically, this means S-CORE will implement
   Platform Integration Test of stakeholder requirements for demonstration, but these are not intended to completely
   covering all stakeholder requirements.
 

docs/requirements/index.rst

@@ -17,6 +17,10 @@
 Requirements
 ============
 
+Requirements are the formal descriptions of the requested capabilities or characteristics that the software platform or its components must fulfill. For further information see the `requirement concept <https://eclipse-score.github.io/process_description//main/process_areas/requirements_engineering/requirements_concept.html>`_ in the process description.
+
+The following stakeholder functional and non-functional requirements and platform assumptions describe this for S-CORE.
+
 .. toctree::
 
    stakeholder/index

docs/score_releases/index.rst

@@ -14,6 +14,13 @@
 
 .. _releases:
 
+S-CORE Releases
+===============
+
+A **Release** is a officially distributed, versioned, and deployable collection of Project artifacts intended for distribution beyond the Project Developers. It brings together the initial set of core modules, reference integrations, and supporting infrastructure needed to build. For further information about the platform releases and module releases see `release documentation <https://eclipse-score.github.io/process_description//main/process_areas/release_management/release_workproducts.html>`_ in the process description.
+
+See also the project life cycle within the `Eclipse Development Process <https://www.eclipse.org/projects/handbook/#release>`_.
+
 S-CORE Releases Overview
 ========================