Sie müssen weder von Word auf Polarion noch von Polarion auf DOORS migrieren, um KI im Anforderungswesen einzusetzen. Die App liest Ihre vorhandenen Quellen, vernetzt die Inhalte ontologisch und schreibt Ergebnisse zurück in die Werkzeuge Ihrer Wahl.
In den meisten Engineering-Organisationen ist „das Anforderungsmanagement" weniger ein System als ein Zustand. Marketing schreibt das Lastenheft in Word, die System-Engineers überführen es in Polarion, die Software-Teams arbeiten mit DOORS, die Mechanik-Kolleg:innen halten ihre Spezifikation in Excel, und der Hauptlieferant schickt seine Anforderungen als PDF. Jede dieser Quellen ist für sich genommen sinnvoll. Zusammen ergeben sie eine Landschaft, in der niemand mehr sicher sagen kann, welche Anforderung wo verbindlich ist.
Das Problem ist nicht das Werkzeug, sondern die Lücke zwischen den Welten. Bisher ließ sich diese Lücke nur durch manuelle Pflege überbrücken.
Requirements Gen arbeitet auf vier Stellen, gespeist aus dem gemeinsamen Product Knowledge Graph. Anforderungen verlassen ihre ursprüngliche Quelle nicht, bleiben aber miteinander verbunden.
Anforderungen aus Word, Excel, SharePoint, PDF, Polarion, DOORS Next Generation, Codebeamer oder Jama Connect werden über Konnektoren eingelesen, ontologisch strukturiert und gegen Funktionen, Komponenten und Tests im Graphen verlinkt.
Aus einem Freitext-Lastenheft entstehen einzelne, atomar formulierte Anforderungen mit Identifikatoren, Typen (funktional, nicht-funktional, Constraint) und Akzeptanzkriterien.
Prüfung gegen EARS-Syntax, Atomarität, Testbarkeit, Eindeutigkeit und Vollständigkeit; Lücken und Widersprüche werden mit konkreten Verbesserungsvorschlägen markiert.
Das Ergebnis fließt entweder zurück in die ursprüngliche Quelle oder in ein zentrales Ziel (typisch: Polarion), inklusive standardkonformer Strukturierung und vollständigem Audit Trail.
Aus einem Word-Lastenheft („Das System soll bei aktiviertem Tempomat den Sicherheitsabstand einhalten, gemäß ISO 26262 ASIL-B") leitet die KI mehrere atomare, testbare Anforderungen ab, jeweils mit ID, ASIL-Bezug und Vorschlag für die Akzeptanzkriterien.
EARS-Syntax, Atomarität (eine Aussage pro Anforderung), Testbarkeit (objektive Akzeptanzkriterien), Widerspruchsfreiheit, Vollständigkeit nicht-funktionaler Aspekte (Performance, Security, Compliance).
Anforderungen werden automatisch mit ihren wahrscheinlichen Bezugspunkten verlinkt: Funktionen in der Architektur, Komponenten in der Stückliste, vorhandene Testfälle, relevante Norm-Abschnitte, Vorschläge mit Begründung, die Sie bestätigen oder ablehnen.
Überführung zwischen Detaillierungsgraden (Stakeholder → System → Software), Übersetzung zwischen Sprachen, Export im ReqIF-Standard für den werkzeugübergreifenden Austausch mit Zulieferern und Kunden.
Auf der Quellseite: DOORS Next Generation, Siemens Polarion, Codebeamer und Jama Connect bidirektional, sowie Microsoft Word, Excel, SharePoint und PDF-Lastenhefte von Kunden und Zulieferern. Auch E-Mails und Confluence-Seiten lassen sich anbinden, sofern sie konsequent gepflegt werden.
Auf der Zielseite stehen dieselben Werkzeuge zur Verfügung. Strukturierte Requirements werden entweder zurück in die Ursprungsquelle geschrieben (Word-Lastenheft, ergänzt um IDs und Querverweise) oder in ein zentrales Repository (Polarion, DOORS) überführt. Für den firmenübergreifenden Austausch nutzt die App den ReqIF-Standard.
Anonymisiertes Automotive-Projekt: Ausgangsmaterial ist eine Sammlung von Markdown- und PDF-Dokumenten zum Bremsensystem (Übersicht, Architektur, Use Cases, funktionale Anforderungen) plus ein C/C++-Code-Auszug der existierenden ABS/ESC-Steuerung. Ziel ist eine standardkonforme Polarion-Spezifikation für das Wheel-Speed-Monitoring-Subsystem.
Im ersten Schritt extrahiert die App aus Dokumenten und Code die relevanten Entitäten (Use Cases, Subsysteme, Funktionen, Komponenten, Signale, Anforderungen), verankert sie im Knowledge Graph und validiert gegen die Engineering-Ontologie. Im zweiten Schritt nimmt sie eine fachliche Abfrage entgegen („Erzeuge die funktionale Spezifikation für das Wheel-Speed-Monitoring-Subsystem mit allen zugehörigen Requirements") und komponiert daraus zwei Polarion-Artefakte: eine funktionale Spezifikation mit allen Akzeptanzkriterien und ein Architektur-Kapitel mit den beteiligten Komponenten und Schnittstellen.
Das Resultat ist kein einmaliger Import, sondern ein dauerhaft verbundenes System: Ändert sich später eine Anforderung im Markdown oder direkt in Polarion, propagiert die Änderung über den Graphen, und betroffene Architektur-, Test- und Safety-Artefakte werden markiert.
Sie behalten Ihre Word-Lastenhefte und Excel-Trace-Listen. Die App liest sie ein, strukturiert sie ontologisch und schreibt das Ergebnis bei Bedarf zurück, etwa als angereicherte Tabelle mit IDs, Status und Querverweisen. Das vorhandene Wissen bleibt, wo es liegt, und wird gleichzeitig in eine maschinenlesbare Form überführt, an der KI-Apps und Audits arbeiten können.
Wenn Sie zu einem späteren Zeitpunkt zu einem klassischen RM-Werkzeug migrieren möchten (Polarion, DOORS Next Generation, Codebeamer), ist die App die natürliche Brücke: Die ontologische Struktur im Graphen lässt sich direkt in das Ziel-Werkzeug exportieren. Sie sparen sich die berüchtigte Datenmigration „aus Excel in Polarion", die in vielen Projekten mehr Aufwand verursacht hat als die Tool-Einführung selbst.
Für Teams, die heute schon mit DOORS oder Polarion arbeiten, gilt das Spiegelbild: Die App ist die KI-Schicht über dem bestehenden Werkzeug, keine Konkurrenz. Bestehende Modulstrukturen, Workflows und Zugriffsrechte bleiben unberührt.
Anforderungen sind die Stelle, an der ein Unternehmen seine Verpflichtungen gegenüber Kunden, Behörden und Mitarbeitenden in eine maschinenlesbare Form gießt. Damit tragen sie Geschäfts- und Haftungsverantwortung, die nicht an ein Sprachmodell delegiert werden kann. Requirements Gen ist als Vorschlagsmaschine konzipiert, nicht als Entscheidungsinstanz: Die App strukturiert, prüft, schlägt vor und macht Konsistenzlücken sichtbar. Die fachliche Freigabe trifft die Requirements-Engineerin oder der Requirements-Engineer. Jede KI-generierte oder KI-veränderte Anforderung trägt im Graphen eine Provenance-Information, wer hat sie wann erzeugt oder bestätigt, auf welcher Quelle basiert sie, welche Modell-Version war beteiligt. Diese Nachvollziehbarkeit ist die Voraussetzung dafür, dass die App in regulierten Branchen Teil einer Compliance-Argumentation werden kann.
Voraussetzung ist weder ein vorhandenes RM-Tool noch eine bestimmte methodische Reife. Wenn Sie heute mit Word arbeiten, fangen wir mit Word an. Wenn Sie in Polarion sind, lesen wir Polarion.
In den ersten zwei Wochen werden die vorhandenen Quellen angebunden (Word, Excel, Polarion, DOORS, je nachdem was da ist) und der Knowledge Graph für den gewählten Bereich aufgebaut. Bereits dabei werden Lücken in der Traceability sichtbar.
Strukturierung, Qualitätsprüfung, Anreicherung, Veröffentlichung, für ein laufendes Projekt mit klar umrissenem Subsystem und definiertem Lastenheft.
Weitere Subsysteme, weitere Projekte, tiefere Automatisierung. Die einzige strukturelle Voraussetzung ist die Bereitschaft, KI-Vorschläge konsequent zu prüfen und Feedback ins System zurückzugeben.
Strukturierte, ontologisch verlinkte Anforderungen sind die Voraussetzung dafür, dass aus ihnen automatisiert eine funktionale Systemarchitektur abgeleitet werden kann. Der Architecture Creator setzt direkt auf Requirements Gen auf.
Mehr zur KI-SystemarchitekturNein. Die App ist als bidirektionale Schicht über Ihren bestehenden Werkzeugen konzipiert. Sie liest aus DOORS Next Generation, Siemens Polarion und Codebeamer, schreibt Änderungen zurück und respektiert die dort vorhandenen Workflows, Zugriffsrechte und Modulstrukturen. Wenn Ihre Teams in DOORS oder Polarion produktiv sind, bleiben sie dort.
Konnektoren lesen Word-Lastenhefte und Excel-Tabellen direkt ein. Requirements Gen extrahiert die einzelnen Anforderungen, weist ihnen Identifikatoren und Typen zu, prüft die Qualität und verknüpft sie mit Funktionen, Komponenten und Tests im Knowledge Graph. Das Ergebnis kann entweder zurück in die ursprüngliche Datei geschrieben werden (angereichert um IDs und Querverweise) oder in ein zentrales Repository wie Polarion überführt werden.
ReqIF (Requirements Interchange Format) ist der OMG-Standard für den werkzeugübergreifenden Austausch von Anforderungen. Sie brauchen ihn dann, wenn Sie Anforderungen mit Zulieferern oder Kunden austauschen, die andere RM-Werkzeuge verwenden. Requirements Gen exportiert und importiert ReqIF, sodass dieser Austausch verlustfrei läuft.
Requirements Gen ersetzt DOORS Next Generation nicht, sondern legt eine KI-Schicht darüber. Teams, die DOORS produktiv nutzen, behalten ihre gewohnte Arbeitsumgebung und gewinnen Strukturierung, Qualitätsprüfung und Cross-Tool-Traceability.
Deutsch und Englisch sind vollständig unterstützt, einschließlich der Strukturierung aus Freitext und der EARS-Qualitätsprüfung. Französisch, Italienisch und Spanisch werden für Importe und Übersetzungen unterstützt. Mehrsprachige Projekte (typisch im DACH-Raum mit internationalen Zulieferern) werden ohne separaten Tool-Wechsel abgedeckt.
Die App läuft auf der Engineering Intelligence Platform, die als Self-Hosted-, Private-Cloud- oder dedizierte SaaS-Variante betrieben werden kann. Anforderungen verlassen Ihre Umgebung nicht. Sprachmodell-Anfragen werden über ein zentrales, kontrollierbares Gateway abgewickelt, sodass Sie die Wahl des Modells und die Datenflüsse vollständig steuern.
Sehen Sie in einer 30-minütigen Demo, wie Requirements Gen mit Ihrer aktuellen Anforderungslandschaft arbeitet. Bringen Sie gerne ein anonymisiertes Lastenheft, einen Polarion-Auszug oder eine DOORS-Modul-Übersicht mit, dann wird die Demo direkt an Ihrem Beispiel konkret.