Logo
5 min Lesezeit
← Alle Insights
AlpiType
Use Case 07 · Requirements Engineering · 2026
Anforderungsanalyse

Strukturierte Spezifikationen statt manuellem Interpretieren.

Anforderungen kommen als unstrukturierte PDFs, E-Mails und Ausschreibungsdokumente. Eine KI-gestützte Analyse liest, extrahiert und strukturiert — und liefert eine auditfähige Spezifikation vom ersten Tag an.

Use Case 07 — Requirements Engineering Geeignet für Defense, Luftfahrt (DO-178C), Medizintechnik (IEC 62304)
Zeitaufwand manuell
8–20h
pro RFP-Dokument
Mit KI-Analyse
< 2h
bis zur strukturierten Spec
Anforderungsfehler
56%
aller Projektdefekte entstehen hier
Nachbesserungskosten
10–100×
teurer in späteren Phasen
NIST · IBM Systems Sciences Institute · eigene Schätzungen Embedded & Safety-critical Systems

Jedes Projekt beginnt mit Anforderungen. Und fast jedes Projekt beginnt damit, dass diese Anforderungen unstrukturiert, widersprüchlich oder unvollständig ankommen. Ein Ausschreibungsdokument enthält auf 80 Seiten verteilt funktionale Anforderungen, Qualitätsziele, Schnittstellenbeschreibungen und regulatorische Vorgaben — ohne einheitliche Struktur, ohne Nummerierung, oft mit impliziten Annahmen, die nirgendwo explizit formuliert sind.

Erfahrene Ingenieure verbringen Stunden damit, dieses Material zu lesen, zu sortieren und zu interpretieren. Dabei entstehen zwei Probleme: Erstens werden Anforderungen übersehen, weil sie in einem Anhang vergraben oder in einer Fußnote erwähnt sind. Zweitens interpretieren verschiedene Ingenieure denselben Text verschieden — mit messbaren Folgen für Architekturentscheidungen, Testfälle und Abnahmekriterien.

56 Prozent aller Projektdefekte entstehen in der Anforderungsphase.

Das ist kein Qualitätsproblem einzelner Teams. Es ist ein strukturelles Problem: Natürliche Sprache ist mehrdeutig. Dokumente sind heterogen. Und manuelle Extraktion skaliert nicht — weder mit der Dokumentenlänge noch mit der Anzahl der Beteiligten.

Was eine KI-gestützte Analyse leistet

Ein KI-gestütztes Analysesystem liest das Eingangsdokument vollständig und systematisch. Es extrahiert funktionale Anforderungen — also das, was das System tun muss — und nicht-funktionale Anforderungen wie Verfügbarkeit, Latenz, Sicherheitsstufe oder Zertifizierungspflichten. Gleichzeitig identifiziert es Stellen, an denen Anforderungen einander widersprechen, wo Informationen fehlen oder wo Formulierungen zu vage sind, um testbar zu sein.

Das Ergebnis ist keine Zusammenfassung. Es ist eine strukturierte Spezifikation in einem definierten Format — mit eindeutigen Identifikatoren je Anforderung, kategorisiert, priorisiert und mit offenen Fragen versehen, die vor Projektbeginn geklärt werden müssen.

Nicht zusammenfassen. Strukturieren.

Der Unterschied ist entscheidend: Eine Zusammenfassung vereinfacht. Eine strukturierte Spezifikation macht jeden einzelnen Punkt nachvollziehbar, verlinkbar und auditierbar. Das ist der Standard, den regulierte Branchen voraussetzen — und den manuelle Prozesse selten zuverlässig erreichen.

Vom RFP-PDF zur strukturierten Spezifikation

Konkret sieht der Prozess so aus: Das Eingangsdokument — etwa eine Ausschreibung, ein technisches Lastenheft oder eine Kundenanforderung per E-Mail — wird als Input übergeben. Die Analyse liefert ein strukturiertes Dokument mit den folgenden Bestandteilen:

Eingang
  • RFP-Dokument (PDF)
  • Technisches Lastenheft
  • E-Mail-Anforderungen
  • Normen-Referenzen
Ausgang
  • Funktionale Anforderungen (nummeriert)
  • Nicht-funktionale Anforderungen
  • Liste offener Fragen
  • Risikohinweise und Widerspruchsmarker
  • Abnahmekriterien-Vorlage

Jede extrahierte Anforderung erhält eine eindeutige ID, eine Quelle im Ursprungsdokument (Seitenzahl, Abschnitt) und eine Kategorie. Anforderungen, die potenziell in Konflikt stehen, werden mit einem Flag markiert. Anforderungen, deren Testbarkeit fraglich ist, erscheinen in der Liste der offenen Fragen.

1
Vollständige Extraktion Alle funktionalen und nicht-funktionalen Anforderungen werden aus dem Dokument extrahiert — unabhängig davon, wo sie im Text erscheinen oder wie sie formuliert sind.
2
Widerspruchs- und Lückenanalyse Das System erkennt, wenn zwei Anforderungen einander ausschließen, wenn Schnittstellen beschrieben werden, ohne dass deren Gegenstelle definiert ist, oder wenn Leistungswerte fehlen.
3
Strukturierte Ausgabe im definierten Format Das Ergebnis folgt einem festgelegten Schema — kompatibel mit gängigen Requirements-Management-Werkzeugen und auditierbar nach geltenden Normen.
4
Abnahmekriterien-Vorlage Für jede Anforderung wird eine testbare Abnahmebedingung vorgeschlagen — als Grundlage für Testplanung und spätere Verifikation.

Compliance-Vorteil: Auditfähigkeit vom ersten Tag

In regulierten Bereichen ist die Anforderungsdokumentation kein internes Arbeitsmittel — sie ist Bestandteil des Zulassungsnachweises. Nach DO-178C (Software Considerations in Airborne Systems and Equipment Certification) müssen Softwareanforderungen vollständig, konsistent und testbar sein, bevor Designentscheidungen getroffen werden. Der Standard fordert explizit eine Rückverfolgbarkeit zwischen High-Level-Anforderungen, Low-Level-Anforderungen und Testfällen.

Nach IEC 62304 (Software lifecycle processes for medical device software) gilt dasselbe Prinzip: Jede Softwareanforderung muss identifizierbar, verifizierbar und änderungsverfolgbar sein. Lücken in der Anforderungsdokumentation führen direkt zu Lücken im Zulassungspaket — und damit zu Verzögerungen oder Zurückweisungen durch Behörden.

Eine KI-gestützte Analyse liefert die Grundstruktur, die beide Normen voraussetzen: eindeutige Bezeichner, Quellreferenzen, Kategorisierung und eine initiale Abnahmebedingung je Anforderung. Das ersetzt nicht die ingenieursseitige Prüfung — aber es stellt sicher, dass diese Prüfung auf einer vollständigen, konsistenten Datenbasis aufbaut, statt auf einem handschriftlich markierten PDF.

Im Defense-Bereich gilt dies analog. Projekte nach MIL-STD oder STANAG-Vorgaben erfordern eine nachvollziehbare Anforderungshistorie. Wer die strukturierte Spezifikation vom ersten Tag an in einem auditfähigen Format vorhält, spart Zeit in allen nachgelagerten Phasen — vom Design Review bis zur Abnahme durch den Auftraggeber.

Auditfähige Dokumentation vom ersten Tag — nicht erst vor der Abnahme.

Das ist kein Komfortgewinn. Es ist ein methodischer Unterschied: Wer Anforderungen nachträglich strukturiert, hat in der Zwischenzeit Entscheidungen auf einer unsicheren Grundlage getroffen. Wer sie von Anfang an strukturiert vorliegen hat, baut auf einer Basis, die trägt.

Use Case 07 — Teil unseres Requirements Engineering Service

Wir setzen KI-gestützte Anforderungsanalyse als strukturierten Schritt in unseren Requirements-Engineering-Prozess ein. Ergebnis: eine vollständige, auditfähige Spezifikation als Grundlage für Architektur, Test und Abnahme.

Ihr AlpiType Team Landsberg am Lech · alpitype.de
Ihr AlpiType Team · Landsberg am Lech · alpitype.de
Ihr AlpiType Team Landsberg am Lech · alpitype.de
← Alle Insights

Weiterführende Artikel

KI nutzen, ohne Daten in die Cloud zu schicken

On-premise KI: Wie Systeme vollständig lokal betrieben werden.

Sind Ihre Daten überhaupt für KI nutzbar?

Datenqualität prüfen, bevor Sie in KI investieren.

Was KI in einem realen Industrieprojekt kostet

Konkrete Zahlen, Phasen und ROI aus realen Projekten.

Nicht sicher, ob das auf Ihren Fall zutrifft?

Wir prüfen Ihr Setup in 2 Wochen und sagen Ihnen, ob KI machbar ist.

Machbarkeits-Audit anfragen →

Sprechen Sie mit einem Ingenieur

Kein Vertrieb. Sie sprechen direkt mit einem unserer Software-Architekten über Ihr konkretes Problem. 30 Minuten. Antwort innerhalb von 24 Stunden.

Email: info@alpitype.com

LinkedIn: AlpiType

Anton Lytvynenko

Anton Lytvynenko

CEO, AlpiType

Unsere Geschichte →