adapts title capitalization to improve consistency using following rule:

- chapter: title case
- section: sentence case
- everything below, e.g. bullets: lower case (terms like cloud native in LG 1-10 in italics)

hint:
- title case: 1st word, nouns, pronouns, verbs, adjectives and subordinate conjunctions start capitalized
- sentence case: 1st letter capitalized
- It does not matter how we do it, but the golden rule is to do whatever you do consistently

See isaqb-org#246

docs/00-preamble/01-what-to-expect.adoc

@@ -29,7 +29,7 @@ CPSA-F trainings teach methods and principles for design, documentation and eval
 
 Focus is education and training of the following skills:
 
-*	Discuss and reconcile fundamental architectural decisions with stakeholders from requirements, management, development, operations and test
+*	discuss and reconcile fundamental architectural decisions with stakeholders from requirements, management, development, operations and test
 *	understand the essential activities of software architecture, and carry out those for small- to medium sized systems
 *	document and communicate software architectures based upon architectural views, architecture patterns and technical concepts.
 

docs/00-preamble/02-out-of-scope.adoc

@@ -25,14 +25,14 @@ This curriculum reflects the contents currently considered by the iSAQB members
 
 The following topics or concepts are not part of CPSA-F:
 
-* Specific implementation technologies, frameworks or libraries
-* Programming or programming languages
-* Specific process models
-* Fundamentals of modelling notations (such as UML) or fundamentals of modelling itself
-* System analysis and requirements engineering (please refer to the education and certification program by IREB e. V., https://ireb.org, International Requirements Engineering Board)
-* Software testing (please refer to the education and certification program by ISTQB e.V., https://istqb.org, International Software Testing Qualification Board)
-* Project or product management
-* Introduction to specific software tools.
+* specific implementation technologies, frameworks or libraries
+* programming or programming languages
+* specific process models
+* fundamentals of modelling notations (such as UML) or fundamentals of modelling itself
+* system analysis and requirements engineering (please refer to the education and certification program by IREB e. V., https://ireb.org, International Requirements Engineering Board)
+* software testing (please refer to the education and certification program by ISTQB e.V., https://istqb.org, International Software Testing Qualification Board)
+* project or product management
+* introduction to specific software tools.
 
  The aim of the training is to provide the basics for acquiring the advanced knowledge and skills required for the respective application.
 

docs/00-preamble/03-prerequisites.adoc

@@ -40,15 +40,15 @@ The iSAQB e. V. may check the following prerequisites in certification examinati
 Participants should have the following knowledge and/or experience. 
 In particular, substantial practical experience from software development in a team is an important prerequisite for understanding the learning material and successful certification.
 
-* More than 18 months of practical experience with software development, gained through team-based development of several systems outside of formal education
-* Knowledge of and practical experience with at least one higher programming language, especially:
-** Concepts of 
+* more than 18 months of practical experience with software development, gained through team-based development of several systems outside of formal education
+* knowledge of and practical experience with at least one higher programming language, especially:
+** concepts of 
 *** modularization (packages, namespaces, etc.)
 *** parameter-passing (_call-by-value, call-by-reference_)
-*** _scope_, i.e. of type- and variable declaration and definition
-** Basics of type systems (static vs. dynamic typing, generic data types)
-** Error- and exception handling in software
-** Potential problems of global state and global variables
+*** _scope_, i.e. of type and variable declaration and definition
+** basics of type systems (static vs. dynamic typing, generic data types)
+** error and exception handling in software
+** potential problems of global state and global variables
 
 * Basic knowledge of:
 ** modelling and abstraction
@@ -59,8 +59,8 @@ In particular, substantial practical experience from software development in a t
 
 Furthermore, the following will be useful for understanding several concepts:
 
-* Basics and differences of imperative, declarative, object-oriented and functional programming
-* Practical experience in 
+* basics and differences of imperative, declarative, object-oriented and functional programming
+* practical experience in 
 ** a higher level programming language
 ** designing and implementing distributed applications, such as client-server systems or web applications
 ** technical documentation, especially documenting source code, system design or technical concepts

docs/01-basics/01-basics-duration-terms.adoc

@@ -35,7 +35,7 @@ Typen von IT-Systemen (eingebettete Systeme; Echtzeitsysteme; Informationssystem
 | Duration: 120 min. | Exercises: none
 |===
 
-=== Relevant Terms
+=== Relevant terms
 {glossary_url}software-architecture[Software architecture]; 
 architecture domains; {glossary_url}structure[structure]; 
 {glossary_url}building-block[building blocks]; 

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

@@ -17,9 +17,9 @@ Softwarearchitekt:innen kennen mehrere Definitionen von Softwarearchitektur (u.
 
 Software architects know several definitions of software architecture (incl. ISO 42010/IEEE 1471, SEI, Booch etc.) and can name their similarities:
 
-* Components/building blocks with interfaces and relationships
-* Building blocks as a general term, components as a special form thereof
-* Structures, cross-cutting concepts, principles
-* Architecture decisions and their consequences on the entire systems and its lifecycle
+* components/building blocks with interfaces and relationships
+* building blocks as a general term, components as a special form thereof
+* structures, cross-cutting concepts, principles
+* architecture decisions and their consequences on the entire systems and its lifecycle
 
 // end::EN[]

docs/01-basics/LZ-1-06.adoc

@@ -13,7 +13,7 @@ Dabei müssen sie bei anderen Stakeholdern systematisch Rückmeldung einholen.
 [[LG-1-6]]
 ==== LG 1-6: Can Explain the Correlation between Development Approaches and Software Architecture (R2)
 
-* Software architects are able to explain the influence of iterative approaches on architectural decisions (with regard to risks and predictability).
-* Due to inherent uncertainty, software architects often have to work and make decisions iteratively. To do so, they have to systematically obtain feedback from other stakeholders.
+* software architects are able to explain the influence of iterative approaches on architectural decisions (with regard to risks and predictability).
+* due to inherent uncertainty, software architects often have to work and make decisions iteratively. To do so, they have to systematically obtain feedback from other stakeholders.
 
 // end::EN[]

docs/01-basics/LZ-1-07.adoc

@@ -9,7 +9,7 @@ Softwarearchitekt:innen können potenzielle Zielkonflikte zwischen kurz- und lan
 
 // tag::EN[]
 [[LG-1-7]]
-==== LG 1-7: Differentiate between Short- And Long-Term Goals (R2)
+==== LG 1-7: Differentiate between Short- and Long-Term Goals (R2)
 
 Software architects can explain potential conflicts between short-term and long-term goals, in order to find a suitable solution for all stakeholders
 

docs/01-basics/LZ-1-10.adoc

@@ -18,14 +18,14 @@ Softwarearchitekt:innen kennen unterschiedliche Typen von IT-Systemen, beispiels
 
 // tag::EN[]
 [[LG-1-10]]
-==== LG 1-10: Differentiate Types of It Systems (R3)
+==== LG 1-10: Differentiate Types of IT Systems (R3)
 
 Software architects know different types of IT systems, for example:
 
 * information systems
 * decision support, data warehouse or business intelligence systems
 * mobile systems
-* _Cloud-native_ systems (refer to <<cncf>>)
+* _cloud native_ systems (refer to <<cncf>>)
 * batch processes or systems
 * systems based upon machine learning or artificial intelligence
 * hardware-related systems; here they understand the necessity of hardware/software co-design (temporal and content-related dependencies of hardware and software design)

docs/02-design/01-design-duration-terms.adoc

@@ -37,7 +37,7 @@ Domain-Driven Design
 | Duration: 330 min. | Excercises: 90 min.
 |===
 
-=== Relevant Terms
+=== Relevant terms
 Design; design approach; design decision; views; 
 {glossary_url}interface[interfaces];  
 technical and 

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

@@ -57,27 +57,27 @@ They should recognize and account for the impact of:
 ** technological, organizational and regulatory constraints.
 
 
-* Technological constraints such as 
+* technological constraints such as 
 ** existing or planned hardware and software infrastructure (R1)
 ** technological constraints on data structures and interfaces (R2)
 ** reference architectures, libraries, components, and frameworks (R1)
 ** programming languages (R2)
 
-* Organizational constraints such as
+* organizational constraints such as
 ** organizational structure of the development team and of the customer (R1), in particular Conway's law (R2).
 ** company and team cultures (R3)
 ** partnerships and cooperation agreements (R2)
 ** standards, guidelines, and process models (e.g. approval and release processes) (R2)
 ** available resources like budget, time, and staff (R1)
 ** availability, skill set, and commitment of staff (R1)
 
-* Regulatory constraints such as (R2)
+* regulatory constraints such as (R2)
 ** local and international legal constraints
 ** contract and liability issues
 ** data protection​ and privacy laws
 ** compliance issues or obligations to provide burden of proof​
 
-* Trends such as (R3)
+* trends such as (R3)
 ** market trends
 ** technology trends (e.g. blockchain, microservices)
 ** methodology trends (e.g. agile)

docs/02-design/LZ-2-05.adoc

@@ -67,36 +67,36 @@ Software architects know:
 
 Software architects can explain and provide examples for the following patterns (R1):
 
-* Layers:
-** Abstraction layers hide details, example: ISO/OSI network layers, or "hardware abstraction layer". See https://en.wikipedia.org/wiki/Hardware_abstraction
-** Another interpretation are Layers to (physically) separate functionality or responsibility, see https://en.wikipedia.org/wiki/Multitier_architecture
+* _layers_:
+** abstraction layers hide details, example: ISO/OSI network layers, or "hardware abstraction layer". See https://en.wikipedia.org/wiki/Hardware_abstraction
+** another interpretation are Layers to (physically) separate functionality or responsibility, see https://en.wikipedia.org/wiki/Multitier_architecture
 
-* Pipes-and-Filter: Representative for data flow patterns, breaking down stepwise processing into a series of processing-activities ("Filter") and associated data transport/buffering capabilities ("Pipes").
-* Microservices split application into separate executable that communicate via network
-* Dependency Injection as a possible solution for the Dependency-Inversion-Principle <<newman>>
+* _pipes and filter_: representative for data flow patterns, breaking down stepwise processing into a series of processing-activities ("Filter") and associated data transport/buffering capabilities ("Pipes").
+* _microservices_ split application into separate executable that communicate via network
+* _dependency injection_ as a possible solution for the Dependency-Inversion-Principle <<newman>>
 
 
 Software architects can explain several of the following patterns, explain their relevance for concrete systems, and provide examples. (R3)
 
-* Blackboard: handle problems that cannot be solved by deterministic algorithms but require diverse knowledge
-* Broker:  responsible for coordinating communication between provider(s) and consumer(s), applied in distributed systems. Responsible for forwarding requests and/or transmitting results and exceptions
-* Combinator (synonym: closure of operations), for domain object of type T, look for operations with both input and output type T. See <<yorgey>>
-* CQRS (Command-Query-Responsibility-Segregation): Separates read- from write concerns in information systems. Requires some context on database-/persistence technology to understand the different properties and requirements of "read" versus "write" operations
-* Event-Sourcing:  handle operations on data by a sequence of events, each of which is recorded in an append-only store
-* Interpreter: represent domain object or DSL as syntax, provide function implementing a semantic interpretation of domain object separately from domain object itself
-* Integration and messaging patterns (e.g. from Hohpe+2004])
-* The MVC (Model View Controller), MVVM (Model View ViewModel), MVU (Model View Update), PAC (Presentation Abstraction Control) family of patterns, separating external representation (view) from data, services and their coordination
-* Interfacing-patterns like Adapter, Facade, Proxy. Such patterns help in integration of subsystems and/or simplification of dependencies. Architects should know that these patterns can be used independent of (object) technology
-** Adapter: decouple consumer and provider - where the interface of the provider does not exactly match that of the consumer. The Adapter decouples one party from interface-changes in the other
-** Facade: simplifies usage of a provider for consumer(s) by providing simplified access
-** Proxy: An intermediate between consumer and provider, enabling temporal decoupling, caching of results, controlling access to the provider etc.
-* Observer: a producer of values over time notifies a central switchboards where consumers can register to be notified of them
-* 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>> <<martin17>>
-* 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
-* Visitor: separate data-structure traversal from specific processing
+* _blackboard_: handle problems that cannot be solved by deterministic algorithms but require diverse knowledge
+* _broker_:  responsible for coordinating communication between provider(s) and consumer(s), applied in distributed systems. Responsible for forwarding requests and/or transmitting results and exceptions
+* _combinator_ (synonym: closure of operations), for domain object of type T, look for operations with both input and output type T. See <<yorgey>>
+* _CQRS_ (Command-Query-Responsibility-Segregation): separates read from write concerns in information systems. Requires some context on database-/persistence technology to understand the different properties and requirements of "read" versus "write" operations
+* _event sourcing_:  handle operations on data by a sequence of events, each of which is recorded in an append-only store
+* _interpreter_: represent domain object or DSL as syntax, provide function implementing a semantic interpretation of domain object separately from domain object itself
+* integration and messaging patterns (e.g. from Hohpe+2004])
+* the MVC (Model View Controller), MVVM (Model View ViewModel), MVU (Model View Update), PAC (Presentation Abstraction Control) family of patterns, separating external representation (view) from data, services and their coordination
+* interfacing patterns like Adapter, Facade, Proxy. Such patterns help in integration of subsystems and/or simplification of dependencies. Architects should know that these patterns can be used independent of (object) technology
+** _adapter_: decouple consumer and provider - where the interface of the provider does not exactly match that of the consumer. The Adapter decouples one party from interface-changes in the other
+** _facade_: simplifies usage of a provider for consumer(s) by providing simplified access
+** _proxy_: an intermediate between consumer and provider, enabling temporal decoupling, caching of results, controlling access to the provider etc.
+* _observer_: a producer of values over time notifies a central switchboards where consumers can register to be notified of them
+* _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>> <<martin17>>
+* _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
+* _visitor_: separate data-structure traversal from specific processing
 
 Software architects know essential sources for architectural patterns, such as POSA (e.g. <<buschmanna>>) and PoEAA (<<fowler>>) (for information systems) (R3).
 

docs/02-design/LZ-2-06.adoc

@@ -101,12 +101,12 @@ Software architects are able to:
 * as a means to reduce complexity (R1)
 * as the driving factor behind KISS (R3) and YAGNI (R3)
 
-**Expect Errors** (R1-R2)
+**Expect errors** (R1-R2)
 
 * as a means to design for robust and resilient systems (R1)
 * as a generalization of the robustness principle (_Postel's law_) (R2)
 
-**Other Principles** (R3)
+**Other principles** (R3)
 
 Software architects know other principles (such as CUPID, see <<nygard-cupid>>), and can apply them.
 // end::EN[]

docs/02-design/LZ-2-07.adoc

@@ -27,8 +27,8 @@ Software architects understand dependencies and coupling between building blocks
 * understand how dependencies increase coupling
 * can use such types of coupling in a targeted manner and can assess the consequences of such dependencies
 * know and can apply possibilities to reduce or eliminate coupling, for example:
-** Patterns (see <<LG-2-5, LG 2-5>>)
-** Fundamental design principles (see <<LG-2-6, LG 2-6>>)
-** Externalization of dependencies, i.e. defining concrete dependencies at installation- or runtime, for example by using _Dependency Injection_.
+** patterns (see <<LG-2-5, LG 2-5>>)
+** fundamental design principles (see <<LG-2-6, LG 2-6>>)
+** externalization of dependencies, i.e. defining concrete dependencies at installation- or runtime, for example by using _Dependency Injection_.
 
 // end::EN[]

docs/02-design/LZ-2-09.adoc

@@ -34,7 +34,7 @@ They know:
 ** functionally complete from the perspective of users or building blocks using them.
 * the necessity to treat internal and external interfaces differently
 * different approaches for implementing interfaces (R3):
-** Resource-oriented approach (REST, Representational State Transfer)
-** Service-oriented approach (see WS-*/SOAP-based web services.
+** resource oriented approach (REST, Representational State Transfer)
+** service oriented approach (see WS-*/SOAP-based web services.
 
 // end::EN[]

docs/03-documentation/LZ-3-04.adoc

@@ -16,8 +16,8 @@ Softwarearchitekt:innen können folgende Architektursichten anwenden:
 Software architects are able to use the following architectural views:
 
 * context view 
-* building-block or component view (composition of software building blocks) 
-* run-time view (dynamic view, interaction between software building blocks at run-time, state machines) 
+* building block or component view (composition of software building blocks) 
+* runtime view (dynamic view, interaction between software building blocks at runtime, state machines) 
 * deployment view (hardware and technical infrastructure as well as the mapping of software building blocks onto the infrastructure)
 
 // end::EN[]

docs/04-quality/01-quality-duration-terms.adoc

@@ -19,7 +19,7 @@ Qualität; Qualitätsmerkmale; DIN/ISO 25010; Qualitätsszenarien; Qualitätsbau
 | Duration: 60 min. | Exercises: 60 min.
 |===
 
-=== Relevant Terms
+=== Relevant terms
 Quality; quality characteristics (also called quality attributes); DIN/ISO 25010; quality scenarios; quality tree; trade-offs between quality characteristics; qualitative architecture analysis; metrics and quantitative analysis
 
 // end::EN[]