From 73dd9952d85120e2da3a018e3340d5c370cbe95e Mon Sep 17 00:00:00 2001 From: Ulrich Becker Date: Sat, 12 Oct 2024 16:37:33 +0200 Subject: [PATCH] Chapter 2: Fix translation inconsistencies and minor issues --- docs/02-requirements/01-requirements-duration-terms.adoc | 4 ++-- docs/02-requirements/LG-02-01.adoc | 2 +- docs/02-requirements/LG-02-02.adoc | 2 +- docs/02-requirements/LG-02-03.adoc | 7 ++++--- docs/02-requirements/LG-02-05.adoc | 2 +- 5 files changed, 9 insertions(+), 8 deletions(-) diff --git a/docs/02-requirements/01-requirements-duration-terms.adoc b/docs/02-requirements/01-requirements-duration-terms.adoc index 82846d8..ce0392e 100644 --- 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 index c51ab75..ff092c3 100644 --- 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 index 1c975b1..b6891af 100644 --- 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 index be9f7f5..a76d121 100644 --- 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 <>, <>, or <>) +* that several taxonomies for categorizing qualities of software systems exist (such as <>, <>, or <>) * that some categorizations distinguish between functionality and quality, e.g. IREB <> * 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 index fceea1a..0d00ab1 100644 --- 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[]