Qualitätsanforderungen

Kapitel 1.2 nennt drei Qualitätsziele in fester Rangfolge: 1. Benutzerfreundlichkeit, 2. Änderbarkeit Richtung SaaS, 3. Verfügbarkeit. Dieses Kapitel deckt alle acht Merkmale der ISO/IEC 25010 ab und markiert je Merkmal, ob es eines der drei Ziele konkretisiert oder abgeleitet ist. Die Szenarien stammen vom Miro-Board zu Folge 113 (Seite 5 und 6). Eberhard hat sie in Folge 111 als Stimulus und Response mit Metrik formuliert, "messbar mit Stoppuhr" (V8, 44:36 und 49:30). QS-Z-03 kam in Folge 112 hinzu (13:07 bis 14:35). Folge 113 setzt die Szenarien in Maßnahmen um, Szenario für Szenario als Sanity Check (27:34 bis 49:00), und vertagt die Usability-Szenarien auf Folge 114.

10.1 Qualitätsbaum

ISO/IEC-25010-Merkmal Kennzeichnung Szenarien und Belege

Benutzbarkeit (Usability)

konkretisiert Ziel 1 aus Kapitel 1.2

QS-U-01 bis QS-U-07 (Board Seite 5)

Wartbarkeit (Maintainability), hier Änderbarkeit

konkretisiert Ziel 2 aus Kapitel 1.2

QS-A-01 (Board Seite 6); fachlicher Schnitt in vier Module (Kapitel 4)

Zuverlässigkeit (Reliability), hier Verfügbarkeit und Wiederherstellbarkeit

konkretisiert Ziel 3 aus Kapitel 1.2

QS-Z-01 bis QS-Z-07 (Board Seite 6); ADR-008

Sicherheit (Security)

abgeleitet; bewusst nachrangig (Folge 111, 41:44 und 58:03)

Threat Model 8.1, Maßnahmen 8.2; kein Board-Szenario

Performance (Performance Efficiency)

abgeleitet

Einzige Zahl: Preisermittlung in 2 Minuten nach Ausfall (QS-Z-03); Skalierbarkeit auf dem Board mit ? markiert

Kompatibilität (Compatibility)

abgeleitet

Sieben REST-Schnittstellen und JWT-Cookie (Kapitel 3); Same-Origin-Policy (ADR-002)

Funktionale Eignung (Functional Suitability)

abgeleitet

Stories auf Board Seite 1; Reparatur als eigener Ablauf statt Webshop-Produkt (ADR-003)

Übertragbarkeit (Portability)

abgeleitet

Cloud bei AWS entschieden (ADR-013); Monolith oder Microservices vertagt (ADR-014); Board Seite 10 und 11
Note
 Offen: Für Sicherheit, Performance, Kompatibilität, funktionale Eignung und Übertragbarkeit nennt das Board keine Szenarien mit Zahl. Die Zeilen sind abgeleitet und ohne Maß. Eberhard kündigt in Folge 113 den ISO-25010-Baum als Prüfliste an, "ob ich alle wesentlichen Informationen abgefragt habe" (62:43 bis 63:00), führt die Prüfung aber nicht durch. Security fällt dort nur als Grund für Updates (29:05) und als DSGVO-Prüfung für AWS (43:39); Performance nur als Latenz-Hinweis von Jan (21:50); Kompatibilität sachlich bei fremden Kassen- und Rechnungssystemen anderer Shops (47:50 bis 48:44).

10.2 Qualitätsszenarien

Jedes Szenario steht in der sechsteiligen Form. Das Maß trägt die Zahl vom Board. "Antwort der Architektur" nennt die Maßnahmen-Karte vom Board.

Benutzbarkeit

Note
 Offen: Folge 113 vertagt alle Usability-Szenarien ausdrücklich auf die Folge mit der UX-Expertin Aminata: "die werden dann keine Rolle spielen" (03:21), "da werden wir Aminata nächstes Mal nerven" (05:22), "Benutzerfreundlichkeit diskutieren wir beim nächsten Mal" (54:20). Keine der Zahlen in QS-U-01 bis QS-U-06 ist im Video begründet, keine Maßnahme genannt; die rote Karte "nicht erfüllbar" zu QS-U-01 wird nicht erwähnt.
Table 1. QS-U-01: Registrierung in einer Minute

Quelle

Neue Kund:in

Stimulus

Will das System nutzen und registriert sich

Artefakt

Reparatursystem, Registrierung

Umgebung

Normalbetrieb

Reaktion

Konto ist angelegt

Maß

Innerhalb von 1 Minute

Antwort der Architektur

Keine. Auf dem Board als nicht erfüllbar markiert, Registrierung liegt im Webshop (ADR-001).

Bezug

konkretisiert Ziel 1
Table 2. QS-U-02: Reparatur beauftragen

Quelle

Frisch registrierte Kund:in

Stimulus

Will eine Reparatur beauftragen

Artefakt

Reparaturbereich unter /reparatur, Auftragsformular

Umgebung

Normalbetrieb, Kund:in ist im Webshop eingeloggt

Reaktion

Auftrag ist erfasst

Maß

90 % der Benutzer:innen schaffen das innerhalb von 2 Minuten

Antwort der Architektur

Login und vorbelegte Adresse aus dem Webshop (ADR-001, ADR-002); eigener Bezahlvorgang (ADR-003)

Bezug

konkretisiert Ziel 1
Table 3. QS-U-03: Bewertung durch Kund:innen

Quelle

Kund:in

Stimulus

Bewertet das System

Artefakt

Reparatursystem, Kundensicht

Umgebung

Nach abgeschlossener Reparatur

Reaktion

Bewertung liegt vor

Maß

Im Schnitt 4 von 5 Punkten

Antwort der Architektur

Eigene Statusseite, Benachrichtigung per E-Mail (ADR-005, ADR-007)

Bezug

konkretisiert Ziel 1
Table 4. QS-U-04: Empfehlung durch Mitarbeitende

Quelle

Mitarbeiter:innen des Shops

Stimulus

Werden gefragt, ob sie das System empfehlen

Artefakt

Reparatursystem, Werkstattsicht

Umgebung

Laufender Betrieb

Reaktion

Empfehlung

Maß

85 % würden das System sehr wahrscheinlich anderen empfehlen

Antwort der Architektur

Keine Maßnahmen-Karte auf dem Board

Bezug

konkretisiert Ziel 1
Table 5. QS-U-05: Einarbeitung Shop-Mitarbeiter:in

Quelle

Neue Shop-Mitarbeiter:in

Stimulus

Wird in das System eingearbeitet

Artefakt

Reparatursystem, Funktionen Abgabe und Bezahlung

Umgebung

Laufender Betrieb

Reaktion

Bedient das System eigenständig

Maß

Nach 1 Stunde

Antwort der Architektur

Keine Maßnahmen-Karte auf dem Board

Bezug

konkretisiert Ziel 1
Table 6. QS-U-06: Einarbeitung Fahrrad-Mechaniker:in

Quelle

Neue Fahrrad-Mechaniker:in

Stimulus

Wird in das System eingearbeitet

Artefakt

Reparatursystem, Werkstattfunktionen

Umgebung

Laufender Betrieb

Reaktion

Bedient das System eigenständig

Maß

Nach 1 Stunde

Antwort der Architektur

Keine Maßnahmen-Karte auf dem Board

Bezug

konkretisiert Ziel 1
Table 7. QS-U-07: Betrieb ohne IT-Experten

Quelle

Shop

Stimulus

Betreibt das System ohne IT-Experten

Artefakt

Gesamtsystem, Betrieb

Umgebung

Dauerbetrieb

Reaktion

Das System läuft dennoch

Maß

Kein IT-Experte beschäftigt (Board nennt keine Zahl)

Antwort der Architektur

Cloud (ADR-013); Eigener Support mit Rufbereitschaft (ADR-017). Folge 113: Ohne IT-Experten kann niemand einen Server im Laden betreiben (05:47 bis 05:57), und Cloud allein reicht nicht, weil Ausfälle und Security-Updates jemanden brauchen, "der angerufen werden kann" (28:42 bis 29:24)

Bezug

konkretisiert Ziel 1 (Mitarbeitende); stützt zugleich Ziel 3

Zuverlässigkeit

Table 8. QS-Z-01: Verfügbarkeit Werkstatt

Quelle

Mitarbeiter:in im Shop

Stimulus

Will das System zwischen 9 und 18 Uhr nutzen

Artefakt

Werkstatt-Teil des Systems

Umgebung

Ladenöffnungszeit

Reaktion

System steht zur Verfügung

Maß

99 % Verfügbarkeit

Antwort der Architektur

EKS / EC2 SLAs: mindestens zwei Instanzen über mehrere Availability Zones (ADR-015); Eigener Support (ADR-017). Folge 113: 99 % zwischen 9 und 18 Uhr sind "3 Minuten am Tag", profan machbar (30:36 bis 30:55)

Bezug

konkretisiert Ziel 3 (ADR-008)
Table 9. QS-Z-02: Wiederanlauf Werkstatt

Quelle

Ausfall

Stimulus

Das System im Shop fällt aus

Artefakt

Werkstatt-Teil des Systems

Umgebung

Ladenöffnungszeit

Reaktion

System steht wieder zur Verfügung

Maß

Spätestens nach 30 Minuten

Antwort der Architektur

EKS / EC2 SLAs: mindestens zwei Instanzen über mehrere Availability Zones (ADR-015); Eigener Support (ADR-017); Netzausfall im Laden als akzeptiertes Risiko mit mobilem Router als Reserve (ADR-018). Folge 113: Ein Wiederanlauf in 30 Minuten vor Ort ist ohne IT-Experten nicht machbar, deshalb Cloud (06:30 bis 06:44)

Bezug

konkretisiert Ziel 3 (ADR-008: "30 Minuten Zettel und Bleistift")
Table 10. QS-Z-03: Preisermittlung nach Ausfall

Quelle

Ausfall

Stimulus

Das System im Shop fällt aus

Artefakt

Modul Reparatur durchführen, Preis aus dem Protokoll

Umgebung

Ladenöffnungszeit, Kund:in wartet an der Kasse

Reaktion

Preis einer erfolgten Reparatur ist wieder ermittelbar

Maß

Spätestens nach 2 Minuten

Antwort der Architektur

EKS / EC2 SLAs (ADR-015); Eigener Support (ADR-017); Netzausfall im Laden als akzeptiertes Risiko mit mobilem Router, Cache-Server im Laden verworfen (ADR-018). Folge 113 nennt dieses Szenario "das aggressivste Wiederanlauf-Kriterium, was wir haben" (07:55 bis 08:20). Eberhard erwägt in Folge 112 einen Low-Tech-Fallback: einen Zettel am Fahrrad mit dem Preis ("diese Reparatur hat übrigens 10 Euro gekostet") oder eine fest abgelegte Tabelle (14:13 bis 14:35). Entschieden ist nichts: "da kann man sich was ausdenken".

Bezug

konkretisiert Ziel 3. Quelle: Folge 112, 13:07 bis 14:35. Das Szenario entsteht dort aus der Frage, was bei Abholung passiert: "muss ich dem Menschen das Geld abknöpfen, dafür brauche ich diese Information"; die Annahme verträgt 30 Minuten, die Preisermittlung nicht. Board Seite 6 hält es fest.
Table 11. QS-Z-04: Verfügbarkeit Web tagsüber

Quelle

Kund:in

Stimulus

Will das Web-System zwischen 7 und 24 Uhr nutzen

Artefakt

Web-Teil des Systems unter /reparatur

Umgebung

Tag und Abend

Reaktion

System steht zur Verfügung

Maß

99,9 % Verfügbarkeit

Antwort der Architektur

EKS / EC2 SLAs: mindestens zwei Instanzen über mehrere Availability Zones (ADR-015); Eigener Support (ADR-017)

Bezug

konkretisiert Ziel 3 (ADR-008: "jede Minute Umsatzausfall")
Table 12. QS-Z-05: Verfügbarkeit Web nachts

Quelle

Kund:in

Stimulus

Will das Web-System zwischen 24 und 7 Uhr nutzen

Artefakt

Web-Teil des Systems unter /reparatur

Umgebung

Nacht

Reaktion

System steht zur Verfügung

Maß

99 % Verfügbarkeit

Antwort der Architektur

EKS / EC2 SLAs: mindestens zwei Instanzen über mehrere Availability Zones (ADR-015); Eigener Support 24/7 (ADR-017). Folge 113 leitet die Rufbereitschaft rund um die Uhr aus 7 bis 24 Uhr und 24 bis 7 Uhr zusammen ab, "wahrscheinlich keine Entwicklerin" (40:26 bis 40:59)

Bezug

konkretisiert Ziel 3
Table 13. QS-Z-06: Schneller Wiederanlauf

Quelle

Ausfall

Stimulus

Das System im Shop fällt aus

Artefakt

System (Board: "im Shop")

Umgebung

Nicht benannt

Reaktion

System steht wieder zur Verfügung

Maß

Spätestens nach 5 Minuten

Antwort der Architektur

EKS / EC2 SLAs (ADR-015); Eigener Support (ADR-017)

Bezug

konkretisiert Ziel 3; Board-Artefakt, im Video nicht belegt (siehe Note)
Note
 Offen: QS-Z-02 und QS-Z-06 nennen beide "das System im Shop" mit 30 und 5 Minuten. ADR-008 ordnet den schnelleren Wiederanlauf dem Web-System nachts zu (Folge 111, 56:07). Die 5-Minuten-Karte fällt in keiner der drei Folgen. In Folge 113 nennt Eberhard bei 08:20 die 2-Minuten-Preisermittlung (QS-Z-03) "das aggressivste Wiederanlauf-Kriterium, was wir haben"; eine 5-Minuten-Karte für den Shop widerspräche dem. QS-Z-06 gilt deshalb als Board-Artefakt, im Video nicht belegt, vermutlich aus der Vorbereitung des Boards (26:05, 53:24). Es bleibt im Bestand, weil es auf dem Board steht; welche Zuordnung gilt, muss das Team klären.
Table 14. QS-Z-07: Datenverlust

Quelle

Ausfall

Stimulus

Das System fällt aus

Artefakt

Persistenz der Reparaturdaten

Umgebung

Beliebig

Reaktion

Daten, die älter als 5 Minuten sind, stehen wieder zur Verfügung

Maß

Mit 99,9 % Sicherheit; Datenverlust höchstens 5 Minuten

Antwort der Architektur

RDS, relational mit Oracle oder MySQL, kein NoSQL (ADR-016). Das Fragezeichen auf dem Board bleibt: RDS garantiert Verfügbarkeit, "den Datenverlust aber nicht getrennt" (Folge 113, 42:01)

Bezug

konkretisiert Ziel 3 (ADR-008, R-024). Die Zahlen 5 Minuten und 99,9 % fallen im Video nicht; Eberhard liest das Szenario in Folge 113 nur als "Daten nicht verloren gehen" (40:59)

Änderbarkeit

Table 15. QS-A-01: SaaS für andere Fahrrad-Shops

Quelle

Geschäftsführung

Stimulus

Das System soll als SaaS-Lösung auch anderen Fahrrad-Shops angeboten werden

Artefakt

Gesamtsystem, Betrieb und Integrationen

Umgebung

Entwicklungszeit, System ist im Betrieb

Reaktion

Die Änderung ist umgesetzt

Maß

Höchstens 2 Monate und nicht mehr als 20 PT

Antwort der Architektur

Cloud (ADR-013), die allein "extrem profan" ist und nicht reicht (Folge 113, 44:18); Mandantenfähigkeit von Anfang an, entschieden (44:10 bis 47:02, 56:33 bis 57:43), mit offen benanntem Trade-off zur Instanz je Shop und zu Serverless; Skalierbarkeit auf zwei, drei oder zehn Shops nicht fokussiert (47:02 bis 47:47); Drittsysteme je Shop offen, erwartete Einschränkung auf bestimmte Kassen- und Rechnungssysteme (47:50 bis 48:44) (R-003, R-006, R-013, R-018, R-026)

Bezug

konkretisiert Ziel 2
Note
 Offen: Das Board nennt keine Szenarien für Security, Performance oder Kompatibilität. Die Karte "Skalierbarkeit?" bleibt ohne Maß; Folge 113 sagt dazu nur, "zwei, drei oder zehn" Shops seien kein Problem (47:02 bis 47:47).

10.3 Welche Entscheidungen auf welche Szenarien antworten

Note
 Dieser Abschnitt ist eine Auswertung, keine Quelle. Er ordnet zu, was in Abschnitt 10.2 und in den ADRs aus Kapitel 9 schon steht. Er ergänzt nichts vom Board und nichts aus den Folgen 111 bis 113.
Table 16. Szenario zu Entscheidung
Szenario Maß Antwortende ADRs Maßnahme laut Board

QS-U-01 Registrierung

1 Minute

ADR-001 (erklärt das Szenario für nicht erfüllbar)

Keine; auf dem Board als nicht erfüllbar markiert

QS-U-02 Reparatur beauftragen

90 % in 2 Minuten

ADR-001, ADR-002, ADR-003

Login und Adresse aus dem Webshop; eigener Bezahlvorgang

QS-U-03 Bewertung durch Kund:innen

4 von 5 Punkten

ADR-005, ADR-007

Eigene Statusseite; Benachrichtigung per E-Mail

QS-U-04 Empfehlung durch Mitarbeitende

85 %

keine Entscheidung dokumentiert

Keine Maßnahmen-Karte

QS-U-05 Einarbeitung Shop-Mitarbeiter:in

1 Stunde

keine Entscheidung dokumentiert

Keine Maßnahmen-Karte

QS-U-06 Einarbeitung Fahrrad-Mechaniker:in

1 Stunde

keine Entscheidung dokumentiert

Keine Maßnahmen-Karte

QS-U-07 Betrieb ohne IT-Experten

Keine Zahl

ADR-013, ADR-017; betroffen: ADR-004, ADR-006, ADR-008

Cloud; Eigener Support

QS-Z-01 Verfügbarkeit Werkstatt

99 %, 9 bis 18 Uhr

ADR-008 (setzt das Ziel), ADR-015, ADR-017

EKS / EC2 SLAs; Eigener Support

QS-Z-02 Wiederanlauf Werkstatt

30 Minuten

ADR-008, ADR-015, ADR-017, ADR-018

EKS / EC2 SLAs; Eigener Support

QS-Z-03 Preisermittlung nach Ausfall

2 Minuten

ADR-004, ADR-008, ADR-018

EKS / EC2 SLAs; Eigener Support

QS-Z-04 Verfügbarkeit Web tagsüber

99,9 %, 7 bis 24 Uhr

ADR-008, ADR-015, ADR-017; ADR-001 (betroffen, R-002)

EKS / EC2 SLAs; Eigener Support

QS-Z-05 Verfügbarkeit Web nachts

99 %, 24 bis 7 Uhr

ADR-008, ADR-015, ADR-017

EKS / EC2 SLAs; Eigener Support 24/7

QS-Z-06 Schneller Wiederanlauf

5 Minuten (Board-Artefakt, im Video nicht belegt)

ADR-008

EKS / EC2 SLAs; Eigener Support

QS-Z-07 Datenverlust

99,9 %, höchstens 5 Minuten (Zahlen im Video nicht genannt)

ADR-008 (R-024), ADR-016

RDS SLAs (?)

QS-A-01 SaaS für andere Fahrrad-Shops

2 Monate, 20 PT

ADR-013; Mandantenfähigkeit von Anfang an (Folge 113, 44:10 bis 47:02); ADR-001, ADR-002, ADR-004, ADR-005, ADR-006 (betroffen über R-003, R-006, R-013, R-018)

Cloud; Mandantenfähigkeit; Skalierbarkeit (?); Drittsysteme je Shop
Table 17. Entscheidung zu Szenario
ADR Szenarien Bemerkung

ADR-001 Login über den Webshop

QS-U-01, QS-U-02, QS-Z-04, QS-A-01

Treibt QS-U-02; macht QS-U-01 im Reparatursystem unerfüllbar; R-002 und R-003 belasten QS-Z-04 und QS-A-01

ADR-002 Pfad unter der Webshop-Domain

QS-U-02, QS-A-01

Folge aus ADR-001; R-006 belastet QS-A-01

ADR-003 Reparatur als eigener Bereich

QS-U-02

Der eigene Bezahlvorgang muss die zwei Minuten halten (R-008)

ADR-004 Payment Service und Kasse

QS-Z-03, QS-U-07, QS-A-01

Die Kasse im Laden trägt QS-Z-03; keine eigene Abwicklung wegen QS-U-07; R-013 belastet QS-A-01

ADR-005 Eigene Statusseite

QS-U-03, QS-A-01

Die Statusseite ist die Kundensicht nach der Reparatur; ein Datenort hilft QS-A-01

ADR-006 Ersatzteile selbst führen

QS-U-07, QS-A-01

Ein System weniger für den Laden; R-018 belastet QS-A-01

ADR-007 Benachrichtigung per E-Mail

keine Szenario-Basis, folgt aus Randbedingung

QS-U-03 nennt die E-Mail als Antwort; die Kanalwahl selbst folgt aus "Dienste kaufen statt betreiben"

ADR-008 Verfügbarkeit differenziert

QS-Z-01 bis QS-Z-07, QS-U-07

Setzt die Maße aller QS-Z-Szenarien; Betriebsmodell und Persistenz sind seit Folge 113 entschieden (ADR-013, ADR-016); R-022 bleibt, weil die Kasse aus der Cloud nicht entschieden ist

ADR-013 Betrieb in der Cloud bei AWS

QS-U-07, QS-A-01, QS-Z-01 bis QS-Z-05

Antwort auf "keine IT-Experten" und Voraussetzung für SaaS; Restrisiko Regionsausfall akzeptiert; die Kasse aus der Cloud bleibt Risiko (R-010)

ADR-014 Monolith oder Microservices, vertagt

keine Szenario-Basis

Für die Qualitätsziele "relativ irrelevant" (Folge 113, 20:29); beide Varianten "genauso verfügbar"

ADR-015 Mindestens zwei Instanzen über mehrere Availability Zones

QS-Z-01, QS-Z-02, QS-Z-04, QS-Z-05

Leitet sich aus dem AWS-SLA ab: Ausfall zählt erst ab mehr als einer Availability Zone

ADR-016 Relationale Datenbank als RDS

QS-Z-07

RDS garantiert Verfügbarkeit, den Datenverlust nicht getrennt; Fragezeichen bleibt

ADR-017 Eigener Support mit Rufbereitschaft

QS-U-07, QS-Z-01 bis QS-Z-05

Cloud allein reicht nicht; tagsüber Entwicklerin, nachts Rufbereitschaft

ADR-018 Netzausfall im Laden als akzeptiertes Risiko

QS-Z-02, QS-Z-03

Mobiler Router als Reserve; Cache-Server im Laden verworfen

Drei Szenarien stehen ohne Entscheidung und ohne Maßnahmen-Karte da: QS-U-04, QS-U-05 und QS-U-06; Folge 113 vertagt sie auf Folge 114. Seit Folge 113 haben sieben Szenarien eine entschiedene Maßnahme: QS-U-07 (ADR-013, ADR-017), QS-Z-01, QS-Z-02, QS-Z-04 und QS-Z-05 (ADR-015, ADR-017), QS-Z-03 (ADR-018) und QS-Z-07 (ADR-016, mit Fragezeichen beim Datenverlust). QS-A-01 hat die Mandantenfähigkeit entschieden; die Drittsysteme je Shop bleiben offen. QS-Z-06 bleibt ohne Videobeleg. Offen für kommende ADRs: die Anbindung von Kasse und Rechnungswesen aus der Cloud (R-010, R-022) und die Drittsysteme bei SaaS.

Eine Entscheidung steht ohne Szenario da: ADR-007. Die Wahl des Kanals folgt aus der Randbedingung, dass der Laden Dienste kauft statt betreibt, nicht aus einem Maß. Alle anderen ADRs treiben mindestens ein Szenario oder werden von einem belastet.