04 Quiz: Requirements Engineering
December 2025 (1745 Words, 10 Minutes)
Neu: Interaktives Quiz verfügbar!
Möchtest du deinen Fortschritt verfolgen und sofortiges Feedback erhalten? Probiere unsere neue interaktive Version mit Fortschrittsverfolgung, sofortigen Erklärungen und Punkteberechnung.
Anleitung
- Dieses Quiz testet dein Verständnis der Schlüsselkonzepte aus Kapitel 04 (Von Tests zu Spezifikationen)
- Jede Frage hat 4 Optionen mit genau einer richtigen Antwort
- Versuche zu antworten, ohne in den Vorlesungsmaterialien nachzuschauen
- Konzentriere dich auf das Verständnis der Konzepte, nicht auf das Auswendiglernen von Details
Frage 1: Das Kernproblem
In Kapitel 04 (Requirements Engineering) haben wir entdeckt, dass Coverage-Lücken in Tests oft etwas Grundlegenderes offenbaren. Was zeigen Coverage-Lücken typischerweise an?
A) Der Code ist zu komplex und muss refaktorisiert werden
B) Requirements-Lücken - man kann keine guten Tests schreiben, wenn man nicht weiß, was die Software tun soll
C) Das Testing-Framework ist falsch konfiguriert
D) Die Entwickler sind faul und haben nicht genug Tests geschrieben
Antwort anzeigen
Richtige Antwort: B
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.
Frage 2: Funktionale vs. Nicht-Funktionale Anforderungen
Welche der folgenden ist eine NICHT-FUNKTIONALE Anforderung für einen Road Profile Viewer?
A) “Das System soll Straßenprofildaten aus CSV-Dateien laden”
B) “Das System soll das Straßenprofil als 2D-Liniendiagramm anzeigen”
C) “Die UI soll innerhalb von 100ms nach Benutzereingabe aktualisiert werden”
D) “Das System soll den Schnittpunkt berechnen und hervorheben”
Antwort anzeigen
Richtige Antwort: C
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.
Frage 3: Das Problem mit Kommentaren
Die Vorlesung argumentiert gegen die Verwendung von Kommentaren/Docstrings als primäre Methode zur Dokumentation von Design by Contract Anforderungen. Was ist das HAUPTPROBLEM bei diesem Ansatz?
A) Kommentare benötigen zu viel Speicherplatz
B) Kommentare können veralten und über das tatsächliche Code-Verhalten lügen
C) Kommentare sind in der IDE nicht sichtbar
D) Kommentare verlangsamen die Code-Ausführung
Antwort anzeigen
Richtige Antwort: B
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.
Frage 4: Typsystem als Anforderungsdurchsetzung
Wie hilft die Verwendung einer Angle-Klasse anstelle eines rohen float für angle_degrees bei der Durchsetzung von Anforderungen?
A) Es macht den Code durch Compiler-Optimierungen schneller
B) Es kodiert die gültige Bereichsbeschränkung direkt im Typ, was es unmöglich macht, sie zu verletzen
C) Es erlaubt dem Winkel, jeden beliebigen Wert anzunehmen ohne Einschränkungen
D) Es macht jegliches Testen überflüssig
Antwort anzeigen
Richtige Antwort: B
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”.
Frage 5: Stakeholder-Definition
Wer gilt laut Vorlesung als Stakeholder?
A) Nur die Personen, die für die Software bezahlen
B) Nur die Endbenutzer, die täglich mit dem System interagieren
C) Jede Person oder Organisation, die ein Interesse an dem System hat oder davon betroffen ist
D) Nur das Entwicklungsteam, das die Software erstellt
Antwort anzeigen
Richtige Antwort: C
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.
Frage 6: Stakeholder-Konflikte
Der Road Profile Viewer hat verschiedene Stakeholder mit potenziell widersprüchlichen Anforderungen. Welches Szenario illustriert einen Stakeholder-Konflikt am besten?
A) Der Straßeningenieur will genaue Messungen UND schnelle Berechnungen
B) Der Lab-Manager will “in unter 1 Stunde erlernbar”, aber der Entwickler will “modulare Architektur für Tests”
C) Der IT-Admin und der Sicherheitsbeauftragte wollen beide Dokumentation
D) Alle Stakeholder sind sich einig, dass das System korrekt funktionieren soll
Antwort anzeigen
Richtige Antwort: B
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.
Frage 7: Die INVEST-Kriterien
Welches INVEST-Kriterium ist am direktesten mit unserer Fähigkeit verbunden zu verifizieren, dass eine Anforderung erfüllt ist?
A) Independent - kann ohne Abhängigkeit von anderen Stories implementiert werden
B) Negotiable - Details können diskutiert werden
C) Testable - hat klare Kriterien für “fertig”
D) Small - kann in einem Sprint abgeschlossen werden
Antwort anzeigen
Richtige Antwort: C
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.
Frage 8: Testbare Anforderungen
“Das System sollte benutzerfreundlich sein” gilt als schlechte Anforderung. Welche der folgenden wäre eine testbare Verfeinerung?
A) “Das System sollte sehr benutzerfreundlich sein”
B) “Das System sollte benutzerfreundlicher als Konkurrenten sein”
C) “Ein neuer Benutzer soll den Kern-Workflow innerhalb von 5 Minuten ohne Training abschließen können”
D) “Benutzer sollen Freude an der Nutzung des Systems haben”
Antwort anzeigen
Richtige Antwort: C
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.
Frage 9: Implementierungsentscheidungen
Bei der Implementierung einer Stakeholder-Anforderung wie “Berechne Schnittpunkt” treffen Entwickler Designentscheidungen, die neue Anforderungen erzeugen. Wie werden diese genannt?
A) Versteckte Anforderungen
B) Abgeleitete Anforderungen
C) Optionale Anforderungen
D) Legacy-Anforderungen
Antwort anzeigen
Richtige Antwort: B
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.
Frage 10: Testpyramide und Anforderungen
Warum werden Stakeholder-Anforderungen typischerweise auf Modul-/E2E-Ebene getestet statt mit Unit-Tests?
A) Unit-Tests sind zu schnell, um Stakeholder-Anforderungen zu testen
B) Stakeholder-Anforderungen erstrecken sich über mehrere Komponenten und betreffen das beobachtbare Systemverhalten
C) Unit-Tests können nur nicht-funktionale Anforderungen testen
D) Modul-/E2E-Tests sind günstiger zu schreiben als Unit-Tests
Antwort anzeigen
Richtige Antwort: B
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.
Frage 11: User Story Format
Was ist das korrekte Format für eine User Story?
A) “Das System soll [etwas tun] wenn [Bedingung] mit [Parametern]”
B) “Als [Rolle] möchte ich [Feature], damit [Nutzen]”
C) “Gegeben [Kontext], Wenn [Aktion], Dann [Ergebnis]”
D) “Feature [Name]: Beschreibung der Funktionalität”
Antwort anzeigen
Richtige Antwort: B
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.
Frage 12: Zweck der Akzeptanzkriterien
Welche Rolle spielen Akzeptanzkriterien (Given-When-Then) im Requirements Engineering?
A) Sie ersetzen den Bedarf an jeglicher anderer Dokumentation
B) Sie spezifizieren die genaue Code-Implementierung
C) Sie definieren spezifische, testbare Bedingungen, die für eine User Story als “fertig” erfüllt sein müssen
D) Sie sind optionale Verzierungen für User Stories
Antwort anzeigen
Richtige Antwort: C
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.
Bewertungsübersicht
- 11-12 richtig: Ausgezeichnet! Du hast ein starkes Verständnis der Requirements Engineering Konzepte und ihrer Verbindung zum Testen
- 8-10 richtig: Gutes Verständnis! Wiederhole die Bereiche, die du verpasst hast, besonders die Verbindungen zwischen Anforderungen, Stakeholdern und Testen
- 5-7 richtig: Solides Verständnis. Wiederhole die Vorlesungsabschnitte zu INVEST-Kriterien, abgeleiteten Anforderungen und der Testpyramide
- Unter 5: Bitte wiederhole die Vorlesung sorgfältig. Konzentriere dich darauf zu verstehen, warum Requirements Engineering wichtig ist und wie es sich mit den Testkonzepten aus vorherigen Vorlesungen verbindet. Melde dich, wenn du Klärung brauchst!
Wichtige Erkenntnisse zum Merken
- Coverage-Lücken = Anforderungslücken - Wenn du keine Tests schreiben kannst, weißt du oft nicht, was die Software tun soll
- Funktional vs. Nicht-Funktional - FR beschreibt was das System tut, NFR beschreibt wie gut es das tut
- Kommentare lügen - Dokumentiere Anforderungen im Typsystem oder in Tests, nicht nur in Kommentaren, die veralten können
- Typsystem-Durchsetzung - Bessere Datentypen können ungültige Zustände unmöglich darstellbar machen
- Stakeholder sind alle Betroffenen - Nicht nur Benutzer und Kunden, sondern auch Entwickler, Ops, Regulierungsbehörden und mehr
- Stakeholder-Konflikte sind normal - Verschiedene Perspektiven führen zu konkurrierenden Anforderungen, die ausbalanciert werden müssen
- Testbar ist kritisch - Wenn du keinen Test dafür schreiben kannst, ist es keine gute Anforderung (das T in INVEST)
- Abgeleitete Anforderungen - Implementierungsentscheidungen erzeugen neue Anforderungen, die Unit-Tests verifizieren
- Pyramide macht Sinn - Stakeholder-Anforderungen → Modul-/E2E-Tests; Abgeleitete Anforderungen → Unit-Tests
- Nachverfolgbarkeit ist bidirektional - Du solltest von Anforderung zu Test UND von Test zu Anforderung zurückverfolgen können
Denke daran: Requirements Engineering ist keine Bürokratie - es geht darum zu wissen, was du baust, bevor du versuchst zu verifizieren, dass es funktioniert. Die Konzepte aus dieser Vorlesung erklären, warum wir die Tests schreiben, die wir schreiben, und warum 100% Code Coverage nicht bedeutet, dass deine Software korrekt ist!