Requirements Engineering ist endlich tot

1999, Frankfurt. Der Business Analyst.

Ich war Business Analyst bei Electronic Data Systems. Mein Job: Anforderungen aufnehmen, Data Schemas entwerfen, relationale Datenbanken modellieren. Entity-Relationship-Diagramme. Normalisierung. Alles musste fertig spezifiziert sein, bevor eine einzige Zeile Code geschrieben wurde. Das war die Welt, in der ich gelernt habe zu arbeiten.

Ich lernte RUP — den Rational Unified Process. Ich lernte, wie man Use Cases schreibt, wie man Anforderungsdokumente strukturiert, wie man Stakeholder-Interviews führt und daraus Spezifikationen destilliert. Alles in der Überzeugung: Wenn ich nur präzise genug spezifiziere, wenn ich nur gründlich genug dokumentiere, wenn ich nur alle möglichen Szenarien vorher durchdenke — dann werde ich die richtigen Anforderungen erfassen und das richtige System bauen.

Requirements Engineering war die Priesterkaste dieses Glaubens. Anforderungsingenieure waren Übersetzer — zwischen einer unklaren "Business"-Welt und einer angeblich dummen technischen Welt. Sie sollten das Unscharfe in Präzision verwandeln. Das Emotionale in Spezifikation. Das Lebendige in Dokumentation.

Und es funktionierte nicht. Nie.

2002, Wien. Sprint Planning als Gegenangriff.

Dann fand ich Scrum. Und ich war vielleicht einer der ersten, der versuchte, das Sprint Planning zu einer Hardcore-Requirements-Engineering-Session umzubauen — nur diesmal durfte das gesamte Team sein Wissen einbringen.

In meinem ersten Scrum-Buch und auf meinem Blog beschrieb ich Sprint Planning 1 als einen Neun-Schritte-Prozess (Gloger, 2008, S. 117–123):

1. Nimm das erste Backlog Item.
2. Verstehe die Anforderungen dieses Items.
3. Finde die User Acceptance Tests.
4. Finde die Acceptance Criteria.
5. Finde die Constraints — Performance, Stabilität.
6. Kläre das Level of Done.
7. Bekomme ein klares Bild.
8. Zeichne Bilder — Flowcharts, UML-Diagramme, Scribbles, Screen Designs.
9. Nächstes Item.

Das war Requirements Engineering. Nur für zwei Wochen statt für sechs Monate. Und das ganze Team machte es, nicht ein einzelner Business Analyst.

Damit unterlief ich das klassische Requirements Engineering — weil es eben nicht mehr komplett davon abhing, was der Product Owner sagte. Obwohl wir natürlich so angefangen haben. Das Team schrieb seine eigenen Anforderungen. Das Team verstand, was es bauen sollte. Das Team wurde zum Anforderungsingenieur.

Aber die Reise weg vom Requirements Engineering war lang. Sehr lang.

Die Hierarchie. Eine Machtstruktur.

Was mir in all den Jahren aufgefallen ist: Es gibt eine soziale Hierarchie in den Unternehmen, die sich hartnäckig hält. Ganz oben steht das Business — die Leute, die sagen, was sie wollen. Dann kommt die Organisationsabteilung oder die Requirements-Engineering-Abteilung — die Übersetzer. Dann kommen die Systemarchitekten. Dann die Software Engineers. Und ganz unten die Betriebsmannschaft, die das Ganze am Laufen hält.

Diese Hierarchie ist keine Beschreibung von Kompetenzen. Sie ist eine Machtstruktur. Je weiter oben du stehst, desto mehr darfst du sagen, was gebaut werden soll. Je weiter unten, desto weniger darfst du fragen, ob das überhaupt Sinn ergibt.

Requirements Engineering institutionalisierte diese Machtbeziehung. Es sagte: Es gibt einen präzisen Unterschied zwischen denen, die wissen, was gebaut werden soll, und denen, die es bauen. Diese Grenzziehung war künstlich — aber sie war funktional. Sie ermöglichte Kontrolle. Sie ermöglichte Dokumentation. Sie ermöglichte die Illusion, dass Komplexität durch Spezifikation zu zähmen ist.

Wenn ich Niklas Luhmann im Kopf habe — und ich habe ihn oft — dann sehe ich Requirements Engineering als einen bestimmten Typus von Kommunikation: eine, die das Problem der Nicht-Kommunikation versteckt (vgl. Luhmann, 1984, Kap. 4). Zwei Menschen aus verschiedenen sozialen Systemen — eine Geschäftsperson und eine Technikperson — verstehen sich nicht grundlegend. Sie haben verschiedene Codes. Verschiedene Wahrheiten. Verschiedene Dringlichkeiten. Requirements Engineering war das Ritual, das diese Nicht-Kommunikation verschleierte. Die langen Meetings, die Dokumentation, die User-Story-Workshops — sie gaben allen das Gefühl, dass Kommunikation stattgefunden hatte. Sie hatte nicht.

2002–2025. Zwanzig Jahre gegen das Aufschreiben.

Was Scrum-Teams machten, war diese Hierarchie systematisch zu torpedieren. Wir sagten: Wir brauchen keine Rollen in den Teams. Wir brauchen Teammitglieder, die all diese Aufgaben übernehmen und gemeinsam selbstorganisierend arbeiten, so dass eine Emergent Architecture entsteht. Wo du keinen Hauptsoftwarearchitekten brauchst, der von oben herab die Struktur vorgibt.

Das wollten die natürlich nicht. Die Architekten nicht. Die Business Analysten nicht. Die Manager nicht.

Und es hat sich bis heute gehalten — in vielen Unternehmen sagt das Business den Entwicklern, was sie zu liefern haben. Ich habe in Wie schätzt man in agilen Projekten (Gloger, 2014) versucht, dem entgegenzuarbeiten. Das ganze Buch ist ein Argument gegen die Idee, dass jemand von außen dem Team sagen kann, was es zu bauen hat und wie lange es dauert.

Aber ich wusste immer: Man kann es nicht aufschreiben. Nicht wirklich. Nicht komplett.

Warum man es nicht aufschreiben kann. Wittgenstein, Adorno, Gabriel.

Und das ist kein praktisches Problem — es ist ein philosophisches.

Requirements sind Sprachspiele. Wittgenstein hat das in den Philosophischen Untersuchungen gezeigt: Jede sprachliche Äußerung ist in einer menschlichen Praxis beheimatet. Bedeutung entsteht nicht durch Abbildung von Realität, sondern durch Gebrauch (Wittgenstein, 1953, §43). Wenn ein Business Analyst schreibt: "Das System soll dem Nutzer ermöglichen, seinen Kontostand abzufragen" — dann ist das kein Abbild einer Realität. Es ist ein Zug in einem Sprachspiel namens Requirements Engineering. Es folgt den Regeln dieses Spiels. Aber es sagt nichts Zuverlässiges darüber, was der Nutzer wirklich braucht.

Adorno geht noch weiter. In der Negativen Dialektik zeigt er: In jedem Begriff steckt auch der Nichtbegriff (Adorno, 1966, S. 17). Wenn ich ein Requirement aufschreibe, schreibe ich gleichzeitig alles mit, was ich nicht aufschreibe — alles, was der Begriff ausschließt, alles, was zwischen den Zeilen verschwindet. Die Spezifikation behauptet Vollständigkeit und ist im selben Moment unvollständig. Der Fehler liegt nicht in der Ausführung. Er liegt im Begriff selbst.

Und dann Markus Gabriel mit seinem Neuen Realismus. Gabriel sagt: Es gibt Tatsachen. Faktische Wahrheiten. Dinge existieren in "Sinnfeldern" — und in jedem Sinnfeld sind die Tatsachen real (Gabriel, 2013, Kap. 3). Das klingt, als müsste man Tatsachen aufschreiben können. Wenn es sie gibt, sollten sie spezifizierbar sein.

Aber hier wird es faszinierend: Wie löst Gabriel das auf, dass Adorno sagt, du sagst in jedem Begriff auch den Nichtbegriff? Gabriels Antwort wäre: Ein Requirement ist eine Tatsache — aber nur im Sinnfeld "Requirements Engineering." Es ist keine Tatsache im Sinnfeld "Was der Nutzer wirklich braucht." Die Sinnfelder sind verschieden. Ein Requirement ist ein Fakt darüber, was in einem Meeting gesagt wurde. Nicht ein Fakt darüber, was gebaut werden sollte.

Das ist der Kern: Requirements Engineering war immer ein Sprachspiel, das so tat, als wäre es Realitätserfassung. Wittgenstein zeigt: Sprache bildet nicht ab. Adorno zeigt: Der Begriff verrät das Ding. Gabriel zeigt: Die Tatsache existiert — aber in einem anderen Sinnfeld, als der Anforderungsingenieur glaubt.

Das Agile Manifesto wusste das intuitiv: "Responding to change over following a plan" (Beck et al., 2001). Es gibt keinen Plan, der hält. Es gibt nur Lernen. Exploration. Emergenz.

Aber Requirements Engineering starb nicht. Es mutierte. Es versteckte sich in User Stories. In Akzeptanzkriterien. In Definition of Done. Es überlebte, weil auch agile Teams den Glauben brauchten, dass man durch genug Struktur und Kommunikation die richtige Sache bauen würde.

Das war mein Versuch, zwanzig Jahre lang: gegen dieses Requirements Engineering zu arbeiten. Weil ich immer wusste, man kann es nicht aufschreiben.

2026, März. Disposable Software.

Jetzt ist etwas passiert, das alles verändert. Nicht philosophisch. Praktisch.

Ich benutze seit zwei Monaten Claude Code, Codex. Die Art, wie man mit diesen Systemen arbeitet, ist fundamental anders als alles, was Requirements Engineering je vorgesehen hat.

So funktioniert es: Du öffnest Claude Cowork, oder Cursor. Du schreibst in natürlicher Sprache, was du willst. Das System baut es. In Minuten, nicht Monaten. Du siehst sofort, ob dein Gedanke funktioniert oder Unsinn ist. Du änderst. Das System baut neu. Du änderst wieder. In vier Minuten hast du drei Iterationen hinter dir — dafür brauchtest du vorher vier Wochen.

Und das Entscheidende: Wenn es nicht passt, wirfst du es weg. Disposable Software. Du baust es nochmal. Von vorn. Anders. Die Kosten einer falschen Entscheidung sind nicht mehr sechs Monate verlorene Entwicklungszeit. Sie sind zehn Minuten.

Das macht Requirements Engineering nicht nur überflüssig. Es macht die gesamte Denkweise obsolet, auf der Requirements Engineering basierte: dass man vorher wissen muss, was man will.

Du musst es nicht vorher wissen. Du lernst es, indem du anfängst.

Das Insulinpumpen-Beispiel. Wissenschaft statt Spezifikation.

Nehmen wir an, wir bauen eine Medizintechnik-App. Eine bessere Insulinpumpe.

Im alten Requirements-Engineering-Modell würde ich monatelang Anforderungen erheben. Stakeholder-Interviews. Use Cases. Nicht-funktionale Anforderungen. Systemarchitektur-Reviews. Bevor eine Zeile Code geschrieben wird.

Mit einer KI mache ich etwas anderes. Ich füttere sie mit Wissenschaft — nicht mit Spezifikationen im Sinne von "ich will das haben", sondern mit Sachverhalten. Wie funktioniert Blut? Was sind die Materialzusammenhänge? Wie funktioniert die Physik der Insulinabgabe? Ich gebe ihr die ganze Wissenschaft. Vielleicht ist sie damit sogar schon trainiert.

Dann gebe ich ihr die Constraints: Du musst die FDA-Richtlinien erfüllen. Du musst die ISO-Normen einhalten. Toleranzen von x Prozent sind zu beachten.

Und dann sage ich: Bau mir eine bessere Insulinpumpe als alles, was es auf dem Markt gibt. Und ich möchte sie angenehmer für die Menschen haben, die sie benutzen.

Ein Requirement im klassischen Sinne ist das nicht mehr. Eher ein Raum von Möglichkeiten, begrenzt durch Constraints und informiert durch Wissenschaft. Die KI exploriert diesen Raum. Sie baut. Sie testet. Sie iteriert. Ich sehe Ergebnisse und sage: Nein, nicht so. Oder: Ja, mehr davon. Oder: Was passiert, wenn wir den Sensor hier platzieren?

Kein Anforderungsingenieur sitzt mehr zwischen mir und dem, was gebaut wird. Die Machtstruktur — Business sagt, Entwicklung baut — löst sich auf. Nicht durch eine bessere Methodik. Durch eine andere Technologie.

Hannah Arendt. Handeln statt Herstellen.

Das ist — im Sinne von Hannah Arendt — nicht mehr Herstellen. Requirements Engineering war immer Herstellen: den Prozess der Fabrikation optimieren. Rohstoff (Anforderung) → Werkzeug (Spezifikation) → Produkt (Software). Ein linearer Produktionsprozess, getarnt als Wissensarbeit (vgl. Arendt, 1958, Kap. IV).

Was jetzt passiert, ist Handeln. Das Betreten eines Raums von Möglichkeiten. Ohne Drehbuch. Ohne Vollständigkeit. Du sagst etwas, du siehst die Konsequenz, du entscheidest — und du trägst die Verantwortung.

Das ist nicht "Wissen, was man will, bevor man anfängt." Das ist: "Lernen, was man will, indem man anfängt."

Das Requirements-Engineering-Establishment.

Gartner hat eine Zahl genannt: 80 Prozent der Engineering Workforce muss bis 2027 upskilling erfahren (Gartner, 2024). Andrey Karpathy hat es direkter gesagt: Agentic Engineering ist die Zukunft. Du schreibst nicht Code. Du orchestrierst Agenten, die Code schreiben (Karpathy, 2025).

Und was sehe ich? Konferenzen mit Titeln wie "Requirements Engineering meets AI" oder "How AI enhances the RE process." Seminare in "Prompt Engineering für Business Analysten."

Neuerfindung? Besseres Kutschendesign im Zeitalter des Automobils.

Der ehrliche Satz wäre: Wir lehren jetzt Domain-Expertise und KI-Zusammenarbeit. Aber das würde bedeuten, Requirements Engineering als Disziplin aufzugeben.

Es ist leichter, es zu retten. Aber es kann nicht gerettet werden.

Was bleibt. Domain Intelligence.

Domain-Expertise wird wichtiger, nicht weniger. Aber sie wird anders. Es geht nicht mehr um die Frage: Was soll das System tun? Das kann eine KI heute schneller erkunden als jeder Anforderungsingenieur je konnte. Es geht um: Was darf es nicht tun? Was sind die Constraints? Was ist die Wissenschaft dahinter? Was sind die Regulierungen?

Requirements Engineering ist das nicht mehr. Wir brauchen einen anderen Namen. Etwas, das noch keinen Namen hat. Vielleicht Domain Intelligence. Vielleicht Constraint Thinking. Es braucht mehr Denken und weniger Prozess. Mehr Verstehen und weniger Dokumentation.

Die Nicht-Kommunikation löst sich auf.

Die Nicht-Kommunikation, die Requirements Engineering verschleierte, löst sich nicht durch bessere Kommunikation. Sie löst sich durch direktes Sehen. Ich sage etwas, die KI baut etwas, ich sehe es, mein Verstand klart auf — und wir iterieren.

Keine versteckte Nicht-Kommunikation mehr. Nur sichtbares Lernen.

Manchmal stelle ich mir vor, was ein Software-Team Ende 2026 sagen würde, wenn jemand "Requirements Engineering" sagt. Sie würden wahrscheinlich fragen: Was ist das?

Und das ist nicht tragisch. Die Welt hat sich weitergedreht.

Was bleibt, ist die archaische Wahrheit dahinter: dass es einen Unterschied gibt zwischen denen, die wissen, und denen, die bauen. Das wird es immer geben. Aber der Unterschied ist nicht mehr eine Machtbeziehung, mediert durch Dokumentation. Er ist eine Zusammenarbeit, mediert durch Iteration und sichtbares Lernen.

Requirements Engineering ist endlich tot. Es hat zwanzig Jahre gedauert. Scrum war der erste Versuch, es zu überwinden — indem das Team seine eigenen Anforderungen schrieb. KI ist das Ende — weil es die Trennung zwischen Denken und Bauen aufhebt.

Und wir können anfangen, wirklich zu bauen.

Literaturverzeichnis

Adorno, T. W. (1966). Negative Dialektik. Suhrkamp.

Arendt, H. (1958). The Human Condition. University of Chicago Press. [Deutsch: Vita activa oder Vom tätigen Leben, Piper, 1960.]

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J. & Thomas, D. (2001). Manifesto for Agile Software Development. https://agilemanifesto.org

Gabriel, M. (2013). Warum es die Welt nicht gibt. Ullstein.

Gartner (2024, 3. Oktober). Gartner Says Generative AI Will Require 80% of Engineering Workforce to Upskill Through 2027. Gartner Newsroom. https://www.gartner.com/en/newsroom/press-releases/2024-10-03-gartner-says-generative-ai-will-require-80-percent-of-engineering-workforce-to-upskill-through-2027

Gloger, B. (2008). Scrum — Produkte zuverlässig und schnell entwickeln. Hanser. [Sprint Planning 1, S. 117–123.]

Gloger, B. (2014). Wie schätzt man in agilen Projekten — oder wieso Schätzen nicht funktioniert. Hanser.

Karpathy, A. (2025). Software is changing (again). https://karpathy.ai/blog/software-is-changing

Luhmann, N. (1984). Soziale Systeme: Grundriß einer allgemeinen Theorie. Suhrkamp.

Wittgenstein, L. (1953). Philosophische Untersuchungen / Philosophical Investigations. Blackwell. [§43: "Die Bedeutung eines Wortes ist sein Gebrauch in der Sprache."]

Du liest als Gast — willkommen. Als Leser bekommst du „Den Brief": persönliche Werkstattnotizen, 2x im Monat, direkt in dein Postfach. → Leser werden