Merge pull request #612 from isaqb-org/Chapter_2_fix_translations_and…

…_minor_issues Chapter 2: Fix translation inconsistencies and minor issues
isaqb-org · Oct 12, 2024 · adfdcc9 · adfdcc9
2 parents b7120c8 + 73dd995
commit adfdcc9
Show file tree

Hide file tree

Showing 5 changed files with 9 additions and 8 deletions.
diff --git a/docs/02-requirements/01-requirements-duration-terms.adoc b/docs/02-requirements/01-requirements-duration-terms.adoc
@@ -27,8 +27,8 @@ Qualität; Qualitätsmerkmale; DIN/ISO 25010; Q42; Qualitätsszenarien; Kompromi
 |===
 
 === Purpose
-This section deepens participants' understanding of stakeholder concerns, requirements, and system qualities in software architecture.
-Participants learn to identify stakeholders and their influence on architectural decisions, discerning conflicts and synergies in the context of development projects.
+This section deepens participants' understanding of stakeholder concerns, requirements, and qualities of software architecture.
+Participants learn to identify the influence of stakeholders on architectural decisions and to assess conflicts and synergies in the context of development projects.
 By exploring diverse requirements and constraints, they gain insight into effectively addressing stakeholders' needs and project constraints.
 Additionally, they recognize the significance of software system qualities as drivers for architectural design. 
 They can formulate such requirements using scenarios.

diff --git a/docs/02-requirements/LG-02-01.adoc b/docs/02-requirements/LG-02-01.adoc
@@ -72,7 +72,7 @@ Examples of stakeholders and concerns (R3):
 
 Software architects can explain potential conflicts between short-term and long-term goals, in order to resolve potential conflicts (e.g., business and project goals vs. architecture and maintainability goals). (R2)
 
-Architects understand that not all stakeholder concerns can or will be translated into requirements, but may nevertheless need to be considered. (R3)
+Architects understand that not all stakeholder concerns can or will be translated into requirements, but still need to be considered. (R3)
 
 Architects can use stakeholder concerns to discover missing or conflicting requirements and/or validate requirements and constraints on the architecture, e.g., in stakeholder interviews. (R3)
 

diff --git a/docs/02-requirements/LG-02-02.adoc b/docs/02-requirements/LG-02-02.adoc
@@ -45,7 +45,7 @@ Sie erkennen und berücksichtigen den Einfluss von:
 
 // tag::EN[]
 [[LG-02-02]]
-==== LG 02-02 [previously LG 2-3]: Identify and Consider Requirements and Constraints (R1-R3)
+==== LG 02-02 [previously LG 2-3]: Clarify and Consider Requirements and Constraints (R1-R3)
 
 Software architects understand that both requirements and constraints can have an impact on the architecture and the architecture work (R2).
 They are able to clarify requirements and constraints and take them into account in the architectural design and development process.

diff --git a/docs/02-requirements/LG-02-03.adoc b/docs/02-requirements/LG-02-03.adoc
@@ -34,15 +34,16 @@ Sie verstehen, dass
 [[LG-02-03]]
 ==== LG 02-03 [previously LG 4-1]: Understand and Explain Qualities of a Software System (R1)
 
-Software architects know that the term "quality" is used differently in different contexts: 
+Software architects know that the term "quality" is used differently in different contexts:
+
 * referring to "excellence" in the context of quality management, and
 * referring to a "specific property (of a software system)" in others.
 
 This learning goal refers to the latter.
 
-They can explain
+Software architects can explain
 
-* that several taxonomies categorizing qualities of software systems exist (such as <<iso25010>>, <<bass>>, or <<q42>>)
+* that several taxonomies for categorizing qualities of software systems exist (such as <<iso25010>>, <<bass>>, or <<q42>>)
 * that some categorizations distinguish between functionality and quality, e.g. IREB <<IREBFoundation>>
 * that software architecture can impact a software system's qualities,
 * that impacting one quality can impact others, necessitating trade-offs, such as:

diff --git a/docs/02-requirements/LG-02-05.adoc b/docs/02-requirements/LG-02-05.adoc
@@ -16,6 +16,6 @@ Softwarearchitekt:innen:
 
 Software architects:
 
+* can make assumptions explicit and thus avoid implicit assumptions
 * know that implicit assumptions can lead to misunderstandings between stakeholders
-* assumptions should be made explicit
 // end::EN[]