Wie beschrieben gebaut:
fünf Risiken bei Softwareanforderungen, die über ein Projekt entscheiden

Ein Projekt kann pünktlich, im Budget und mit relativ wenigen technischen Fehlern geliefert werden und trotzdem wirtschaftlich scheitern. Es hat schlicht das Falsche gebaut. Das Problem entsteht dort, wo Softwareanforderungen geschrieben werden, lange vor der ersten Codezeile. Dort lässt es sich auch am günstigsten verhindern.

Die Forschung zeigt viele Probleme, die in Softwareanforderungen stecken. Für ein typisches mittleres oder großes Softwareprojekt würde ich fünf priorisieren. Ihr relatives Gewicht hängt von der Domäne des Projekts und vom Liefermodell ab.

Unvollständige Softwareanforderungen: teure Nacharbeit

Was in einer Anforderung fehlt, sieht man selten an dem Tag, an dem jemand sie schreibt. Es zeigt sich später, wenn jemand sie umsetzen oder testen muss. Eine auf der Konferenz ASE 2026 vorgestellte Studie untersuchte 8.082 Anforderungen, die ein Chiphersteller von Autoherstellern, Normungsgremien und eigenen Entwicklungsteams erhielt. Nur 0,2 % waren vollständig spezifiziert. Der Einsatzkontext fehlte in 81,5 % der Fälle, die Bedingungslogik in 51,5 % und das erwartete Verhalten in 45 %. Je weniger Kontext eine Anforderung enthielt, desto mehr detaillierte Anforderungen mussten die Ingenieure daraus ableiten^[1].

Interviews bei einem Autohersteller und einem Zulieferer erklären, warum. Zu Projektbeginn fehlt den Autoren der Anforderungen oft das Wissen über das künftige Produkt. Deshalb fallen Anforderungen vage aus oder veralten schnell. Kunden, die ihr Problem nicht ganz verstehen, beschreiben stattdessen die Lösung, die sie sich wünschen. Kurze Vertragsfristen zwingen die Teams außerdem, Anforderungen in Eile zu erheben^[2].

Manche Lücken verstecken sich vor aller Augen. Wird ein Altsystem ersetzt, ist auch alles, was es bereits leistet, eine Anforderung. Eine Studie zur Modernisierung eines Altsystems aus dem Jahr 2026 zeigte, dass Interviews neue Bedürfnisse gut erfassten. Was das bestehende System schon leistete, übersahen sie jedoch. Dieses Wissen steckte nur in den Köpfen der Menschen^[3].

Mehrdeutige Softwareanforderungen: fehlerhafte Funktionen

Eine mehrdeutige Anforderung ist schlimmer als eine fehlende, weil sie vollständig aussieht. Zwei Leser finden darin zwei Bedeutungen, und jeder baut, was er verstanden hat.

Praktiker halten Mehrdeutigkeit für den schlimmsten Mangel von Softwareanforderungen. Eine Studie aus dem Jahr 2025 in einem großen europäischen Rüstungsunternehmen befragte zehn erfahrene Ingenieure in Interviews und 58 weitere in einer Umfrage. Acht der zehn Befragten zählten Mehrdeutigkeit zu den drei schwersten Mängeln, sieben zu den drei häufigsten. Die Umfrage bestätigte außerdem beide Rangfolgen. Die Ingenieure beschrieben die Folgen klar. Eine mehrdeutige Anforderung wandert zwischen Analysten und Entwicklern hin und her und zieht Änderungsanträge nach sich. Schlimmer noch: Sie kann bis zu Integrationstests oder Wartung unbemerkt bleiben, wenn die Korrektur am teuersten ist^[4]. Auch die Forschung spiegelt diese Priorität wider. Eine Auswertung von 105 empirischen Studien zur Qualität von Anforderungen ergab, dass Mehrdeutigkeit das am häufigsten untersuchte Qualitätsmerkmal ist, mit mehr Unterarten als jedes andere^[5].

KI verschärft dieses Risiko, statt es zu verringern. Eine auf der Konferenz ASE 2026 vorgestellte Studie schrieb 1.304 Programmieraufgaben in mehrdeutige Varianten um und gab sie großen Sprachmodellen. Mehrdeutigkeit senkte den Anteil korrekter Lösungen im Durchschnitt um 7,22 Prozentpunkte und um bis zu 32 Punkte. Zudem wurden die Antworten weniger konsistent: Bei GPT-4 stieg der Anteil widersprüchlicher Antworten auf dieselbe Aufgabe von 14 % auf 28 %. Die Modelle erkannten je nach Art nur zwischen 25 % und 44 % der mehrdeutigen Formulierungen^[6]. Ein KI-Modell fragt nicht, was Sie gemeint haben. Es wählt eine Bedeutung und schreibt den Code.

Unkontrollierte Änderungen der Anforderungen: Kosten- und Terminüberschreitungen

Softwareanforderungen werden sich ändern, weil sich das Geschäft ändert. Das Risiko ist die Änderung ohne Kontrolle: eine Änderung, die niemand bewertet, bepreist und im Systementwurf nachverfolgt.

Eine Fallstudie in einem Softwareunternehmen auf Basis von 15 Interviews führte die Volatilität der Anforderungen vor allem auf zwei Ursachen zurück. Das waren unsichere Anforderungen und ein sich wandelndes Geschäftsumfeld. Als Folge nannten die Architekten Terminprobleme und technische Schulden in der Architektur^[7]. Die Studie aus der Rüstungsbranche stellt zudem eine Verbindung zu Risiko 2 her: Mehrdeutige Anforderungen sind eine häufige Quelle von Änderungsanträgen^[4]. Viele Änderungen sind also gar keine neuen Bedürfnisse, sondern alte Anforderungen, die endlich verstanden wurden.

Darüber hinaus erschwert Komplexität die Lage. Im PMI Pulse of the Profession 2026 sagten 81 % der Projektfachleute, Projekte seien komplexer geworden. Vier von fünf komplexen Projekten erlitten negative Folgen, etwa strategische Abweichungen oder Störungen in der Umsetzung^[8]. Ohne gepflegte Baseline und Folgenabschätzung für jede Änderung trifft jede Verschiebung der Prioritäten direkt Budget und Zeitplan.

Fehlende nicht-funktionale Anforderungen: Ausfälle im Betrieb

Funktionale Anforderungen beschreiben, was das System tut. Nicht-funktionale Anforderungen beschreiben, wie gut es das tut: Leistung, Zuverlässigkeit, Sicherheit, Wartbarkeit. Sie prägen die Architektur, und gerade sie bleiben am häufigsten unausgesprochen.

Eine Analyse der internationalen NaPiRE-Umfrage zum Requirements Engineering aus dem Jahr 2025 ergab, dass die meisten Befragten Wartbarkeit, Zuverlässigkeit, Benutzbarkeit und Leistung für wichtig halten. Einige berichteten jedoch, dass Anforderungen an diese wichtigen Merkmale nicht dokumentiert waren. Die Autoren werten diese Lücken als technische Schulden^[10]. Ein Ingenieur aus der Studie in der Rüstungsbranche nannte ein Beispiel dafür, was dann geschieht. Eine Aufgabe, die nur als „hohe Priorität“ und „schnell“ beschrieben ist, kann niemand sauber testen. Das System besteht seine Tests und versagt dann im Betrieb, wo die realen Rahmenbedingungen anders sind^[4].

Ebenso weisen Prüfungen im öffentlichen Sektor in dieselbe Richtung. Das niederländische Prüfgremium für staatliche IT-Projekte, das Adviescollege ICT-toetsing (AcICT), prüfte 2025 insgesamt 20 Projekte im Wert von mehr als 1,1 Mrd. Euro. Es verlangt Sicherheitsanforderungen, die „konkret, anwendbar und testbar“ sind. Außerdem soll die Wartung schon in der Projektphase geplant und finanziert werden^[9].

Zu wenig Beteiligung der Stakeholder: geschäftlicher Bedarf verfehlt

Softwareanforderungen sind nur so gut wie die Menschen, die sie gestalten. Fehlen die richtigen Leute, erfüllt das System die Spezifikation und verfehlt das Geschäft.

Das AcICT stellte fest, dass die Rolle des Auftraggebers in staatlichen IT-Projekten noch immer zu oft unzureichend ausgefüllt wird. Projekte geraten ins Stocken, wenn Auftraggeber sich zu sehr auf den Lieferanten verlassen und selbst zu wenige konkrete, messbare Anforderungen festlegen^[9]. Ähnlich beschreiben die Interviews aus der Automobilbranche dasselbe Problem von innen. Kommunikations- und Feedbackkanäle über Ebenen und Organisationen hinweg sind schwer aufzubauen, und die Verantwortung zwischen Teams ist oft unklar^[2]. In der Studie zur Modernisierung eines Altsystems nahmen Nutzer aus einem Land nicht an der Priorisierung teil. Die Entwickler verzichteten auf eine Teilnahme, weil sie das nicht als ihre Aufgabe sahen^[3].

Die Menschen, die Anforderungen schreiben, zählen ebenso viel wie die Menschen, die sie befragen. Eine kleine Studie aus dem Jahr 2026 unter 18 Praktikern in Brasilien listete 17 unerwünschte Eigenschaften von Requirements Engineers auf. Kommunikationsprobleme und fehlendes Fachwissen gehörten zu den wichtigsten Gruppen^[11]. Schließlich stellte PMI fest, dass besonders erfolgreiche Teams Sponsoren häufiger vor der Umsetzung auf Erfolgskriterien einschworen: 39 % gegenüber 30 %. Insgesamt brachten 31 % der komplexen Projekte nicht den vollen beabsichtigten Nutzen^[8].

Softwareanforderungen als Risikoindikator des Projekts

Die grundlegende Herausforderung bei Softwareanforderungen besteht nicht einfach darin, aufzuschreiben, was die Software tun soll. Sie besteht darin, ein gemeinsames, validiertes, testbares und laufend gepflegtes Verständnis des geschäftlichen Bedarfs sicherzustellen.

Ein Projekt kann pünktlich, im Budget und mit relativ wenigen technischen Fehlern geliefert werden und trotzdem wirtschaftlich scheitern, weil es die falschen Anforderungen umsetzt. Deshalb sollte die Qualität der Anforderungen in der Steuerung von Softwareprojekten als zentraler Risikoindikator gelten, neben Budget, Zeitplan und technischer Qualität.

Fünf Fragen helfen, sie vor der nächsten Lenkungsausschusssitzung zu messen.

1. Ist jede Anforderung vollständig genug, um sie ohne Raten umzusetzen und zu testen? Prüfen Sie Kontext, Bedingungen und erwartetes Verhalten, auch das, was das Altsystem bereits leistet.
2. Könnten zwei Leser sie unterschiedlich verstehen? Dann ergänzen Sie ein Beispiel oder ein Abnahmekriterium, bevor jemand Code schreibt, Mensch oder KI.
3. Wird jede Änderung bewertet, bevor sie angenommen wird? Legen Sie fest, wer sie genehmigt, was sie kostet und welche Teile des Entwurfs sie berührt.
4. Sind Leistung, Zuverlässigkeit, Sicherheit und Wartbarkeit aufgeschrieben und testbar? Wenn nicht, entscheidet der Zufall über die Architektur.
5. Haben die künftigen Nutzer des Systems die Anforderungen mitgestaltet? Und hat sich der Sponsor darauf festgelegt, was Erfolg für ihn bedeutet?

Wer auch immer den Code schreibt, ein Inhouse-Team, ein Lieferant oder ein KI-Modell: Gebaut wird, was die Softwareanforderungen sagen.

Quellen

1. Z. Wang, S. Yu, Z. Xing, T. Wenzel, C. Chen, „Bridging Stakeholder and Product Requirements: An Empirical Study of Requirement Engineering in the Automotive Industry“, ASE 2026, arXiv:2607.05632, 6. Juli 2026. arxiv.org
2. G. Liebel, M. Tichy, E. Knauss, O. Ljungkrantz, G. Stieglbauer, „Organisation and communication problems in automotive requirements engineering“, Requirements Engineering 23 (2018) 145–167, online veröffentlicht am 28. Oktober 2016. doi.org
3. R. S. Karper, D. A. Tamburri, A. Ferrari, W.-J. van den Heuvel, „When Stakeholder-centric Requirements Engineering is Not Enough: An Action Research Study on Legacy System Modernisation“, arXiv:2609.07340, 7. September 2026. arxiv.org
4. E. Gentili, D. Falessi, „Practitioners‘ perceptions on requirements smells“, Information and Software Technology 187 (2025) 107823, online verfügbar seit 5. Juli 2025. doi.org
5. L. Montgomery, D. Fucci, A. Bouraffa, L. Scholz, W. Maalej, „Empirical research on requirements quality: a systematic mapping study“, Requirements Engineering 27 (2022) 183–209. doi.org
6. D. Yang et al., „Clarity Is Not Assumed: Understanding LLM-Based Code Generation under Ambiguous Requirements“, ASE 2026 (East China Normal University), arXiv:2604.21505. arxiv.org
7. S. Aaramaa, S. Dasanayake, M. Oivo, J. Markkula, S. Saukkonen, „Requirements Volatility in Software Architecture Design: An Exploratory Case Study“, arXiv:2603.17648 (veröffentlicht am 18. März 2026). arxiv.org
8. Project Management Institute, Pulse of the Profession 2026, „Driving Success in Complex Projects“, Pressemitteilung, 12. Mai 2026. businesswire.com
9. Adviescollege ICT-toetsing, „Jaarrapportage 2025“ (Jahresbericht 2025), März 2026, veröffentlicht am 9. April 2026, CC BY 4.0. adviescollegeicttoetsing.nl
10. E. Scott, G. Robiolo, S. Matalonga, M. Felderer, D. Pfahl, „A study on reported under-documented non-functional requirements as an indicator of technical debt“, Software Quality Journal 33 (2025), Artikel 28, online veröffentlicht am 30. Juni 2025. doi.org
11. L. Barbosa et al., „Understanding Undesirable Attributes of Requirements Engineers: Insights from Practitioners“, arXiv:2606.01370, 31. Mai 2026. arxiv.org