removed some adr, slight formatting changes

docs/content/architecture/01_introduction/02_quality_goals.md

@@ -4,4 +4,14 @@ draft: true
 cascade:
   type: docs
 ---
-DRAFT
+The following table describes the key quality objectives of DAS.
+
+| Quality Goal                                                            | Motivation/description  |
+|:------------------------------------------------------------------------|:------------------------|
+| Railway operations depend on it (Reliability)                           |                         |
+| Provided information is correct (Functional Suitability)                |                         |
+| Reliable and efficient operation (Operability)                          |                         |
+| Changes need to be implemented efficiently and safely (Maintainability) |                         |
+| Support, not distract the engine driver (Usability)                     |                         |
+
+The [Quality Requirements in section 10](../../10_quality_requirements/) detail these goals and serve to evaluate their achievement.

docs/content/architecture/04_solution_strategy/01_introduction.md

@@ -4,4 +4,43 @@ draft: true
 cascade:
   type: docs
 ---
-DRAFT
+The following list contrasts the [quality goals](../../01_introduction/02_quality_goals/) of DAS with matching architecture approaches and thus provides easy access to the solution.
+
+**Railway operations depend on it (Reliability)**
+* decoupling
+* caching the data
+* reduce number of involved systems
+
+**Provided information is correct (Functional Suitability)**
+* comprehensive testing
+* read-only View-Model / immutable objects 
+* using Mappers
+
+**Reliable and efficient operation (Operability)**
+* logging and monitoring
+* crash recorder on mobile
+* no unnecessary dependencies
+
+**Changes need to be implemented efficiently and safely (Maintainability)**
+* no unnecessary dependencies, quality check
+* cohesive and well-structured internal data model
+* APIM -> 
+* modularization
+* Interfaces for core abstractions -> 
+* using standards
+* lint enforced
+* check architecture with tools (ArchUnit)
+
+**Support, not distract the engine driver (Usability)**
+* intense collaboration between UX- and dev-team
+
+Further goals which are important for DAS:
+
+**Auditability**
+* logging
+* open source
+* comprehensive documentation
+
+**Safety**
+* follow (SBB internal) processes to assess risks
+* comprehensive testing 

docs/content/architecture/09_design_decisions/authentication_adr.md

@@ -21,9 +21,9 @@ DAS is operated for various RUs and must therefore have an exchangeable or broad
 
 ## Influences on the Decision
 * Azure is the standard technology for IAM at SBB.
-*In order to authenticate other companies/EVUs, a federation of Azure ADs must be created.
+* In order to authenticate other companies/EVUs, a federation of Azure ADs must be created.
 * With Multitenant, the partner RUs must manage the identities and can therefore be delegated.
-*With Crosstenant, all identities would have to be managed by SBB. However, SBB does not know the identities and cannot know which identities should have which access.
+* With Crosstenant, all identities would have to be managed by SBB. However, SBB does not know the identities and cannot know which identities should have which access.
 * If there is no identity federation, each RU would have to operate a DAS itself, which is not currently planned.
 * Exchange with the Beacon Management project has taken place. Azure Multitenant is already used there with many TUs and there is multi-client capability and delegated role management.
 
@@ -32,7 +32,6 @@ DAS is operated for various RUs and must therefore have an exchangeable or broad
 
 
 ## Considered Alternatives
-* Multitenant
 * Crosstenant
 
 ## Decisions