Home

04 Quiz: Requirements Engineering - Prozess & Praxis

December 2025 (2560 Words, 15 Minutes)

quiz chapter-04 requirements elicitation change-management waterfall v-model agile poc

Neu: Interaktives Quiz verfügbar!

Möchten Sie Ihren Fortschritt verfolgen und sofortiges Feedback erhalten? Probieren Sie unsere neue interaktive Version mit Fortschrittsverfolgung, sofortigen Erklärungen und Punkteberechnung.

Interaktives Quiz starten →

Anleitung

Dieses Quiz testet Ihr Verständnis der Kernkonzepte aus Kapitel 04 Teil 2 (Requirements Engineering: Vom Prozess zur Praxis)
Jede Frage hat 4 Optionen mit genau einer richtigen Antwort
Versuchen Sie zu antworten, ohne in den Vorlesungsmaterialien nachzuschlagen
Konzentrieren Sie sich auf das Verständnis von Konzepten, nicht auf das Auswendiglernen von Details

Frage 1: Geschäftsperspektiven

Die gleiche Anforderung “Schnittpunkt anzeigen” sieht für verschiedene Rollen unterschiedlich aus. Welche Perspektive konzentriert sich primär auf “Gibt es einen Markt dafür?”

A) Der Entwickler
B) Der Projektmanager
C) Der Produktmanager
D) Der Startup-Gründer

Antwort anzeigen

Richtige Antwort: D

Die Sichtweise des Startup-Gründers konzentriert sich auf Product-Market-Fit, Validierung und Pivotierung. Sie stellen Fragen wie “Gibt es einen Markt dafür?” und “Werden die Leute dafür bezahlen?” Der Entwickler konzentriert sich auf Implementierungsdetails, der Projektmanager auf das magische Dreieck (Umfang, Zeit, Budget) und der Produktmanager auf Wertlieferung und Priorisierung.

Frage 2: Das magische Dreieck

Ein Projektmanager muss drei konkurrierende Einschränkungen ausbalancieren. Welche Einschränkungen gehören laut dem “magischen Dreieck”-Konzept dazu?

A) Geschwindigkeit, Sicherheit und Skalierbarkeit
B) Umfang, Zeit und Budget
C) Testen, Dokumentation und Schulung
D) Features, Benutzer und Umsatz

Antwort anzeigen

Richtige Antwort: B

Das magische Dreieck besteht aus Umfang, Zeit und Budget - mit Qualität in der Mitte, die von allen drei beeinflusst wird. Der Spruch “Gut, Schnell, Günstig - wähle zwei” fasst den Kompromiss zusammen. Man kann nicht alles haben: Die Erweiterung des Umfangs bei gleichbleibender Qualität erfordert typischerweise mehr Zeit oder Budget.

Frage 3: Erhebungstechniken

Sie müssen verstehen, was Benutzer tatsächlich tun (nicht nur, was sie sagen). Welche Erhebungstechnik ist dafür am BESTEN geeignet?

A) Umfragen
B) Interviews
C) Beobachtung
D) Workshops

Antwort anzeigen

Richtige Antwort: C

Beobachtung ist am besten geeignet, um den tatsächlichen Arbeitsablauf zu verstehen im Vergleich zu dem, was Benutzer sagen. Menschen beschreiben in Interviews oft idealisierte oder vereinfachte Versionen ihrer Arbeit. Durch Beobachtung können Sie die Workarounds, Abkürzungen und Schmerzpunkte sehen, die sie möglicherweise nicht erwähnen würden. Achten Sie jedoch auf den Hawthorne-Effekt - Menschen können ihr Verhalten ändern, wenn sie beobachtet werden.

Frage 4: Gute Fragen

Welche der folgenden ist ein Beispiel für eine GUTE Erhebungsfrage?

A) “Sie möchten, dass der Button blau ist, richtig?”
B) “Ist das System schnell genug?”
C) “Was ist der frustrierendste Teil Ihres aktuellen Arbeitsablaufs?”
D) “Gefällt Ihnen das aktuelle Design?”

Antwort anzeigen

Richtige Antwort: C

Option C ist offen und explorativ und lädt den Stakeholder ein, seine Erfahrungen und Schmerzpunkte zu teilen. Die anderen Optionen sind geschlossene oder Suggestivfragen: A führt zu einer bestimmten Antwort, B kann nur mit Ja/Nein ohne Einblick beantwortet werden, und D ist subjektiv ohne verwertbare Informationen. Gute Fragen helfen, Anforderungen zu entdecken, nicht Annahmen zu bestätigen.

Frage 5: Die 5-Warum-Technik

Wenn ein Benutzer sagt “Ich brauche die Schnittpunktberechnung schneller”, hilft die 5-Warum-Technik dabei:

A) Die genaue Algorithmusoptimierung zu finden
B) Herauszufinden, wie viele Millisekunden eingespart werden müssen
C) Das zugrundeliegende Bedürfnis hinter der geäußerten Anfrage zu entdecken
D) Herauszufinden, welcher Wettbewerber schnellere Berechnungen hat

Antwort anzeigen

Richtige Antwort: C

Die 5-Warum-Technik gräbt tiefer zum wahren Bedürfnis. Durch wiederholtes Fragen “warum” könnten Sie entdecken, dass “schnellere Berechnung” nicht wirklich das ist, was sie brauchen - vielleicht brauchen sie eine Echtzeit-Feedback-Schleife für die Kameraeinstellung, die durch Vorhersage/Vorschau gelöst werden könnte, anstatt durch schnellere Berechnung. Die geäußerte Anfrage ist oft nicht die wahre Anforderung.

Frage 6: Bug vs. Änderungsanfrage - Definition

Was unterscheidet laut der Vorlesung einen BUG von einer Änderungsanfrage (Change Request)?

A) Bugs werden von Testern gefunden, Änderungsanfragen von Kunden
B) Bugs bedeuten, dass die Software dokumentierte Anforderungen nicht erfüllt; CRs fordern etwas Anderes oder Zusätzliches
C) Bugs sind immer kostenlos zu beheben, CRs sind immer kostenpflichtig
D) Bugs sind technische Probleme, CRs sind Benutzeroberflächenprobleme

Antwort anzeigen

Richtige Antwort: B

Der entscheidende Unterschied ist, ob dokumentierte Anforderungen existieren: Ein Bug bedeutet, dass die Software eine bestehende, dokumentierte Anforderung nicht erfüllt. Eine Änderungsanfrage bedeutet, dass der Stakeholder etwas Anderes oder Zusätzliches zum Spezifizierten möchte. Diese Unterscheidung hat erhebliche geschäftliche Auswirkungen - Bugs fallen typischerweise in die Verantwortung des Anbieters (Gewährleistung), während CRs kostenpflichtig sein können und Fristen verlängern.

Frage 7: Die Grauzone

Ein Kunde meldet: “Die Schnittpunktberechnung liefert falsche Ergebnisse für Winkel größer als 180 Grad.” Wenn die Anforderung “Winkel im Bereich 0-180” sagt, ist dies:

A) Definitiv ein Bug, der kostenlos behoben werden muss
B) Eine Änderungsanfrage - der Kunde möchte neue Funktionalität
C) Ein Dokumentationsfehler
D) Ein Performance-Problem

Antwort anzeigen

Richtige Antwort: B

Wenn die Anforderung explizit “Winkel im Bereich 0-180” spezifiziert, dann ist die Behandlung von Winkeln größer als 180 Grad neue Funktionalität, die nicht von der ursprünglichen Spezifikation abgedeckt ist. Das ist eine Änderungsanfrage. Wenn die Anforderung “Winkel im Bereich 0-360” gesagt hätte, wäre es ein Bug. Wenn die Anforderung zum Winkelbereich nichts sagte, wird es zu einer Grauzone, die Stakeholder-Diskussion erfordert. Klare Anforderungsdokumentation verhindert diese Streitigkeiten.

Frage 8: Warum Bug vs. CR wichtig ist

Über die Softwareentwicklung hinaus, warum ist die Unterscheidung zwischen Bug und Änderungsanfrage besonders wichtig?

A) Sie bestimmt, welcher Entwickler die Aufgabe zugewiesen bekommt
B) Sie hat rechtliche und finanzielle Auswirkungen, die zu Vertragsstreitigkeiten eskalieren können
C) Sie beeinflusst den Code-Review-Prozess
D) Sie bestimmt die Git-Branch-Namenskonvention

Antwort anzeigen

Richtige Antwort: B

Die Bug-vs-CR-Unterscheidung hat direkte finanzielle und rechtliche Konsequenzen. Anbieter könnten für “Änderungsanfragen” Gebühren erheben, wenn sie echte Bugs beheben. Kunden könnten “Bugs” reklamieren, um neue Features kostenlos zu bekommen. Unklare Anforderungen führen zu Streitigkeiten, die zu Vertragsverhandlungen oder Rechtsfällen eskalieren können. Deshalb schützt klare Anforderungsdokumentation beide Parteien.

Frage 9: POC-getriebene Anforderungen

Der Lean-Startup-Ansatz (Build-Measure-Learn) adressiert welches fundamentale Problem des traditionellen Requirements Engineering?

A) Stakeholder geben zu viele Anforderungen
B) Entwickler schreiben zu viel Dokumentation
C) Kunden wissen nicht, was sie wollen, bis sie es sehen
D) Testen dauert zu lange

Antwort anzeigen

Richtige Antwort: C

Die unbequeme Wahrheit über Anforderungen ist, dass Kunden oft nicht wissen, was sie wollen, bis sie es sehen. Traditionelles RE nimmt an, dass man Stakeholder interviewen, vollständige Anforderungen schreiben, das System bauen und liefern kann, was sie wollten. Realität: Sie beschreiben, was sie denken zu wollen, Sie bauen es, sie sagen “Eigentlich meinte ich…” Lean Startup adressiert dies durch schnelle Iteration mit MVPs.

Frage 10: MVP-Definition

Im Kontext von Lean Startup, was ist ein MVP (Minimum Viable Product)?

A) Ein voll ausgestattetes Produkt mit minimalen Bugs
B) Das Kleinste, was man bauen kann, um eine Hypothese darüber zu testen, was Benutzer wollen
C) Ein detailliertes Anforderungsdokument
D) Ein Prototyp, der technische Machbarkeit demonstriert

Antwort anzeigen

Richtige Antwort: B

MVP steht für Minimum Viable Product - das Kleinste, was man bauen kann, um seine Hypothese darüber zu testen, was Benutzer wollen. Es geht nicht darum, etwas Vollständiges mit minimalen Fehlern zu bauen (A), noch nur um technische Machbarkeit (D). Jede MVP-Iteration verfeinert Anforderungen basierend auf echtem Feedback und ersetzt Raten durch validiertes Lernen.

Frage 11: Design Thinking

Design Thinking betont “Empathize First” (Zuerst einfühlen). Was bedeutet das im Kontext der Anforderungsermittlung?

A) Mitleid mit Benutzern haben, die schwierige Jobs haben
B) Benutzer beobachten, sie interviewen und ihre Probleme erleben, bevor Lösungen definiert werden
C) Einfühlsame Fehlermeldungen schreiben
D) Die Benutzeroberfläche emotional ansprechender gestalten

Antwort anzeigen

Richtige Antwort: B

“Empathize First” bedeutet, Benutzer tiefgreifend zu verstehen, bevor man zu Lösungen springt. Dies beinhaltet, Benutzer in ihrer Umgebung zu beobachten, sie über ihre Erfahrungen zu interviewen und zu versuchen, ihre Schmerzpunkte aus erster Hand zu verstehen. Anforderungen entstehen aus diesem Verständnis, anstatt von vornherein angenommen zu werden. Der Design-Thinking-Prozess setzt sich dann mit Definieren, Ideation, Prototyping und Testen fort.

Frage 12: Gen AI und Prototyping

Wie verändert Gen-AI-unterstütztes Prototyping (“Vibe Coding”) den Anforderungsermittlungsprozess?

A) Es eliminiert die Notwendigkeit für Stakeholder-Interviews
B) Es ermöglicht schnelle Erstellung von funktionierenden Prototypen, wodurch die Anforderungsermittlung interaktiv wird
C) Es generiert automatisch perfekte Anforderungsdokumente
D) Es ersetzt die Notwendigkeit für Tests

Antwort anzeigen

Richtige Antwort: B

Gen AI ermöglicht schnelles Prototyping - was traditionell Wochen dauern könnte, kann in Stunden oder Minuten erledigt werden. Das transformiert die Anforderungsermittlung: Anstatt langer Interviews gefolgt von schriftlichen Anforderungen gefolgt vom Bauen (und oft dem Bauen des Falschen), können Sie schnelle Gespräche führen, am selben Tag funktionierende Prototypen zeigen und schnell iterieren. Anforderungen werden zu Gesprächen mit funktionierender Software als gemeinsamer Referenz.

Frage 13: Grenzen des traditionellen RE

Traditionelles Requirements Engineering (Big Upfront Requirements) funktioniert am BESTEN in welchem Szenario?

A) Hohe Unsicherheit und neuartige Produktentwicklung
B) Schnelllebige Märkte, in denen sich Anforderungen schnell ändern
C) Regulierte Umgebungen mit stabilen, gut verstandenen Anforderungen
D) Innovationskontexte, in denen Sie entdecken, nicht nur bauen

Antwort anzeigen

Richtige Antwort: C

Traditionelles RE funktioniert gut für regulierte Umgebungen (Medizin, Luftfahrt), gut verstandene Domänen mit stabilen Anforderungen, Festpreisverträge mit klar definiertem Umfang und große Systeme mit vielen Integrationspunkten. Es kämpft mit Unsicherheit, “Ich weiß es, wenn ich es sehe”-Anforderungen, schnelllebigen Märkten und Innovationskontexten, in denen POC-getriebene Ansätze überlegen sind.

Frage 14: Die Royce-Ironie

Winston Royces Aufsatz von 1970 wird oft als Ursprung des Wasserfallmodells zitiert. Was ist daran ironisch?

A) Royce hat nie wirklich an Software gearbeitet
B) Royce warnte tatsächlich vor dem rein sequentiellen Ansatz in genau diesem Aufsatz
C) Der Aufsatz handelte von Hardware, nicht von Software
D) Royce bevorzugte agile Entwicklung

Antwort anzeigen

Richtige Antwort: B

Die Ironie ist, dass Royce den grundlegenden Wasserfallansatz in seinem Aufsatz als “riskant und zum Scheitern einladend” bezeichnete. Er präsentierte ihn als warnendes Beispiel und der Rest seines Aufsatzes beschrieb iterative Verbesserungen und Feedback-Schleifen. Die Branche übernahm sein Diagramm, ignorierte aber seine Warnungen. Was als “tu das nicht” gedacht war, wurde zum Standardprozess.

Frage 15: V-Modell-Innovation

Was ist die wichtigste Innovation des V-Modells im Vergleich zum grundlegenden Wasserfallmodell?

A) Es eliminiert die Notwendigkeit für Dokumentation
B) Jede Entwicklungsphase hat eine entsprechende Testphase, wobei die Testplanung parallel erfolgt
C) Es beseitigt die sequentielle Einschränkung vollständig
D) Es konzentriert sich nur auf Unit-Tests

Antwort anzeigen

Richtige Antwort: B

Die wichtigste Innovation des V-Modells ist die Paarung jeder Entwicklungsphase (linker Arm des V) mit einer entsprechenden Testphase (rechter Arm). Entscheidend ist, dass die Testplanung parallel zur Entwicklung erfolgt - Abnahmetests werden entworfen, wenn Anforderungen geschrieben werden, nicht nach dem Coding. Das adressiert die Schwäche des Wasserfalls, Testing als Nachgedanken zu behandeln.

Frage 16: V-Modell XT

V-Modell XT ist für Softwareengineering-Studierende relevant, weil:

A) Es für alle Open-Source-Projekte erforderlich ist
B) Es für IT-Projekte der deutschen Bundesregierung vorgeschrieben ist und von vielen großen deutschen Unternehmen verwendet wird
C) Es das einfachste Entwicklungsmodell zum Lernen ist
D) Es die Notwendigkeit für Anforderungsdokumentation eliminiert

Antwort anzeigen

Richtige Antwort: B

V-Modell XT ist der vorgeschriebene Standard für IT-Projekte des deutschen Bundes - es ist nicht optional, es ist gesetzlich vorgeschrieben. Viele große deutsche Unternehmen (Siemens, Bosch, SAP) nutzen es ebenfalls oder Varianten davon. Es zu verstehen zeigt, wie regulierte Branchen Softwareentwicklung handhaben, und ist oft relevant in Vorstellungsgesprächen der deutschen Industrie.

Frage 17: Das Problem des späten Feedbacks

Alle sequentiellen Modelle (Wasserfall, V-Modell) teilen eine fundamentale Einschränkung. Welche ist das?

A) Sie benötigen zu viele Entwickler
B) Funktionierende Software erscheint erst am Ende, sodass Anforderungsfehler spät entdeckt werden
C) Sie erlauben kein Testen
D) Sie können nur für kleine Projekte verwendet werden

Antwort anzeigen

Richtige Antwort: B

Das Kernproblem sequentieller Modelle ist, dass funktionierende Software erst am Ende erscheint. Wenn Anforderungen falsch waren, entdecken Sie es Monate (oder Jahre) nachdem die Entscheidung getroffen wurde - was zu teurer Nacharbeit führt. Das V-Modell verbessert den Wasserfall durch frühere Testplanung, leidet aber immer noch unter diesem fundamentalen Problem des späten Feedbacks.

Frage 18: Kosten der Änderung

Barry Boehms Forschung zur “Änderungskostenkurve” demonstriert:

A) Alle Änderungen kosten gleich viel, unabhängig davon, wann sie gemacht werden
B) Änderungen in der Produktion sind tatsächlich günstiger, weil der Code fertig ist
C) Fehler, die spät in der Entwicklung gefunden werden, sind deutlich teurer zu beheben als früh gefundene
D) Dokumentation verhindert alle Änderungskosten

Antwort anzeigen

Richtige Antwort: C

Boehms Forschung zeigte, dass spät gefundene Fehler dramatisch teurer zu beheben sind. Ein Anforderungsfehler, der während der Anforderungsphase gefunden wird, bedeutet, ein Dokument zu ändern. Der gleiche Fehler, der in der Produktion gefunden wird, bedeutet: Anforderungen ändern, Design-Dokumente aktualisieren, Code neu schreiben, Tests erneut durchführen, neu deployen, Kundenauswirkungen handhaben und möglicherweise Datenmigration. Die genauen Verhältnisse werden diskutiert, aber das Prinzip ist robust: Späte Änderungen kosten mehr.

Frage 19: Annahmen sequentieller Modelle

Sequentielle Modelle nehmen an, dass wir “alle Anforderungen im Voraus kennen können”. Die Realität widerspricht dem, weil:

A) Anforderungsdokumente zu lang zum Lesen sind
B) Benutzer nicht wissen, was sie wollen, bis sie funktionierende Software sehen
C) Entwickler sich weigern, Anforderungen zu lesen
D) Anforderungswerkzeuge zu teuer sind

Antwort anzeigen

Richtige Antwort: B

Benutzer können ihre Bedürfnisse oft nicht vollständig artikulieren, bis sie mit etwas Konkretem interagieren. Das ist kein Versagen - es ist menschliche Natur. Designentscheidungen brauchen auch Feedback aus der Implementierung. Software wird durch Iteration gelernt, nicht wie physische Produkte hergestellt. Sequentielle Modelle nehmen Stabilität an, aber Softwareentwicklung ist von Natur aus unsicher.

Frage 20: Die agile Antwort

Laut der Agile-Manifesto-Vorschau, was ist die agile Antwort auf ständige Anforderungsänderungen?

A) Detailliertere Dokumentation erstellen, um Änderungen zu verhindern
B) Anforderungen am Anfang einfrieren und alle Änderungen ablehnen
C) Änderungen als unvermeidlich akzeptieren, schnell iterieren und früh Wert liefern
D) Mehr Projektmanager einstellen, um den Prozess zu kontrollieren

Antwort anzeigen

Richtige Antwort: C

Während die traditionelle Antwort auf Änderungen “mehr Planung, mehr Dokumentation, Änderungskontrolle” ist, ist die agile Antwort, Änderungen als unvermeidlich zu akzeptieren. Das bedeutet schnelles Iterieren (Sprints), frühe Wertlieferung (funktionierende Software über umfassende Dokumentation) und Zusammenarbeit mit Kunden anstatt starrer Vertragsverhandlung. Anforderungen werden zu lebenden Artefakten, die durch häufiges Feedback verfeinert werden.

Bewertungsleitfaden

18-20 richtig: Ausgezeichnet! Sie haben ein starkes Verständnis der Anforderungsprozesse, von der Erhebung über das Änderungsmanagement bis zu den Entwicklungsmodellen
14-17 richtig: Gutes Verständnis! Wiederholen Sie die Bereiche, die Sie verpasst haben, insbesondere die Unterscheidungen zwischen den Ansätzen
10-13 richtig: Ausreichendes Verständnis. Besuchen Sie die Vorlesungsabschnitte zu Erhebungstechniken, Bug vs. CR und Kompromissen bei Entwicklungsmodellen erneut
Unter 10: Bitte wiederholen Sie die Vorlesung sorgfältig. Konzentrieren Sie sich darauf zu verstehen, warum verschiedene Ansätze existieren und wann jeder angemessen ist. Melden Sie sich, wenn Sie Klärung benötigen!

Wichtige Erkenntnisse zum Merken

Verschiedene Rollen, verschiedene Sichtweisen - Die gleiche Anforderung sieht für Entwickler, PMs, Produktmanager und Gründer unterschiedlich aus
Magisches Dreieck - Umfang, Zeit, Budget (wähle zwei) mit Qualität in der Mitte
Beobachtung übertrifft Fragen - Schauen Sie, was Benutzer tun, nicht nur, was sie sagen
Offene Fragen stellen - “Was ist frustrierend?” ist besser als “Sie wollen es blau, richtig?”
5 Warums enthüllen wahre Bedürfnisse - Die geäußerte Anfrage ist oft nicht die wahre Anforderung
Bug vs. CR hat rechtliches Gewicht - Klare Dokumentation verhindert teure Streitigkeiten
Kunden wissen es nicht, bis sie es sehen - Bauen zum Lernen, nicht nur zum Liefern
MVP testet Hypothesen - Das Kleinste, das Ihre Annahme validiert
Royce warnte uns - Der “Vater des Wasserfalls” warnte tatsächlich davor
V-Modell paart Entwicklung mit Test - Tests planen, wenn Sie Anforderungen schreiben, nicht nach dem Coding
Späte Änderungen kosten mehr - Boehms Prinzip: Fehler früh finden
Agile akzeptiert Änderungen - Kämpfe nicht gegen Unsicherheit, arbeite damit

Denken Sie daran: Requirements Engineering geht nicht nur um das Schreiben von Dokumenten - es geht darum, durch Gespräche, Prototyping und Iteration zu entdecken, was gebaut werden soll. Die beste Anforderung ist eine, die es Ihnen ermöglicht, beim ersten Mal das Richtige zu bauen, oder die Ihnen hilft, schneller zu lernen, wenn Sie es nicht tun!