Merge pull request #465 from isaqb-org/464-check-and-fix-minor-transl…

…ation-issues

#464 check and fix minor translation issues

docs/00-preamble/03-prerequisites.adoc

@@ -19,7 +19,7 @@ Teilnehmende sollten die im Nachfolgenden genannten Kenntnisse und/oder Erfahrun
 ** Modellierung und Abstraktion
 ** Algorithmen und Datenstrukturen (etwa Listen, Bäume, HashTable, Dictionary/Map)
 ** UML (Klassen-, Paket-, Komponenten- und Sequenzdiagramme) und deren Bezug zum Quellcode
-** Vorgehen beim Testen von Software (z.B. Unit- und Akzeptanztests)
+ ** Vorgehen beim Testen von Software (z.{nbsp}B. Unit- und Akzeptanztests)
 
 
 Hilfreich für das Verständnis einiger Konzepte sind darüber hinaus:

docs/01-basics/LZ-01-02.adoc

@@ -1,15 +1,15 @@
 
 // tag::DE[]
 [[LZ-01-02]]
-==== LZ 01-02: Nutzen und Ziele von Softwarearchitektur verstehen und erläutern (R1)
+==== LZ 01-02: Ziele und Nutzen von Softwarearchitektur verstehen und erläutern (R1)
 
-Softwarearchitekt:innen können folgenden Nutzen und wesentlichen Ziele von Softwarearchitektur begründen:
+Softwarearchitekt:innen können die folgenden wesentlichen Ziele und Nutzen der Softwarearchitektur begründen:
 
 * Entwurf, Implementierung, Pflege und Betrieb von Systemen zu unterstützen
 * funktionale Anforderungen zu erreichen bzw. deren Erfüllbarkeit sicherzustellen
 * Anforderungen wie Zuverlässigkeit, Wartbarkeit, Änderbarkeit, Sicherheit, Energieeffizienz zu erreichen
 * Verständnis für Strukturen und Konzepte des Systems zu vermitteln, bezogen auf sämtliche relevanten Stakeholder
-* systematisch Komplexität zu reduzieren 
+* Komplexität systematisch zu reduzieren
 * architekturrelevante Richtlinien für Implementierung und Betrieb zu spezifizieren
 
 // end::DE[]

docs/01-basics/LZ-01-03.adoc

@@ -22,7 +22,7 @@ Sie sollen selbstständig die Notwendigkeit von Iterationen bei allen Aufgaben e
 
 // tag::EN[]
 [[LG-01-03]]
-==== LG 01-03 [ehemaliges LG 1-4]: Understand Software Architects' Tasks and Responsibilities (R1)
+==== LG 01-03 [ehemaliges LG 1-4]: Understand the Tasks and Responsibilities of Software Architects (R1)
 Software architects are responsible for meeting requirements and creating the architecture design of a solution.
 Depending on the actual approach or process model used, they must align this responsibility with the overall responsibilities of project management and/or other roles.
 

docs/01-basics/LZ-01-04.adoc

@@ -1,7 +1,7 @@
 
 // tag::DE[]
 [[LZ-01-04]]
-==== LZ 01-04 [ehemaliges LZ 1-09]: Zuständigkeit von Softwarearchitekt:innen in organisatorischen Kontext einordnen (R3)
+==== LZ 01-04 [ehemaliges LZ 1-09]: Verantwortlichkeiten von Softwarearchitekt:innen in organisatorischen Kontext einordnen (R3)
 
 Der Fokus des iSAQB CPSA-Foundation Level liegt auf Strukturen und Konzepten einzelner Softwaresysteme.
 
@@ -21,7 +21,7 @@ Diese Architekturdomänen sind nicht inhaltlicher Fokus vom CPSA-F.
 
 // tag::EN[]
 [[LG-01-04]]
-==== LG 01-04 [previously LG 1-09]: Responsibilities of Software Architects within the Greater Architectural Context (R3)
+==== LG 01-04 [previously LG 1-09]: Classify Responsibilities of Software Architects within the Greater Architectural Context (R3)
 
 The focus of the iSAQB CPSA Foundation Level is on structures and concepts of individual software systems.
 

docs/01-basics/LZ-01-05.adoc

@@ -1,7 +1,7 @@
 
 // tag::DE[]
 [[LZ-01-05]]
-==== LZ 01-05 [ehemaliges LZ 01-05]: Rolle von Softwarearchitekt:innen in Beziehung zu anderen Stakeholdern setzen (R1)
+==== LZ 01-05 [ehemaliges LZ 01-05]: Rolle von Softwarearchitekt:innen mit anderen Stakeholdern in Beziehung setzen (R1)
 Softwarearchitekt:innen können ihre Rolle erklären. 
 Sie sollten ihren Beitrag zur Systementwicklung in Verbindung mit anderen Stakeholdern und Organisationseinheiten kontextspezifisch ausgestalten, insbesondere zu:
 

docs/02-requirements/LZ-02-01.adoc

@@ -1,7 +1,7 @@
 
 // tag::DE[]
 [[LZ-02-01]]
-==== LZ 02-01: Stakeholder-Anliegen
+==== LZ 02-01: Stakeholder-Anliegen verstehen
 
 Architekten können Stakeholder und deren Anliegen sowie deren
 Auswirkungen auf die Softwarearchitektur oder den Entwurfs- und
@@ -13,29 +13,29 @@ Entwicklungsprozess identifizieren. (R2)
 |Interessengruppe |Anliegen der Interessengruppe
 
 | Produktmanagement
-| z. B. benötigte Zeit für die Umsetzung der Anforderungen
+| z.{nbsp}B. benötigte Zeit für die Umsetzung der Anforderungen
 
 | Projektmanager
-| z. B. benötigte Zeit und Budget für die Umsetzung, verbundene Risiken des
+| z.{nbsp}B. benötigte Zeit und Budget für die Umsetzung, verbundene Risiken des
 gewählten architekturellen Ansatzes
 
 | Requirements Ingenieure
-| z. B. Erfüllung der Anforderungen
+| z.{nbsp}B. Erfüllung der Anforderungen
 
 | Entwickler
-| z. B. zu implementierende Komponenten und Schnittstellen, Protokolle,
+| z.{nbsp}B. zu implementierende Komponenten und Schnittstellen, Protokolle,
 technologische Einschränkungen
 
 | Qualitätssicherung und Tester
-| z. B. isoliertes Testen von Komponenten
+| z.{nbsp}B. isoliertes Testen von Komponenten
 
 | Betrieb
-| z. B. Infrastrukturanforderungen im Zusammenhang mit dem Betrieb des Systems
+| z.{nbsp}B. Infrastrukturanforderungen im Zusammenhang mit dem Betrieb des Systems
 
 |===
 
 Softwarearchitekten können potenzielle Konflikte zwischen kurz- und
-langfristigen Zielen erklären, um mögliche Konflikte (z.B., Geschäfts- und
+langfristigen Zielen erklären, um mögliche Konflikte (z.{nbsp}B., Geschäfts- und
 Projektziele vs. Architektur- und Wartbarkeitsziele) zu lösen. (R1)
 
 Architekten verstehen, dass nicht alle Anliegen der Stakeholder in
@@ -44,12 +44,12 @@ werden müssen. (R3)
 
 Architekten können die Anliegen der Stakeholder nutzen, um fehlende oder
 widersprüchliche Anforderungen zu entdecken und/oder Anforderungen und
-Einschränkungen an der Architektur zu validieren, z.B. in Stakeholder-Interviews. (R3)
+Einschränkungen an der Architektur zu validieren, z.{nbsp}B. in Stakeholder-Interviews. (R3)
 // end::DE[]
 
 // tag::EN[]
 [[LG-02-01]]
-==== LG 02-01: Stakeholder Concerns (R1 - R3)
+==== LG 02-01: Unterstand Stakeholder Concerns (R1 - R3)
 
 Architects can identify stakeholders and their concerns, as well as their impact on the
 software architecture or the design and development process. (R2)

docs/02-requirements/LZ-02-02.adoc

@@ -3,10 +3,9 @@
 [[LZ-02-02]]
 ==== LZ 02-02 [ehemaliges LZ 2-3]: Anforderungen und Randbedingungen klären und berücksichtigen können (R1-R3)
 
-TODO: translations must be checked
-
-Softwarearchitekt:innen können Anforderungen (inklusive Randbedingungen als Einschränkungen der Entwurfsfreiheit) klären und berücksichtigen.
-Sie verstehen, dass ihre Entscheidungen zu weiteren Anforderungen (inklusive Randbedingungen) an das zu entwerfende System, seine Architektur oder den Entwicklungsprozess führen können. 
+Softwarearchitekt:innen sind in der Lage, Anforderungen und Randbedingungen zu klären und zu berücksichtigen, die sich
+auf die zu entwerfende Architektur oder den Entwurfs- und Entwicklungsprozess auswirken.
+Sie wissen, dass ihre Entscheidungen zu zusätzlichen Anforderungen führen können.
 
 Sie erkennen und berücksichtigen den Einfluss von:
 
@@ -24,7 +23,7 @@ Sie erkennen und berücksichtigen den Einfluss von:
 ** Organisationsstruktur von Entwicklungsteams und Auftraggebenden (R1), insbesondere das Gesetz von Conway (R2)
 ** Unternehmens- und Teamkultur (R3)
 ** Partnerschaften und Kooperationen (R2)
-** Normen, Richtlinien und Prozessmodelle (z.B. Genehmigungs- und Freigabeprozesse) (R2)
+** Normen, Richtlinien und Prozessmodelle (z.{nbsp}B. Genehmigungs- und Freigabeprozesse) (R2)
 ** Verfügbarkeit von Ressourcen wie Budget, Zeit und Personal (R1)
 ** Verfügbarkeit, Qualifikation und Engagement von Mitarbeitenden (R1)
 
@@ -36,8 +35,8 @@ Sie erkennen und berücksichtigen den Einfluss von:
 
 * Trends wie (R3)
 ** Markttrends
-** Technologietrends (z.B. Blockchain, Microservices)
-** Methodik-Trends (z.B. agil)
+** Technologietrends (z.{nbsp}B. Blockchain, Microservices)
+** Methodik-Trends (z.{nbsp}B. Agilität)
 ** (potenzielle) Auswirkungen weiterer Stakeholderinteressen und vorgegebener oder extern festgelegter Designentscheidungen 
 // end::DE[]
 
@@ -77,8 +76,8 @@ They should recognize and account for the impact of:
 
 * trends such as (R3)
 ** market trends
-** technology trends
-** methodology trends
+** technology trends (Blockchain, Microservices)
+** methodology trends (Agile)
 
 Software architects are able to describe how those factors can influence
 design decisions and can elaborate on the consequences of changing

docs/02-requirements/LZ-02-03.adoc

@@ -7,10 +7,10 @@ Softwarearchitekt:innen können erklären:
 
 * dass der Begriff "Qualität" in verschiedenen Kontexten
   unterschiedlich benutzt wird - im Kontext von Qualitätsmanagement im
-  Sinne von "Güte" und im Sinne einer spezifischen Eigenschaften
+  Sinne von "Güte" und im Sinne spezifischer Eigenschaften
   (eines Softwaresystems) in anderen (und in diesem Abschnitt)
 * dass es unterschiedliche Taxonomien gibt, die Qualitäten von
-  Softwaresystemen kategorisieren (wie z.{nbsp}B.  <<iso25010>>,
+  Softwaresystemen kategorisieren (wie z.{nbsp}B. <<iso25010>>,
   <<bass>> oder <<q42>>)
 * dass manche Kategorisierungen zwischen Funktionalität und Qualität unterscheiden
 * dass Softwarearchitekt:innen die Qualitäten eines Softwaresystems

docs/02-requirements/LZ-02-04.adoc

@@ -1,14 +1,15 @@
 
 // tag::DE[]
 [[LZ-02-04]]
-==== LZ 02-04 [ehemaliges LZ 04-03]: Requirements and Software Architecture (R1-R3)
+==== LZ 02-04 [ehemaliges LZ 04-03]: Bedeutung von Anforderungen für die Softwarearchitektur verstehen (R1-R3)
+
 Softwarearchitekt:innen:
 
 * verstehen, dass eine Anforderung für eine gegebene Qualität
   eine Analysemethode spezifizieren sollte (siehe <<LZ-05-02>>) (R1)
 * verstehen, dass manche Kategorisierungen zwischen
   "Qualitätsanforderungen" und funktionalen Anforderungen
-  unterscheiden, wie zum Beispiel IREB <<IREBFoundation>> R1)
+  unterscheiden, wie zum Beispiel IREB <<IREBFoundation>> (R1)
 * verstehen, dass eine einzelne Anforderung sich auf mehrere
   Qualitäten beziehen kann (R1)
 * wissen, dass die Verwendung einer Metrik als Ziel diese invalidieren
@@ -22,7 +23,7 @@ Softwarearchitekt:innen:
 
 // tag::EN[]
 [[LG-02-04]]
-==== LG 02-04 [previously LG 04-03]: Requirements and Software Architecture (R1-R3)
+==== LG 02-04 [previously LG 04-03]: Understand the Importance of Requirements for Software Architecture (R1-R3)
 
 Software architects:
 

docs/02-requirements/LZ-02-05.adoc

@@ -1,7 +1,7 @@
 
 // tag::DE[]
 [[LZ-02-05]]
-==== LZ 02-05 [ehemaliges LZ 1-08]: Bevorzuge explizite Aussagen vor impliziten Annahmen (R1)
+==== LZ 02-05 [ehemaliges LZ 1-08]: Explizite Aussagen vor impliziten Annahmen bevorzugen (R1)
 
 Softwarearchitekt:innen:
 

docs/03-design/LZ-03-03.adoc

@@ -2,6 +2,7 @@
 // tag::DE[]
 [[LZ-03-03]]
 ==== LZ 03-03 [ehemaliges LZ 2-01]: Vorgehen und Heuristiken zur Architekturentwicklung auswählen und anwenden können (R1,R3)
+
 Softwarearchitekt:innen können grundlegende Vorgehensweisen der Architekturentwicklung benennen, erklären und anwenden, beispielsweise:
 
 * Top-down- und Bottom-up-Vorgehen beim Entwurf (R1)

docs/03-design/LZ-03-04.adoc

@@ -63,6 +63,7 @@ Softwarearchitekt:innen kennen weitere Prinzipien (etwa CUPID, siehe <<north-cup
 
 [[LG-03-04]]
 ==== LG 03-04 [previously LG 2-06]: Explain and Use Design Principles (R1-R3)
+
 Software architects are able to explain what design principles are.
 They can outline their general objectives and applications with regard to software architecture. (R2)
 
@@ -88,12 +89,12 @@ Software architects are able to:
 //, refer to <<LG-2-7, LG 2-7>>
 * high cohesion (R1)
 * SOLID principles (R1-R3), which have, to a certain extent, relevance at the architectural level
-** S: Single responsibility principle (R1) and its relation to SoC
+** S: Single responsibility principle (R1) and its relation to SoC
 ** O: Open/closed principle (R1)
-** L: Liskov substitution principle (R3) as a way to achieve consistency and conceptual integrity in OO design
-** I: Interface segregation principle (R2)
+** L: Liskov substitution principle (R3) as a way to achieve consistency and conceptual integrity in OO design
+** I: Interface segregation principle (R2)
 //, including its relation to <<LG-2-9, LG 2-9>>
-** D: Dependency inversion principle (R1) by means of interfaces or similar abstractions
+** D: Dependency inversion principle (R1) by means of interfaces or similar abstractions
 
 **Conceptual integrity** (R2)
 

docs/03-design/LZ-03-08.adoc

@@ -33,7 +33,7 @@ Softwarearchitekt:innen können einige der folgendene Muster erklären, ihre Rel
 * CQRS (Command-Query-Responsibility-Segregation): Trennung von Lese- und Schreibvorgängen in Informationssystemen. Erfordert Einblicke in konkrete Datenbank-/Persistenztechnologie, um die unterschiedlichen Eigenschaften und Anforderungen von "Lese-" und "Schreib"-Operationen zu verstehen.
 * Event-Sourcing: Behandlung von Datenoperationen durch eine Abfolge von Ereignissen (Events), von denen jedes in einem Append-only Speicher aufgezeichnet wird.
 * Interpreter: repräsentieren Domänenobjekt oder DSL als Syntax, bieten eine Funktion, die eine semantische Interpretation des Domänenobjekts getrennt vom Domänenobjekt selbst implementiert.
-* Integrations- oder Messaging-Patterns (z.B. aus <<hohpe>>)
+* Integrations- oder Messaging-Patterns (z.{nbsp}B. aus <<hohpe>>)
 * Die MVC- (Model View Controller), MVVM- (Model View ViewModel), MVU- (Model View Update), PAC- (Presentation Abstraction Control) Musterfamilie, die die externe Repräsentation (Ansicht) von Daten von Operationen Diensten und deren Koordination trennt.
 * Schnittstellenmuster wie Adapter, Fassade, Proxy. Solche Muster helfen bei der Integration von Subsystemen und/oder bei der Vereinfachung von Abhängigkeiten. Architekt:innen sollten wissen, dass diese Muster unabhängig von (Objekt-)Technologie verwendet werden können.
 ** Adapter: Entkopplung von Konsument und Provider - wenn die Schnittstelle des Providers nicht genau mit der des Konsumenten übereinstimmt.
@@ -43,22 +43,21 @@ Softwarearchitekt:innen können einige der folgendene Muster erklären, ihre Rel
   registriert sich bei einem Objekt (dem Subjekt), damit das Subjekt
   den Observer bei Änderungen benachrichtigt.
 * Plug-In: erweitert das Verhalten einer Komponente.
-* Ports&Adapters (syn. Onion-Architecture, Hexagonale Architektur, Clean-Architecture): konzentrieren die Domänenlogik im Zentrum des Systems, und besitzen lediglich an den Rändern Verbindungen zur Außenwelt (Datenbank, UI). Abhängigkeiten von außen nach innen (Outside-In), niemals von innen nach außen (Inside-Out). <<lange21>> <<hombergs>>
+* Ports & Adapters (Synonyme: Onion-Architecture, Hexagonale Architektur, Clean-Architecture): konzentrieren die Domänenlogik im Zentrum des Systems, und besitzen lediglich an den Rändern Verbindungen zur Außenwelt (Datenbank, UI). Abhängigkeiten von außen nach innen (Outside-In), niemals von innen nach außen (Inside-Out). <<lange21>> <<hombergs>>
 * Remote Procedure Call: eine Funktion oder einen Algorithmus in einem anderen Adressraum ausführen lassen.
 * SOA (Service-orientierte Architektur): Ein Ansatz zur Bereitstellung abstrakter Dienste statt konkreter Implementierungen für die Benutzer des Systems, um die Wiederverwendung von Diensten über Abteilungen und zwischen Unternehmen zu fördern.
 * Template und Strategy: spezifische Algorithmen durch Kapselung flexibel machen.
 * Visitor (Besucher): Traversierung von Datenstrukturen von spezifischer Verarbeitung trennen.
 
 
-Softwarearchitekt:innen kennen wesentliche Quellen für Architekturmuster, beispielsweise die POSA-Literatur (z.B. <<buschmanna>>) und PoEAA (<<fowler>>) (für Informationssysteme) (R3)
+Softwarearchitekt:innen kennen wesentliche Quellen für Architekturmuster, beispielsweise die POSA-Literatur (z.{nbsp}B. <<buschmanna>>) und PoEAA (<<fowler>>) (für Informationssysteme) (R3)
 
 // end::DE[]
 
 // tag::EN[]
 [[LG-03-08]]
 ==== LG 03-08 [previously LG 2-05]: Describe, Explain and Appropriately Apply Important Patterns (R1, R3)
 
-
 Software architects know:
 
 * various architectural patterns and can apply them when appropriate
@@ -95,7 +94,7 @@ Software architects can explain several of the following patterns, explain their
 * _observer_: An interested object (observer) registers with another
   object (the subject) so that the subject notifies the observer upon changes.
 * _plug-in_: extend the behaviour of a component
-* _ports & adapters_ (syn. Onion-Architecture, Hexagonal-Architecture, Clean-Architecture): concentrate domain logic in the center of the system, have connections to the outside world (database, UI) at the edges, dependencies only outside-in, never inside-out <<lange21>> <<hombergs>>
+* _ports & adapters_ (synonyms: Onion-Architecture, Hexagonal-Architecture, Clean-Architecture): concentrate domain logic in the center of the system, have connections to the outside world (database, UI) at the edges, dependencies only outside-in, never inside-out <<lange21>> <<hombergs>>
 * _remote procedure call_: make a function or algorithm execute in a different address space
 * _SOA_ (Service-Oriented Architecture): an approach to provide abstract services rather than concrete implementations to users of the system to promote reuse of services across departments and between companies
 * _template and strategy_: make specific algorithms flexible by encapsulating them

docs/03-design/LZ-03-09.adoc

@@ -16,7 +16,7 @@ Softwarearchitekt:innen wissen, dass solche Querschnittskonzepte systemübergrei
 
 // tag::EN[]
 [[LG-03-09]]
-==== LG 03-09 [previously LG 2-04]: Design and Implement Cross-Cutting Concerns (R1)
+==== LG 03-09 [previously LG 2-04]: Identify, Design and Implement Cross-Cutting Concerns (R1)
 
 Software architects are able to:
 

docs/03-design/LZ-03-10.adoc

@@ -9,7 +9,7 @@ Softwarearchitekt:innen:
 * können grundlegende Konzepte des Deployments von Software benennen und erklären, beispielsweise:
 ** Automatisierung von Deployments
 ** Wiederholbare Builds
-** Konsistente Umgebungen (z.B. durch Nutzung von unveränderlicher (_immutable_) Infrastruktur)
+** Konsistente Umgebungen (z.{nbsp}B. durch Nutzung von unveränderlicher (_immutable_) Infrastruktur)
 ** Alles liegt unter Versionskontrolle
 ** Releases sind einfach zurückzunehmen
 

docs/03-design/LZ-03-11.adoc

@@ -1,7 +1,7 @@
 
 // tag::DE[]
 [[LZ-03-11]]
-==== LZ 03-11 [ehemaliges LZ 1-11]: Herausforderungen verteilter Systeme (R3)
+==== LZ 03-11 [ehemaliges LZ 1-11]: Herausforderungen verteilter Systeme kennen (R3)
 
 Softwarearchitekt:innen können:
 
@@ -19,7 +19,7 @@ Softwarearchitekt:innen wissen:
 
 // tag::EN[]
 [[LG-03-11]]
-==== LG 03-11 [previously LG 1-11]: Challenges of Distributed Systems (R3)
+==== LG 03-11 [previously LG 1-11]: Know the Challenges of Distributed Systems (R3)
 
 Software architects are able to:
 

docs/04-documentation/LZ-04-02.adoc

@@ -6,7 +6,7 @@ Softwarearchitekt:innen nutzen Dokumentation zur Unterstützung bei Entwurf, Imp
 
 Softwarearchitekt:innen (R1):
 
-* können Architekturen entsprechend der Anliegen der Stakeholder dokumentieren und kommunizieren und dadurch unterschiedliche Zielgruppen adressieren, z. B. Management, Entwicklungsteams, QS, andere Softwarearchitekt:innen sowie möglicherweise zusätzliche Stakeholder
+* können Architekturen entsprechend der Anliegen der Stakeholder dokumentieren und kommunizieren und dadurch unterschiedliche Zielgruppen adressieren, z.{nbsp}B. Management, Entwicklungsteams, QS, andere Softwarearchitekt:innen sowie möglicherweise zusätzliche Stakeholder
 * können die Beiträge unterschiedlicher Autorengruppen stilistisch und inhaltlich konsolidieren und harmonisieren
 * können Maßnahmen entwickeln und umsetzen, die mündliche und schriftliche Kommunikation in Einklang miteinander halten und miteinander angemessen ausbalancieren
 * kennen den Nutzen von Template-basierter Dokumentation
@@ -17,7 +17,7 @@ Sie können beispielsweise die folgenden Merkmale von Dokumentation je nach Situ
 * Umfang und Detaillierungsgrad der benötigten Dokumentation
 * das Dokumentationsformat
 * die Zugänglichkeit der Dokumentation
-* Formalitäten der Dokumentation (z.B. Diagramme, die einem Metamodell entsprechen, oder einfache Zeichnungen)
+* Formalitäten der Dokumentation (z.{nbsp}B. Diagramme, die einem Metamodell entsprechen, oder einfache Zeichnungen)
 * formale Überprüfungen und Freigabeprozesse für die Dokumentation