Welche Entscheidungen sind zu treffen?<\/h2>\n
Das Ergebnis eines Software-Projekts ist ausf\u00fchrbarer Programmcode, der auf einem daf\u00fcr passenden Ger\u00e4t \u2013 einem Smartphone, einem Laptop, einem dedizierten Server oder in der Cloud \u2013 ausgef\u00fchrt wird. Auf dem Weg dahin, werden zahlreiche Entscheidungen getroffen:<\/p>\n
- \n
- Welche Ziele<\/strong> sollen mit der Software erreicht werden?<\/li>\n
- Welche Stakeholder<\/strong> m\u00fcssen ber\u00fccksichtigt werden?<\/li>\n
- Wie sind die Gesch\u00e4ftsprozesse<\/strong> gestaltet?<\/li>\n
- Welche Daten<\/strong> verarbeitet das System?<\/li>\n
- Welche technischen und grafischen Schnittstellen<\/strong> sind notwendig?<\/li>\n
- Auf welchen Ger\u00e4ten oder Servern<\/strong> wird der Code ausgef\u00fchrt?<\/li>\n<\/ul>\n
Wo verbergen sich die Mehrwerte?<\/h3>\n
Bereits in der ersten Frage verbirgt sich die Suche nach Mehrwerten. Diese sind im Idealfall messbar und richten sich an den Bed\u00fcrfnissen von Stakeholdern aus. Realisiert werden die Mehrwerte durch Entscheidungen, die entlang der obigen Leitfragen getroffen werden, und zwar von oben (dem Abstrakten) nach unten (dem Konkreten). Entlang dieser Kette werden Prozessschritte und Systemverantwortlichkeiten festgelegt, die Datenstrukturen und Schnittstellen definiert, und die technische Infrastruktur geschaffen. All dies geschieht, um am Ende den praktischen Nutzen einer Software zu realisieren, sobald sie auf dem entsprechenden Ger\u00e4t l\u00e4uft.<\/p>\n
Die Leitfragen und deren Reihenfolge sind kein Zufall: Sie folgen einem Rahmenwerk, das wir am Fraunhofer IESE seit ca. 25 Jahren weiterentwickeln und in Software-Projekten einsetzen: \u00bbTask-Oriented Requirements Engineering\u00ab<\/strong>, kurz \u00bbTORE\u00ab<\/a>.<\/p>\n
Requirements Engineering als Entscheidungsprozess<\/h2>\n
Requirements Engineering bildet die erste Phase im traditionellen Software-Engineering und besitzt dieselbe hohe Wichtigkeit in agilen Projekten: Kontinuierlich arbeitet ein Team darauf hin, erhobene Anforderungen in Form von Inkrementen der Gesamtl\u00f6sung zu realisieren. W\u00e4hrend die Prozessschritte und Vorgehensweisen in wasserfallartigen und agilen Projekten sehr unterschiedlich sein k\u00f6nnen, sind zu treffenden Entscheidungen stets dieselben: Ein Requirements-Engineering-Prozess ist ein Entscheidungsprozess<\/strong>, in dem f\u00fcr ein System dessen Nutzungskontext, Scope, Funktionalit\u00e4t und Qualit\u00e4t festgelegt werden. Die verantwortlichen Akteure haben dabei meist die Aufgabe, aus verschiedenen Optionen eine Entscheidung zu treffen.<\/p>\n
Das TORE-Rahmenwerk ordnet die Entscheidungen in vier Abstraktionsebenen ein, wie sie in Abbildung 1 dargestellt sind, einschlie\u00dflich aller Entscheidungspunkte.<\/p>\n
1. Projektebene<\/h3>\n
Auf der ersten Ebene wird das \u00fcbergeordnete Thema des Projekts formuliert. Es stellt sicher, dass ein gemeinsames Verst\u00e4ndnis zum Inhalt des Projekts unter allen Beteiligten besteht. Anschlie\u00dfend werden die Stakeholder identifiziert, also Personen oder Organisationseinheiten, die ein Interesse am Projekt haben oder von den Arbeiten bzw. dem Ergebnis des Projekts betroffen sind. Die Projektziele legen fest, welcher Nutzen durch das Projekt f\u00fcr welche Stakeholder erreicht werden muss. Als letzten Punkt auf der Projektebene werden die Gesch\u00e4ftsprozesse identifiziert, die im Rahmen des Projekts behandelt werden.<\/p>\n
2. Gesch\u00e4ftsebene<\/h3>\n
Die folgende Ebene befasst sich mit den gesch\u00e4ftlichen Prozessen. Begonnen wird mit der Erhebung des gegenw\u00e4rtigen Ist-Stands. Dies zielt darauf ab, zu verstehen, wie Prozesse aktuell durchgef\u00fchrt werden sowie welche St\u00e4rken und Schw\u00e4chen sie aufweisen. Darauf aufbauend wird die Soll-Situation erarbeitet. Diese beschreibt, wie die Prozesse k\u00fcnftig ablaufen sollen, um zuvor im Ist-Stand identifizierte Schw\u00e4chen zu adressieren. Dabei wird festgelegt, welche Rolle welche Prozessschritte \u00fcbernimmt, und hierbei werden bestimmte Daten produziert oder konsumiert. Auf Basis dieser Soll-Prozesse wird abgeleitet, welche Teile oder Schritte durch Systeme unterst\u00fctzt oder gar vollst\u00e4ndig automatisiert werden. Des Weiteren sind f\u00fcr ein Verst\u00e4ndnis der Gesch\u00e4ftsebene die Gesch\u00e4ftsdaten und zugeh\u00f6rige Regeln f\u00fcr die Handhabung von Daten oder die Durchf\u00fchrung von Prozessen von Interesse.<\/p>\n
3. Interaktionsebene<\/h3>\n
Die Interaktionsebene verfeinert haupts\u00e4chlich die zuvor identifizierten Teile des Soll-Prozesses, deren Durchf\u00fchrung durch IT-Systeme unterst\u00fctzt wird. Zun\u00e4chst werden f\u00fcr diese Teile die Interaktionen zwischen Nutzern oder externen Systemen mit dem zu entwickelnden System erarbeitet. Innerhalb einer solchen Interaktion werden \u00fcblicherweise Teilaufgaben vom System \u00fcbernommen, z.B. Berechnungen oder Datenausgaben. Diese konkreten Funktionalit\u00e4ten werden als Systemfunktionen identifiziert und detailliert dokumentiert. Sie bilden einen Kern der Anforderungen an das zu entwickelnde System ab. Zus\u00e4tzlich ergeben sich durch die Interaktionen mit dem System weitere Daten und Regeln, die die bereits auf der vorherigen Ebene erfassten Gesch\u00e4ftsdaten detaillieren. Die Interaktionen laufen im Regelfall mithilfe einer Nutzerschnittstelle ab, die auf der Interaktionsebene konzeptionell erfasst wird.<\/p>\n
4. Systemebene<\/h3>\n
Die abschlie\u00dfende Systemebene erl\u00e4utern wir an dieser Stelle nicht n\u00e4her. Sie dient als \u00dcbergabepunkt f\u00fcr weitergehende, sich an die Anforderungsanalyse anschlie\u00dfende Entwicklungsphasen, in denen Anforderungsingenieure involviert sein k\u00f6nnen. Dies schlie\u00dft die Gestaltung grafischer Nutzerschnittstellen und die Definition einer Systemarchitektur ein.<\/p>\n
![\"Technologische](\"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2026\/01\/TORE2025-698x370.png\")
Abbildung 1: Das TORE-Rahmenwerk bietet die methodische Basis f\u00fcr den gezielten Einsatz von KI im Requirements Engineering.<\/figcaption><\/figure>\n Wer trifft die Entscheidungen \u2013 und wann?<\/h3>\n
Das TORE-Rahmenwerk macht Entscheidungen explizit und unterst\u00fctzt dabei, eine bewusste Entscheidungsfindung herbeizuf\u00fchren. Das Ziel ist es, fr\u00fchzeitig in der Konzeption einer Software einen Konsens im Projektteam zu erreichen, anstatt Entscheidungen implizit und (zu) sp\u00e4t im Projekt durch Programmiert\u00e4tigkeiten treffen zu lassen. In der Praxis geschieht zu oft genau das: Sp\u00e4testens eine Entwicklerin oder ein Entwickler legt fest, welche Datenfelder in einer Maske abgefragt werden. Doch wom\u00f6glich geschieht dies ohne Kenntnis \u00fcber Nutzergruppen und Nutzungsszenarien, und folglich mit falschen Annahmen. Diese f\u00fchren zu teuren, aber vermeidbaren Korrekturen.<\/p>\n
Die Ebenen in TORE geben eine Orientierung, welche Entscheidungen fr\u00fcher getroffen werden m\u00fcssen, weil sie sp\u00e4tere Entscheidungen beeinflussen. Hierbei gibt TORE keinen starren Prozess vor. Vielmehr unterst\u00fctzt es Anforderungsingenieurinnen und -ingenieure dabei, eine Vollst\u00e4ndigkeit aller relevanten Themen im Requirements Engineering zu erzielen: von abstrakten Zielen bis hin zu Systemfunktionen, die konkrete Anforderungen widerspiegeln.<\/p>\n
Wie unterst\u00fctzende KI im Requirements Engineering einsetzen?<\/h2>\n
Wir sind \u00fcberzeugt, dass weitreichende Entscheidungen \u00fcber die durch die Software erzielten Mehrwerte und damit deren Erfolgsaussichten nicht leichtfertig abgegeben werden d\u00fcrfen. Diese Aussage bedeutet jedoch nicht, dass nicht auch sinnvolle Einsatzm\u00f6glichkeiten f\u00fcr KI im Requirements Engineering bestehen. Die gibt es und wir geben zwei Beispiele:<\/p>\n
Generierung von Inhaltsvorschl\u00e4gen<\/strong><\/h3>\n
Mit ausreichend Kontextinformationen versehen, kann eine KI bei der Erstellung von Inhalten durch die Generierung von Vorschl\u00e4gen die Effizienz der Erstellung von Anforderungsdokumenten verbessern. So k\u00f6nnen (Proto-)Personas aus Stakeholder-Beschreibungen erstellt werden, Prozessdiagramme anhand von Interview-Transkripten oder Datenmodelle aus Prozessbeschreibungen. Hierbei gilt besonders, dass ein Mensch die Inhalte pr\u00fcft und letztlich die Entscheidungen f\u00e4llt, welche Stakeholder, Prozessschritte oder Daten in der Software unterst\u00fctzt werden.<\/p>\n
Qualit\u00e4tssicherung von Anforderungen<\/strong><\/h3>\n
Das Sprachverst\u00e4ndnis gro\u00dfer Sprachmodelle ausnutzend, kann eine KI pr\u00fcfen, ob zu allen Entscheidungspunkten bereits relevante Informationen dokumentiert sind. Eine automatisierte Pr\u00fcfung der Vollst\u00e4ndigkeit<\/strong> erlaubt eine Verfolgung des Fortschritts im Requirements Engineering eines Projekts. <\/em><\/p>\n
Genau hier setzt unsere L\u00f6sung \u00bbQuasar\u00ab<\/a> an:<\/b> Das Sprachverst\u00e4ndnis gro\u00dfer Sprachmodelle (LLMs) erm\u00f6glicht heute neue Wege f\u00fcr KI im Requirements Engineering. Durch den Einsatz von LLMs und etablierten Heuristiken erm\u00f6glicht Quasar Feedback aus virtuellen User-Tests bereits w\u00e4hrend der Anforderungsphase. Anstatt auf manuelle Tests zu warten, erhalten Designer und Engineers direkt in Tools wie Figma R\u00fcckmeldung zu ihren Entscheidungen. Auch innerhalb der Entscheidungspunkte k\u00f6nnen automatisiert Pr\u00fcfungen vorgenommen werden. Diese reichen von der Pr\u00fcfung der Korrektheit von Prozessmodellen<\/strong> hinsichtlich Notationen und Konventionen im Unternehmen bis hin zur Pr\u00fcfung inhaltlicher Konsistenz<\/strong> von Persona-Beschreibungen und Zielmodellen.<\/p>\n
Effizienzsteigerung durch Requirements Engineering<\/h2>\n
Gute Anforderungen sind nicht nur eine Zugabe, sondern entscheidend f\u00fcr den Erfolg von Software. Exzellentes Requirements Engineering<\/a> schafft die Grundlagen f\u00fcr die Realisierung von softwarebasierten Produkten, die tats\u00e4chliche Mehrwerte stiften und somit eine Chance auf nachhaltige Akzeptanz im Markt erhalten. Daf\u00fcr gibt es methodische Hilfsmittel, wie das vorgestellte TORE. Um bestm\u00f6gliches RE effizient zu gestalten, darf und soll selbstverst\u00e4ndlich auch KI eingesetzt werden. Bestm\u00f6glich bedeutet hierbei nicht, grenzenlos Ressourcen in die Dokumentation von Anforderungen zu investieren, sondern stets genau so viel, wie notwendig ist. In Zukunft bedeutet bestm\u00f6glich auch, dass die Voraussetzungen daf\u00fcr geschaffen sind, mit ausreichend Kontextinformationen Ans\u00e4tze wie Generative AI (\u00bbGenAI\u00ab) gewinnbringend einsetzen zu k\u00f6nnen.<\/p>\n
\nEffizienz-Boost mit Quasar<\/span><\/b>\u00a0W\u00e4hrend TORE die methodische Leitplanke bietet, automatisiert\u00a0Quasar<\/b> die Validierung. Durch virtuelle User-Tests nach jeder Designentscheidung reduzieren Sie Fehlerkosten massiv und steigern die User Experience, noch bevor die erste Zeile Code geschrieben ist. Mehr zu Quasar erfahren!<\/a><\/p>\n<\/div>\n
Schnelligkeit zu jedem Preis?<\/h3>\n
GenAI, insbesondere KI-basierte Programmierung, hat bereits Einzug in Unternehmen gehalten. Wir erwarten, dass die Nutzung von KI f\u00fcr diese T\u00e4tigkeit weiter zunehmen wird. Die Nutzung erlaubt immer k\u00fcrzere Iterationszyklen in Softwareentwicklungsprozessen. Sie bewirkt zudem, dass Anforderungen immer schneller, wom\u00f6glich sogar ungefiltert, in eine lauff\u00e4hige Software \u00fcberf\u00fchrt werden. Hierin liegen immense Chancen, und ebenso gro\u00dfe Risiken. Schnell zu sein, ist erfolgsentscheidend, doch das Richtige auf den Markt zu bringen, ist mindestens genauso bedeutsam.<\/p>\n
Wann und wie hilft KI im Requirements Engineering?<\/h3>\n
Um als Unternehmen also die Chancen der Effizienzsteigerung durch KI in der Entwicklung nutzen zu k\u00f6nnen, m\u00fcssen die Voraussetzungen daf\u00fcr in den Anforderungen geschaffen werden.<\/strong> Das bedeutet keinen R\u00fcckschritt in Zeiten, in denen die umfassende Spezifikation das Ziel war. Stattdessen kann und soll unter Verwendung agiler Entwicklungsans\u00e4tze, gepaart mit LLM-basierten KI-Ans\u00e4tzen und \u00bbAgentic AI\u00ab <\/a>in kurzen Iterationen das Feedback von Stakeholdern eingeholt werden \u2013 idealerweise zu bewusst getroffenen Entscheidungen, die effizient in einen Prototyp und lauff\u00e4hige Software \u00fcberf\u00fchrt wurden.<\/p>\n
Wie verhindern wir KI-Halluzinationen?<\/h3>\n
Am Fraunhofer IESE forschen wir an Werkzeugen und Methoden, sodass der Einsatz von KI als Hilfsmittel im Software Engineering zu qualitativ hochwertigen Ergebnissen f\u00fchrt. Ohne den richtigen Kontext, wie er beispielsweise durch ein Rahmenwerk wie TORE geschaffen wird, neigen KI-Modelle zu Halluzinationen. Wir sehen daher ein gutes Kontextmanagement<\/strong> als erfolgskritischen Faktor. Gleichzeitig sehen wir den Menschen als Entscheidungsinstanz an neuralgischen Punkten als weiterhin unverzichtbar und sehen in unserer Gestaltung von KI-unterst\u00fctzten Prozessen den \u00bbHuman-in-the-Loop\u00ab<\/strong> explizit vor.<\/p>\n
- Welche Stakeholder<\/strong> m\u00fcssen ber\u00fccksichtigt werden?<\/li>\n