04 Quiz: Requirements Engineering

Die zentrale Botschaft der Vorlesung ist, dass man beim Versuch, die Testabdeckung zu verbessern, oft auf implizite oder fehlende Anforderungen stößt. Fragen wie “Was soll passieren, wenn der Strahl vertikal ist?” zeigen, dass man das erwartete Verhalten nicht kennt - das ist eine Anforderungslücke, nicht nur eine Testlücke. Man kann keine aussagekräftigen Tests schreiben, ohne zu wissen, was “korrektes” Verhalten bedeutet.

Optionen A, B und D beschreiben, was das System tut - das sind funktionale Anforderungen. Option C beschreibt, wie gut das System es tut (ein Qualitätsattribut: Performance). Nicht-funktionale Anforderungen umfassen Kategorien wie Performance, Sicherheit, Benutzerfreundlichkeit, Zuverlässigkeit und Wartbarkeit. Die 100ms-Reaktionszeit ist eine Performance-Einschränkung, keine Funktion.

Kommentare und Docstrings werden nicht vom Compiler oder zur Laufzeit durchgesetzt - nichts zwingt sie, mit dem Code synchron zu bleiben. Wenn du refaktorisierst oder Features hinzufügst, wird der Docstring möglicherweise nicht aktualisiert, sodass du eine Dokumentation hast, die über das tatsächliche Verhalten lügt. Deshalb empfiehlt die Vorlesung, Anforderungen wenn möglich im Typsystem zu kodieren und Tests als ausführbare Dokumentation zu verwenden.

Durch die Erstellung einer Angle-Klasse, die Werte bei der Konstruktion auf [0, 360) normalisiert, wird die Anforderung “Winkel muss im gültigen Bereich sein” unmöglich zu verletzen. Angle(500) wird automatisch zu Angle(140). Dies ist besser als ein Kommentar, der sagt “Winkel sollte 0-360 sein”, weil das Typsystem es durchsetzt - du kannst keinen ungültigen Winkel darstellen. Dies ist das Prinzip “ungültige Zustände undarstellbar machen”.

Stakeholder umfassen alle, die vom System betroffen sind, was typischerweise Endbenutzer, Kunden/Käufer, Entwickler, Operations-Teams, Geschäftsrollen (Product Manager, Marketing, Support) und sogar Regulierungsbehörden einschließt. Dieselbe Funktion sieht für verschiedene Stakeholder unterschiedlich aus - eine Schnittpunktberechnung ist ein Messwerkzeug für den Ingenieur, eine Kosteneinsparung für den Manager, ein Algorithmus für den Entwickler und ein zu verifizierendes Verhalten für QA.

Option B illustriert einen echten Konflikt: Etwas “in unter 1 Stunde erlernbar” zu machen, könnte eine einfachere Oberfläche mit weniger Optionen bevorzugen, während “modulare Architektur für Tests” Komplexität hinzufügen könnte, die die Lernzeit erhöht. Dies sind konkurrierende Anforderungen aus verschiedenen Stakeholder-Perspektiven, die ausbalanciert werden müssen. Option A beschreibt komplementäre Wünsche (kein Konflikt), C zeigt Übereinstimmung, und D ist zu vage, um eine echte Anforderung zu sein.

Das “T” in INVEST steht für Testable (Testbar), welches das Kriterium ist, das am direktesten mit der Verifikation verbunden ist. Wenn du keinen Test für eine Anforderung schreiben kannst, kannst du nicht objektiv feststellen, ob sie erfüllt ist. Dies verbindet sich direkt mit der Kernbotschaft der Vorlesung: vage Anforderungen wie “benutzerfreundlich” müssen in testbare Kriterien wie “Reaktionszeit < 200ms” verfeinert werden, bevor sie für Entwicklung und Verifikation nützlich sind.

Option C liefert spezifische, messbare Kriterien: einen definierten Benutzertyp (neuer Benutzer), eine definierte Aufgabe (Kern-Workflow), ein messbares Ergebnis (innerhalb von 5 Minuten) und Bedingungen (ohne Training). Dafür kann man einen Test schreiben! Optionen A, B und D bleiben vage und subjektiv - “sehr benutzerfreundlich”, “benutzerfreundlicher als Konkurrenten” und “Freude” sind ohne weitere Verfeinerung nicht objektiv messbar.

Abgeleitete Anforderungen (auch Child-Anforderungen genannt) sind Anforderungen, die aus Implementierungsentscheidungen entstehen. Wenn du dich entscheidest, Ray-Casting zu verwenden und None für vertikale Strahlen zurückzugeben, wird das zu einer abgeleiteten Anforderung (REQ-GEOM-001), die deine Unit-Tests verifizieren müssen. Der Stakeholder hat dieses Verhalten nicht spezifisch verlangt - es wurde von deiner technischen Designentscheidung abgeleitet. ISO/IEC/IEEE 29148 definiert diesen Begriff formell.

Stakeholder-Anforderungen wie “laden und berechnen in unter 2 Sekunden” sind Systemanforderungen, die Datei-I/O, Zustandsverwaltung und Berechnung umfassen. Der Stakeholder kümmert sich nicht um einzelne Funktionen - er kümmert sich um die gesamte Erfahrung. Unit-Tests verifizieren abgeleitete Anforderungen (Implementierungsdetails wie “vertikale Strahlen geben None zurück”), während Modul-/E2E-Tests die Stakeholder-Anforderungen verifizieren. Deshalb hat die Pyramide wenige Integrationstests und viele Unit-Tests.

Das User Story Format “Als [Rolle] möchte ich [Feature], damit [Nutzen]” erfasst WER es braucht (Stakeholder), WAS sie brauchen (das Feature, nicht die Lösung), und WARUM (den Wert, den es liefert). Option A ist eher wie eine traditionelle Anforderungsspezifikation, Option C ist das Given-When-Then Format für Akzeptanzkriterien (nicht die Story selbst), und Option D ist nur ein Feature-Label.

Akzeptanzkriterien verwandeln vage User Stories in testbare Spezifikationen. Das Given-When-Then Format spezifiziert exakte Szenarien: Ausgangszustand, Aktion und erwartetes Ergebnis. Diese können sogar als automatisierte Tests mit Tools wie pytest-bdd ausgeführt werden. Sie sind nicht optional (D) - ohne Akzeptanzkriterien kann man nicht objektiv feststellen, ob eine Story abgeschlossen ist. Sie spezifizieren keine Implementierung (B) - nur Verhalten.