curriculum-foundation
curriculum-foundation copied to clipboard
isaqb-org
LG 02-04 (V2025) LZ 4-2: Qualitätsanforderungen klären (nicht formulieren?)
Ich möchte gerne, dass wir die Formulierung dieses Lernziels noch mal anpassen, sodass Anforderungen von Architekten nicht formuliert werden, sondern nur geklärt werden. Beispielsweise, wir unterstützen die deren Formulierung.
aber:
- Architekt*en treffen oft "explizite Annahmen" (aka educated guesses) über die Qualitätsanforderungen. und formulieren daher...
- Architek*en helfen Stakeholdern oft dabei, die Q-Anforderungen zu formulieren
oder?
Zu Punkt 1: Ja, aber dann formulieren sie Annahmen und nicht QA. Zu Punkt 2: Ja, aber dann ist es noch mal Unterstützen. Ich trenne "Durchführen" und "Verantwortung".
Die Architekten führen oft Aufgaben für andere durch, obwohl es eigentlich nicht unsere Verantwortung sein sollte, bspw. Aufwandeinschätzung (PO, PM, Entwicklungsteam), Dokumentation der Qualitätsanforderungen (PO, Business Analyst), etc. Wenn wir es so formulieren, dass wir die anderen bei der Durchführung / Dokumentation / Formulierung unterstützen finde ich in Ordnung. Ich möchte damit deutlich machen, dass die Aufgaben unter der Verantwortung anderen liegen.
FLWG hat aktuelle Formulierung geprüft und für ok befunden (d.h. Rogers' Einwände sind unser Ansicht nach erfüllt)
Sorry to be a pain in the butt, but .... Dies wiederspricht, meiner Meinung nach, einer der Prüfungsfragen. Q-15-01-37. (sollten wir persönlich besprechen, da es um die Prüfungsfragen geht).
My specific recommendation for a formulation is as follows:
German Softwarearchitekt:innen können:
- architekturrelevante Qualitätsanforderungen mit den Verantwortlichen klären, z. B. bzgl. deren Verständlichkeit, Machbarkeit, Widersprüche usw.
- die Stakeholder bei der Definition bzw. Verbesserung der Qualitätsanforderungen, -szenarien und -bäumen unterstützen
- Qualitätsanforderungen, -szenarien und -bäume als Basis für Architekturentscheidungen verwenden.
English Software architects can:
- clarify architecturally relevant quality requirements with those responsible, e.g. regarding their understandability, feasibility, contradictions, etc.
- support stakeholders with the definition or improvement of the quality requirements, quality scenarios, and quality trees
- use quality requirements, quality scenarios, and quality trees as a basis for architecture decisions.
Is this issue still relevant since we changed the curriculum sections regarding quality?
The new formulation is: "understand that, in order to formulate a requirement on any given quality, they also should specify the method of analysis". This states that the Requirements should / can be specified by architects, which IMHO is not "correct".
FLWG: The group has conflicting opinions on this topic. @rhoadesre proposes a formulation that hopefully works for everybody.
Proposed formulation: "understand that the method of analysis (refer to LG 05-02) should be specified when requirements are defined on any given quality."
@rhoadesre This would be backwards - requirements aren't defined without a method of analysis.
Improvement: "understand that requirements for a given quality should be accompanied by a method of analysis"
@rhoadesre This would be backwards - requirements aren't defined without a method of analysis.
Improvement: "understand that requirements for a given quality should be accompanied by a method of analysis"
I agree with this statement and the formulation is fine for me. I would still put the reference in regarding "method of analysis" (refer to LG 05-02)
