04 Requirements Engineering: Vom Prozess zur Praxis

December 2025 (3864 Words, 22 Minutes)

1. Einführung: Von Dokumentation zu Entdeckung

Wo wir aufgehört haben:

In Teil 1 haben Sie gelernt:

• Was Anforderungen sind (funktional vs. nicht-funktional)
• Wer sich dafür interessiert (Stakeholder)
• Was sie gut macht (INVEST, Testbarkeit)
• Wie man sie dokumentiert (User Stories, GitHub Issues)
• Wie man sie mit Tests verknüpft (Traceability)

Aber wir haben die schwierigeren Fragen noch nicht beantwortet:

• Wie passen Anforderungen in den Entwicklungs-Workflow?
• Wie entdeckt man eigentlich, was Stakeholder brauchen?
• Was passiert, wenn sich Anforderungen mitten im Projekt ändern?
• Gibt es einen besseren Weg als “alles vorher aufschreiben”?

Heutiger Fokus: Der Prozess des Requirements Engineering - von der Erhebung bis zum Änderungsmanagement, und warum Agile als Antwort auf Anforderungsunsicherheit entstanden ist.

2. Lernziele

Am Ende dieser Vorlesung werden Sie:

1. Anforderungen aus verschiedenen Perspektiven sehen (Entwickler, PM, Produktmanager, Gründer)
2. Erhebungstechniken anwenden, um Anforderungen durch Stakeholder-Interviews zu entdecken
3. Bugs von Change Requests unterscheiden und verstehen, warum das wichtig ist
4. POC-getriebene Ansätze nutzen, um Anforderungen durch Prototyping zu entdecken
5. Traditionelle Entwicklungsmodelle verstehen (Wasserfall, V-Modell, V-Modell XT) und ihre Grenzen
6. Erkennen, warum V-Modell XT wichtig ist für deutsche Behörden- und regulierte Industrieprojekte
7. Agile Methodik als Vorschau als Antwort auf Anforderungsunsicherheit

Verbindung zu Teil 1: Diese Fähigkeiten bauen auf der Dokumentation und den Qualitätskriterien aus Teil 1 auf. Man kann Anforderungen nicht gut erheben, wenn man nicht weiß, was eine gute Anforderung ausmacht.

3. Über den Entwickler hinaus: Business-Perspektiven

Verschiedene Rollen stellen unterschiedliche Fragen zu Anforderungen.

3.1 Die Sicht des Entwicklers

Fragen:

• Was genau soll diese Funktion tun?
• Was sind die Randfälle?
• Wie teste ich das?

Fokus: Präzision, Testbarkeit, Implementierungsdetails

3.2 Die Sicht des Projektmanagers

Fragen:

• Wie lange wird das dauern?
• Was ist die Priorität?
• Was ist der Umfang?

Fokus: Das magische Dreieck:

graph TD
    Scope --- Time
    Time --- Budget
    Budget --- Scope

    Quality((Quality))

    Scope -.-> Quality
    Time -.-> Quality
    Budget -.-> Quality

“Gut, Schnell, Günstig - wähle zwei.”

3.3 Die Sicht des Produktmanagers

Fragen:

• Liefert das Mehrwert für die Nutzer?
• Was ist das Minimum, das wir bauen können, um die Hypothese zu testen?
• Was sollten wir als nächstes bauen?

Fokus: Wertlieferung, Nutzerbedürfnisse, Priorisierung

3.4 Die Sicht des Startup-Gründers

Fragen:

• Gibt es einen Markt dafür?
• Werden Leute dafür bezahlen?
• Lösen wir ein echtes Problem?

Fokus: Product-Market Fit, Validierung, Pivoting

Wichtige Erkenntnis: Dieselbe “Anforderung” sieht auf jeder Ebene anders aus:

“Schnittpunkt anzeigen”

• Entwickler: Algorithmus, Datenstrukturen, UI-Komponente
• PM: 2 Tage Aufwand, abhängig von Chart-Bibliothek
• Produktmanager: Ermöglicht Kern-Workflow, hohe Priorität
• Gründer: Teil unseres Wertangebots, Differenzierung von Wettbewerbern

4. Anforderungen erheben: Wie man Stakeholder interviewt

Anforderungen schreiben sich nicht von selbst. Jemand muss sie durch Gespräche mit Stakeholdern entdecken.

4.1 Techniken zur Anforderungserhebung

4.2 Gute Fragen vs. Schlechte Fragen

Schlechte Fragen (suggestiv, geschlossen):

• “Sie wollen den Button blau, richtig?”
• “Ist das System schnell genug?”
• “Gefällt Ihnen das aktuelle Design?”

Gute Fragen (offen, explorativ):

• “Führen Sie mich durch, wie Sie diese Aufgabe aktuell erledigen.”
• “Was ist der frustrierendste Teil Ihres aktuellen Workflows?”
• “Wie würde Erfolg für dieses Feature aussehen?”
• “Was passiert, wenn diese Berechnung falsch ist?”

4.3 Die 5-Warum-Technik

Wenn Sie eine Anforderung hören, graben Sie tiefer:

Nutzer: “Die Schnittpunktberechnung muss schneller sein.”

Warum? “Weil ich zu lange warte.”

Warum ist Warten ein Problem? “Weil ich 50 Profile pro Tag verarbeiten muss.”

Warum 50 pro Tag? “So viele Straßensegmente vermessen wir.”

Warum nicht stapelweise? “Ich brauche die Ergebnisse vor der nächsten Messung.”

Warum sofort? “Um den Kamerawinkel für das nächste Segment anzupassen.”

Echte entdeckte Anforderung: Nicht “schnellere Berechnung” sondern “Echtzeit-Feedback-Schleife für Kameraanpassung.”

Lösung könnte sein: Vorhersage/Vorschau, nicht schnellere Berechnung.

5. Change Request vs. Bug Fix: Eine kritische Unterscheidung

Das scheint ein technisches Detail zu sein, ist aber tatsächlich eine geschäftskritische Entscheidung.

5.1 Definitionen

Bug:

Die Software erfüllt eine bestehende, dokumentierte Anforderung nicht.

Change Request (CR):

Der Stakeholder möchte, dass die Software etwas anderes oder zusätzliches zu bestehenden Anforderungen tut.

5.2 Warum das wichtig ist

5.3 Die Grauzone

Kunde sagt: “Der Schnittpunkt ist falsch!”

Ist es ein Bug oder CR?

graph TD
    A[Kunde meldet Problem] --> B{Ist erwartetes Verhalten dokumentiert?}
    B -->|Ja| C{Entspricht Software der Dokumentation?}
    B -->|Nein| D[Grauzone - mit Stakeholder besprechen]
    C -->|Ja| E[Change Request - Software funktioniert wie spezifiziert]
    C -->|Nein| F[Bug - Software entspricht nicht Spezifikation]
    D --> G{War Verhalten durch Kontext impliziert?}
    G -->|Ja| H[Wahrscheinlich ein Bug]
    G -->|Nein| I[Wahrscheinlich ein CR]

Echtes Beispiel:

“Die Schnittpunktberechnung liefert falsche Ergebnisse für Winkel größer als 180°.”

• Wenn die Anforderung sagt “Winkel im Bereich 0-360”: Bug (sollte 180+ verarbeiten)
• Wenn die Anforderung sagt “Winkel im Bereich 0-180”: Change Request (neue Fähigkeit)
• Wenn die Anforderung nichts spezifiziert: Diskussion nötig

Wichtige Erkenntnis: Gute Anforderungsdokumentation verhindert diese Streitigkeiten.

Warnung: Über die Softwareentwicklung hinaus

Diese Unterscheidung ist nicht nur eine technische Angelegenheit—sie kann rechtliche und finanzielle Konsequenzen haben, die weit über den Bereich der Softwareentwicklung hinausgehen. In realen Projekten eskalieren Bug- vs. Change-Request-Streitigkeiten oft zu Vertragsverhandlungen, rechtlichen Diskussionen oder sogar Gerichtsverfahren.

Reale Szenarien, die Sie kennen sollten:

• Ein Kunde erhält Software, die bei normaler Nutzung abstürzt. Der Anbieter behauptet: “Die Anforderungen haben keine Stabilität spezifiziert.” → Rechtsstreit
• Ein Anbieter liefert genau das, was spezifiziert war, aber der Kunde erwartete mehr. Der Kunde behauptet: “Das ist offensichtlich kaputt.” → Vertragsverhandlung
• Unklare Anforderungen führen zu monatelangen “Ist es ein Bug?”-Diskussionen, die das Projekt verzögern → Scope Creep und Kostenüberschreitungen

Was das für Sie als Student bedeutet:

• Requirements Engineering hat direkte finanzielle und rechtliche Auswirkungen
• Wenn Sie Anforderungen schreiben oder prüfen, denken Sie: “Würde das einem Vertragsstreit standhalten?”
• Dieses Thema überschneidet sich mit Wirtschaftsrecht und Vertragsmanagement—Bereiche außerhalb unseres Rahmens, aber welche Sie in der Berufspraxis antreffen werden

Fazit: Je klarer Ihre Anforderungsdokumentation, desto weniger Streitigkeiten entstehen. Wenn Streitigkeiten auftreten, schützt gute Dokumentation beide Parteien.

6. POC-getriebene Anforderungen: Bauen um zu Lernen

Hier ist die unbequeme Wahrheit über Anforderungen:

Kunden wissen nicht, was sie wollen, bis sie es sehen.

Das ist kein Versagen - das ist menschliche Natur. Anforderungen entstehen durch Interaktion mit greifbaren Artefakten.

6.1 Das Problem mit umfangreichen Vorab-Anforderungen

Traditionelles RE nimmt an, dass man:

1. Stakeholder interviewen kann
2. Vollständige Anforderungen schreiben kann
3. Das System bauen kann
4. Das liefern kann, was sie wollten

Realität:

1. Stakeholder beschreiben, was sie denken, dass sie wollen
2. Sie bauen es
3. Sie sehen es und sagen “Eigentlich meinte ich…”
4. Teure Nacharbeit

6.2 Lean Startup: Build-Measure-Learn

Der Lean Startup Ansatz (Eric Ries) dreht den Prozess um:

graph LR
    A[Idea] --> B[Build MVP]
    B --> C[Measure]
    C --> D[Learn]
    D --> A

MVP = Minimum Viable Product: Das Kleinste, was Sie bauen können, um Ihre Hypothese über Nutzerwünsche zu testen.

Beispiel für Road Profile Viewer:

Statt das vollständige System zu bauen:

1. MVP 1: Kommandozeilen-Skript, das Schnittpunkt berechnet → Nutzer zeigen
2. MVP 2: Einfacher Plot mit hartcodierten Daten → “Ist das, was Sie brauchen?”
3. MVP 3: Interaktiver Winkelwähler → “Funktioniert dieser Workflow?”

Jede Iteration verfeinert Anforderungen basierend auf echtem Feedback.

6.3 Design Thinking: Erst Empathie

Design Thinking (IDEO, Stanford d.school) betont das Verstehen der Nutzer vor dem Definieren von Lösungen:

Empathize → Define → Ideate → Prototype → Test
     ↑_____________________________________|

Wichtige Aktivitäten:

• Empathize: Nutzer beobachten, interviewen, ihre Schmerzen erleben
• Define: Beobachtungen zu Problemstellungen synthetisieren
• Ideate: Viele mögliche Lösungen generieren
• Prototype: Schnelle, günstige, wegwerfbare Prototypen bauen
• Test: Feedback einholen, Verständnis verfeinern

Anforderungen entstehen aus diesem Prozess - sie sind keine Eingaben dafür.

6.4 Moderner Ansatz: Gen AI für Rapid Prototyping

Hier wird es für moderne Entwickler spannend:

Traditionelles Prototyping:

• Prototyp bauen: 2-4 Wochen
• Kunde zeigen, Feedback holen
• Iterieren

Gen AI-unterstütztes Prototyping (“Vibe Coding”):

• Beschreiben, was Sie einem KI-Assistenten wollen
• Funktionierenden Prototyp in Stunden (oder Minuten) bekommen
• Kunde am selben Tag zeigen
• Schnell iterieren

Beispiel-Workflow:

Entwickler: "Erstelle eine einfache Python GUI, die eine CSV mit Straßenpunkten
           lädt und als Liniendiagramm anzeigt. Füge einen Schieberegler für Winkel hinzu."

[KI generiert funktionierenden Code in 10 Minuten]

Entwickler: *Zeigt dem Straßenbauingenieur*

Ingenieur: "Das ist interessant, aber ich muss auch die Kameraposition sehen.
          Und kann der Schnittpunkt blinken wenn er sich aktualisiert?"

Entwickler: "Füge Kamerapositionsmarker und blinkenden Schnittpunkt zum Code hinzu."

[KI aktualisiert Code in 5 Minuten]

Entwickler: *Zeigt aktualisierte Version*

Ingenieur: "Ja! Aber eigentlich muss ich zwei Profile nebeneinander
          vergleichen können..."

Die Erkenntnis: KI ermöglicht so schnelle POCs, dass Anforderungsentdeckung interaktiv wird.

Statt:

1. Langes Interview → Geschriebene Anforderungen → Bauen → Falsches Ding

Bekommen Sie:

1. Kurzes Gespräch → Funktionierender Prototyp → Sofortiges Feedback → Verfeinerter Prototyp → Echte Anforderungen entstehen

Anforderungen werden zu Gesprächen mit funktionierender Software als gemeinsame Referenz.

6.5 Wann traditionelles RE versagt

POC-getriebene Ansätze sind besonders wertvoll wenn:

• Hohe Unsicherheit: Sie bauen etwas Neuartiges
• Stakeholder können Bedürfnisse nicht artikulieren: “Ich erkenne es, wenn ich es sehe”
• Schnelllebiger Markt: Anforderungen ändern sich bevor Sie sie dokumentieren können
• Innovationskontext: Sie entdecken, nicht nur bauen

Traditionelles RE funktioniert noch für:

• Regulierte Umgebungen (Medizin, Luftfahrt)
• Gut verstandene Domänen mit stabilen Anforderungen
• Große Systeme mit vielen Integrationspunkten
• Vertragsbasierte Entwicklung mit festem Umfang

7. Traditionelle Entwicklungsmodelle

Bevor wir in Agile eintauchen, müssen wir verstehen, was davor kam. Traditionelle Entwicklungsmodelle dominierten die Softwareentwicklung jahrzehntelang, und viele Organisationen—besonders in regulierten Branchen—nutzen sie heute noch. Das Verstehen dieser Modelle hilft Ihnen zu würdigen, warum Agile entstand und wann traditionelle Ansätze noch angemessen sein könnten.

7.1 Das Wasserfallmodell: Ursprünge und Struktur

Das Wasserfallmodell ist der Großvater aller Software-Entwicklungsmethodologien.

Geschichte:

• 1956: Herbert Benington präsentierte die erste Beschreibung sequentieller Phasen auf einem Symposium für fortgeschrittene Programmiermethoden
• 1970: Winston Royce veröffentlichte “Managing the Development of Large Software Systems”—das Papier, das am häufigsten als Ursprung des Wasserfalls zitiert wird
• 1976: Thomas Bell und T.A. Thayer prägten den Begriff “Wasserfall” in ihrem Paper über Softwareanforderungen

Jede Phase “fließt” in die nächste wie Wasser, das einen Wasserfall hinunterstürzt—daher der Name. Sobald Sie eine Phase passiert haben, ist es schwierig und teuer, stromaufwärts zurückzugehen.

Die Royce-Ironie:

Hier ist ein faszinierendes historisches Detail: Winston Royce, dessen 1970er Paper universell als Ursprung des Wasserfallmodells zitiert wird, warnte tatsächlich vor dem rein sequentiellen Ansatz. In seinem Paper nannte er den einfachen Wasserfall “riskant und zum Scheitern einladend.” Der Rest seines Papers beschrieb iterative Verbesserungen und Feedback-Schleifen.

Die Industrie übernahm sein Diagramm, ignorierte aber seine Warnungen. Royces “warnendes Beispiel” wurde zum Standardprozess.

Charakteristiken:

• Sequentielle Phasen: Jede Phase muss abgeschlossen sein, bevor die nächste beginnt
• Phase Gates: Formale Reviews und Freigaben zwischen Phasen
• Umfangreiche Dokumentation: Vollständige Dokumentation in jeder Phase
• Big Design Up Front (BDUF): Alle Anforderungen und Design vor dem Codieren abgeschlossen
• Änderungen sind teuer: Späte Änderungen erfordern das Zurückgehen zu früheren Phasen

Wo Wasserfall funktioniert:

Trotz seiner Einschränkungen kann Wasserfall angemessen sein für:

• Projekte mit stabilen, gut verstandenen Anforderungen
• Regulierte Umgebungen, die Dokumentationsspuren erfordern
• Festpreisverträge mit klar definierten Liefergegenständen
• Hardware-Software-Integration, wo Hardware früh festgelegt ist

7.2 Das V-Modell: Testen eingebaut

Das V-Modell entstand in den 1980ern als Evolution des Wasserfalls und adressierte eine seiner Hauptschwächen: Testen als Nachgedanke.

Ursprung: Paul Rook führte das V-Modell Ende der 1980er ein, hauptsächlich für Softwareentwicklung in regulierten Branchen.

Wichtige Innovation: Jede Entwicklungsphase auf der linken Seite des “V” hat eine entsprechende Testphase auf der rechten Seite. Testplanung geschieht parallel zur Entwicklung, nicht danach.

Die V-Form: Entwicklung fließt hinunter den linken Arm, erreicht Implementation am unteren Punkt, dann fließt Testen hinauf den rechten Arm. Die horizontalen gestrichelten Linien zeigen, dass Testplanung parallel geschieht—Abnahmetests werden entworfen, wenn Anforderungen geschrieben werden, nicht nach dem Codieren.

Die V-Form erklärt:

Verbesserung gegenüber Wasserfall:

• Tests werden früh geplant, so dass Tester während des Designs über Verifikation nachdenken
• Klare Nachverfolgbarkeit von Anforderungen zu Testfällen
• Defekte werden früher erkannt (zumindest theoretisch)

Immer noch sequentiell:

Trotz der Verbesserung leidet das V-Modell am gleichen fundamentalen Problem wie Wasserfall: Funktionierende Software erscheint erst am Ende. Wenn Anforderungen falsch waren, entdecken Sie es immer noch spät.

7.3 V-Modell XT: Der deutsche Behördenstandard

Wenn Sie an IT-Projekten für die deutsche Bundesregierung arbeiten, sind Sie verpflichtet, V-Modell XT zu verwenden. Das ist nicht optional—es ist gesetzlich vorgeschrieben.

Was ist V-Modell XT?

V-Modell XT (wobei “XT” für “eXtreme Tailoring” steht) ist der Standard-Entwicklungsprozess für deutsche Bundes-IT-Projekte seit 2005. Version 2.3 (veröffentlicht März 2019) ist aktuell in Verwendung.

Offizielle Ressourcen:

• V-Modell XT Homepage
• V-Modell XT FAQ

Geschichte:

• 1992: Ursprüngliches V-Modell entwickelt von IABG (Industrieanlagen-Betriebsgesellschaft) für das Bundesministerium der Verteidigung
• 1997: V-Modell 97 für zivile Nutzung freigegeben
• 2004: V-Modell XT mit modernisierter, anpassbarer Struktur eingeführt
• 2019: Aktuelle Version 2.3 veröffentlicht

Warum “Extreme Tailoring”?

Anders als starre Prozessmodelle ist V-Modell XT darauf ausgelegt, an verschiedene Projekttypen und -größen angepasst zu werden. Der “Tailoring”-Prozess wählt aus, welche Teile des Modells auf Ihr spezifisches Projekt anwendbar sind.

Kernkomponenten:

1. Entscheidungspunkte: Projekt-Gates, an denen bestimmte Liefergegenstände genehmigt werden müssen, bevor fortgefahren wird. Diese sichern Qualität und bieten Management-Sichtbarkeit.

2. Vorgehensbausteine: Ungefähr 20 standardisierte Module, die kombiniert werden können:
   • Projektmanagement (PM)
   • Qualitätssicherung (QS)
   • Konfigurationsmanagement (KM)
   • Problem- und Änderungsmanagement (PÄM)
   • Anforderungsmanagement
   • Systementwicklung
   • Und mehr…
3. Projekttypen:
   • Systementwicklungsprojekt
   • Systemintegrationsprojekt
   • Kombinierte Entwicklung und Integration
   • Service-Projekte
   • Agiles Entwicklungsprojekt (ja, sogar V-Modell XT hat agile Varianten!)

4. 108 definierte Produkte (Liefergegenstände): Von Anforderungsspezifikationen bis Testberichten, jedes Produkt hat eine definierte Struktur und einen Genehmigungsprozess.

5. 35 definierte Rollen: Projektmanager, Architekten, Entwickler, Tester, Qualitätsmanager und mehr—jede mit definierten Verantwortlichkeiten.

Tailoring-Prozess:

graph LR
    A[Projekttyp auswählen] --> B[Projekttypvariante auswählen]
    B --> C[Projektcharakteristiken definieren]
    C --> D[Projektspezifisches Modell generieren]

Reale Anwendungen:

• Bundes-IT-Systeme: Steuerverwaltung, Sozialversicherung, öffentliche Dienste
• Verteidigung und Luft-/Raumfahrt: Militärsysteme, Flugsicherung
• Medizingeräte-Software: Regulatorische Compliance (IEC 62304)
• Automotive Software: Sicherheitskritische Systeme (ISO 26262)
• Öffentliche Verwaltung: E-Government, Bürgerdienste

Warum das für Studenten wichtig ist:

Auch wenn Sie nicht planen, in der Regierung zu arbeiten, ist das Verstehen von V-Modell XT wertvoll, weil:

• Viele große deutsche Unternehmen (Siemens, Bosch, SAP) es oder Varianten davon nutzen
• Es demonstriert, wie regulierte Branchen Softwareentwicklung handhaben
• Es zeigt das Extrem der dokumentationsgetriebenen Entwicklung—was den Kontrast zu Agile klarer macht
• Vorstellungsgespräche in der deutschen Industrie referenzieren es oft

7.4 Das Problem mit sequentiellen Modellen

Alle sequentiellen Modelle—Wasserfall, V-Modell und V-Modell XT—teilen fundamentale Einschränkungen, die schließlich zur Agile-Bewegung führten.

Das Problem des späten Feedbacks:

In sequentiellen Modellen erscheint funktionierende Software erst am Ende. Wenn Anforderungen falsch waren, entdecken Sie es Monate (oder Jahre) nachdem die Entscheidung getroffen wurde.

graph LR
    A[Anforderungs-<br>entscheidung] -->|"6-18 Monate"| B[Funktionierende<br>Software]
    B --> C[Entdeckung:<br>'Das meinte ich nicht!']
    C --> D[Teure<br>Nacharbeit]

Die Kosten der Änderung:

Barry Boehms bahnbrechendes 1981er Buch “Software Engineering Economics” dokumentierte, was als “Kosten-der-Änderung-Kurve” bekannt wurde. Seine Studien zeigten, dass spät in der Entwicklung gefundene Defekte dramatisch teurer zu beheben sind:

• Anforderungsphase: Relative Kosten = 1x
• Designphase: Relative Kosten = 3-6x
• Codierphase: Relative Kosten = 10x
• Testphase: Relative Kosten = 15-40x
• Wartung (Produktion): Relative Kosten = 30-100x

Hinweis: Moderne Studien zeigen variierende Verhältnisse je nach Kontext. Die genauen Zahlen sind umstritten, aber das Prinzip ist robust: Späte Änderungen kosten mehr als frühe Änderungen.

Warum? Ein Anforderungsfehler, der während der Anforderungsphase gefunden wird, bedeutet Änderung eines Dokuments. Derselbe Fehler in Produktion gefunden bedeutet:

• Anforderungsdokument ändern
• Design-Dokumente aktualisieren
• Code umschreiben
• Tests erneut ausführen (Regressionstests)
• Neu deployen
• Kundenauswirkungen handhaben
• Mögliche Datenmigration

Die fundamentalen Spannungen:

Sequentielle Modelle nehmen an, dass wir:

1. Alle Anforderungen im Voraus kennen können
2. Eine vollständige Lösung vor dem Codieren entwerfen können
3. Es beim ersten Mal richtig bauen können

Die Realität widerspricht allen drei Annahmen:

Das Paradox:

• Wenn wir mehr planen: Verbringen wir Zeit mit Plänen, die sich ändern werden
• Wenn wir weniger planen: Bauen wir das Falsche
• Sequentielle Modelle nehmen Stabilität an: Aber Softwareentwicklung ist inhärent unsicher

Die Lösung?

Akzeptieren Sie, dass Änderung unvermeidlich ist und bauen Sie Prozesse, die sie annehmen. Kämpfen Sie nicht gegen Unsicherheit—arbeiten Sie mit ihr.

Diese Erkenntnis führte zur Agile-Bewegung…

8. Vorschau: Hin zu agiler Entwicklung

Alles, was wir besprochen haben, zeigt auf eine fundamentale Spannung:

Das Planungsproblem:

• Wir brauchen Anforderungen, um das Richtige zu bauen
• Aber Anforderungen ändern sich ständig
• Und Nutzer wissen nicht, was sie wollen, bis sie es sehen

Traditionelle Antwort: Mehr Planung, mehr Dokumentation, Änderungskontrolle

Agile Antwort: Änderung als unvermeidlich annehmen, schnell iterieren, früh Wert liefern

8.1 Das Agile Manifest (Vorschau)

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.

Durch diese Arbeit haben wir gelernt zu schätzen:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

8.2 Agile Anforderungen

In agiler Entwicklung:

• Anforderungen werden als User Stories erfasst (klein, verhandelbar)
• Stories leben in einem Backlog (priorisierte Liste)
• Arbeit geschieht in Sprints (kurze Iterationen, 1-4 Wochen)
• Anforderungen werden kontinuierlich verfeinert (Backlog Grooming)
• Kundenfeedback geschieht häufig (Sprint Reviews)

Nächste Vorlesung: Wir tauchen tief in Agile Methodik ein - Scrum, Sprints, Backlogs, und wie Testen in iterative Entwicklung passt.

9. Zusammenfassung

Das große Bild (beide Teile kombiniert):

Stakeholder-Bedürfnisse
       ↓
   Anforderungen (User Stories, Abnahmekriterien)  ← Teil 1
       ↓
   Erhebung & Verfeinerung  ← Teil 2
       ↓
   Tests (verifizieren Anforderungen)  ← Teil 1
       ↓
   Code (implementiert Anforderungen, besteht Tests)
       ↓
   Change Requests & Bug Fixes  ← Teil 2
       ↑
   Lücken offenbaren fehlende Anforderungen
       ↑
   Zurück zu Stakeholder-Gesprächen

10. Reflexionsfragen

1. Schauen Sie auf Ihr aktuelles Projekt: Welche Anforderungen sind implizit in Ihrem Code? Wo sind sie dokumentiert?

2. Stakeholder-Analyse: Wer sind die Stakeholder für den Road Profile Viewer? Was könnte ein “Sicherheitsbeauftragter”-Stakeholder fordern, das nicht in unserer ursprünglichen Liste war?

3. Bug oder CR? Ein Nutzer meldet: “Das System stürzt ab, wenn ich eine Datei mit 1 Million Punkten lade.” Die Dokumentation sagt nichts über Dateigrößenlimits. Bug oder Change Request? Wie würden Sie damit umgehen?

4. Testbarkeit: Nehmen Sie diese Anforderung: “Das System soll zuverlässig sein.” Schreiben Sie sie so um, dass sie testbar ist.

5. POC-Ansatz: Wenn Sie ein neues Feature für Road Profile Viewer bauen würden und nicht genau wüssten, was Nutzer brauchen, wie würden Sie einen Gen AI-unterstützten POC-Ansatz nutzen, um Anforderungen zu entdecken?

11. Weiterführende Literatur

Bücher:

• Karl Wiegers & Joy Beatty: Software Requirements (3. Aufl.) - Die umfassende Referenz
• Eric Ries: The Lean Startup - POC-getriebene Produktentwicklung
• Mike Cohn: User Stories Applied - Praktischer Leitfaden für User Stories

Standards:

• IEEE 830: Software Requirements Specifications (älter aber grundlegend)
• IEEE 29148: Requirements Engineering (moderner Standard)

Werkzeuge:

• GitHub Issues: Eingebautes Anforderungs-Tracking
• Jira: Enterprise Anforderungsmanagement
• Linear: Modernes, entwicklerfreundliches Issue-Tracking
• pytest-bdd: Behavior-driven Development mit pytest