Anforderungen vs. Spezifikationen: Warum die Unterscheidung auf der Empfängerseite wichtiger ist

Einleitung

Die meisten Ingenieure, die mit Kundenspezifikationen arbeiten, kennen den Unterschied zwischen Anforderungen und Spezifikationen. Anforderungen definieren, was ein System leisten muss. Spezifikationen definieren, wie es gebaut wird. In der Theorie ist diese Unterscheidung klar.

Kompliziert wird es in der Lieferkette.

Wenn ein Kunde ein 400-seitiges Lastenheft (URS) an einen Lieferanten sendet, enthält dieses Dokument Anforderungen aus Sicht des Kunden. Die Aufgabe des Lieferanten besteht darin, auf diese Anforderungen mit einem technischen Angebot und schließlich mit einem Produkt zu reagieren. Das interne Ingenieurteam des Lieferanten erstellt dann Spezifikationen, die festlegen, wie das Produkt gebaut wird, um die Kundenwünsche zu erfüllen.

Der Lieferant befindet sich also an der Schnittstelle zweier Welten: Auf der einen Seite stehen die vom Kunden vorgegebenen Anforderungen, auf die er reagieren muss; auf der anderen Seite die internen Spezifikationen, nach denen die eigenen Ingenieure arbeiten müssen.

‍

„Die Verwirrung zwischen Anforderungen und Spezifikationen auf der Empfängerseite ist nicht konzeptioneller Natur. Ingenieure kennen den Unterschied. Das Problem ist, dass die meisten Tools und Prozesse beides als dasselbe behandeln, wodurch die Grenze in der Praxis verschwimmt.“

— Anuraj Suman, Principal AI Engineer, Booma

Eine falsche Grenzziehung hat reale Konsequenzen. Sie bestimmt, welches Tool das jeweilige Dokument verwaltet, wer der Eigentümer ist, wie das Ergebnis für den Kunden aussieht und wer bei Problemen haftet.

‍

[KEY TAKEAWAYS]

• Anforderungen definieren, was ein System leisten muss. Spezifikationen definieren, wie es gebaut wird, um dies zu erreichen. Diese Unterscheidung gilt sowohl auf der Ersteller- als auch auf der Empfängerseite.
• Auf der Empfängerseite enthält das vom Kunden ausgestellte Lastenheft (URS), die Angebotsanfrage (RFQ) oder die Ausschreibung (ITT) die Anforderungen. Ihre internen technischen Dokumente, die festlegen, wie Sie diese erfüllen, sind Spezifikationen.
• Tools wie DOORS und Jama wurden entwickelt, um die Spezifikationen zu verwalten, die Ihr Ingenieurteam erstellt. Booma wurde entwickelt, um die Anforderungen zu verwalten, die Ihre Kunden Ihnen senden.
• Die Compliance-Matrix bildet die Schnittstelle: Sie ist Ihre strukturierte Antwort auf die Kundenanforderungen, noch bevor Ihre Spezifikationen existieren.
• Die Rückverfolgbarkeit über diese Grenze hinweg – von der Kundenanforderung über Ihre Compliance-Antwort bis hin zu Ihrer internen Spezifikation – ist die Kette, die bei der Werksabnahme (FAT) Bestand hat.

Was Anforderungen sind

Eine Anforderung legt fest, was ein System leisten, erreichen oder erfüllen muss, ohne vorzuschreiben, wie. Sie ist aus der Perspektive eines Bedarfs geschrieben: ein Leistungsniveau, ein Sicherheitsgrenzwert, eine regulatorische Verpflichtung oder ein Nutzerergebnis. Der Test für eine gut formulierte Anforderung ist, dass mehrere technisch gültige Lösungen sie erfüllen könnten.

Auf der Empfängerseite gehen Anforderungen in Dokumenten ein, die der Kunde kontrolliert: ein Lastenheft (URS), eine Angebotsanfrage (RFQ), eine Ausschreibung (ITT), eine technische Beschaffungsspezifikation oder ein Lieferantenhandbuch. Der Kunde besitzt diese Dokumente. Der Kunde entscheidet, wann sie geändert werden und was in der neuen Version steht. Ihre Aufgabe ist es, darauf zu reagieren.

Sie haben diese Anforderungen nicht verfasst. Sie können sie nicht umschreiben. Sie können sie nicht aufschieben. Sie bewerten, ob Sie diese erfüllen können, dokumentieren Ihren Compliance-Status und stehen während der gesamten Projektlaufzeit zu dieser Position.

‍

Was Spezifikationen sind

Eine Spezifikation definiert, wie ein System gebaut wird, um die geforderten Anforderungen zu erfüllen. Sie ist aus der Perspektive einer Lösung geschrieben: die technischen Entscheidungen, Materialauswahl, Maßtoleranzen, Algorithmenimplementierungen, Komponentenauswahl und Schnittstellendefinitionen, die eine Anforderung in etwas Baubares übersetzen.

Auf der Empfängerseite sind Spezifikationen Dokumente, die Ihr Unternehmen kontrolliert: Ihre Standardproduktspezifikation, Ihre technischen Konstruktionsunterlagen, Ihre Testspezifikationen, Ihre Fertigungsdokumentation. Ihre Ingenieure schreiben sie, Ihr interner Prüfprozess genehmigt sie und Ihr Änderungsmanagement verwaltet sie.

Dies sind die internen Dokumente, die Ihre Compliance-Aussagen belegen. Wenn in der Compliance-Matrix „Vollständig konform“ steht und auf IS-1234 Abschnitt 4.2 verwiesen wird, ist IS-1234 eine Spezifikation. Sie ist Ihr Nachweis.

‍

Wo die Grenze auf der Empfängerseite verläuft

Die Grenze lässt sich am einfachsten anhand der Dokumentenverantwortung erkennen.

Das vom Kunden herausgegebene URS ist ein Anforderungsdokument. Der Kunde kontrolliert es. Wenn es sich ändert, entscheidet der Kunde. Ihre Verpflichtung ist es, auf jeden Punkt zu reagieren.

Ihre Compliance-Matrix ist Ihre strukturierte Antwort auf die Anforderungen des Kunden. Sie kontrollieren sie auf Ihrer Seite, der Kunde erhält sie, und bei Vertragsvergabe wird sie üblicherweise zu einem Vertragsanhang. Sie befindet sich auf der Anforderungsebene: Sie adressiert die Anforderungen des Kunden, ohne bereits festzulegen, wie Ihre Technik diese erfüllen wird.

Ihre interne Produktspezifikation ist ein Spezifikationsdokument. Sie kontrollieren es. Es definiert, wie Ihr Produkt gebaut wird. Es ist der Nachweis, der Ihre Compliance-Aussagen stützt. Wenn in der Compliance-Matrix „Vollständig konform“ steht, ist Ihre Spezifikation das, womit die vollständige Konformität erreicht wird.

Die Rückverfolgbarkeitskette, die diese verbindet, verläuft von der Kundenanforderung über die Compliance-Antwort bis hin zur internen Spezifikation. Diese Kette ist der Audit-Nachweis bei der FAT. Beide Enden müssen existieren und die Verbindung zwischen ihnen muss gepflegt werden.

‍

Warum die Unterscheidung kommerziell wichtig ist

Eine falsche Grenzziehung führt zu Problemen, die zum ungünstigsten Zeitpunkt auftreten.

Kundenanforderungen als eigene Spezifikationen behandeln. Manche Teams reagieren auf ein Kunden-URS, indem sie dessen Klauseln in ihre internen technischen Dokumente kopieren, als wären es ihre eigenen Spezifikationen. Die Klauseln wurden vom Engineering-Team des Kunden für den Kontext des Kunden geschrieben. Sie lassen sich möglicherweise nicht sauber auf die Konstruktion Ihres Produkts übertragen. Konflikte treten während der Konstruktion auf und niemand weiß, ob diese durch eine Änderung der Konstruktion oder durch Rücksprache mit dem Kunden gelöst werden sollen.

Eigene Spezifikationen als Kundenanforderungen behandeln. Manche Teams reagieren auf ein Kunden-URS mit der Behauptung, ihre Standardproduktspezifikation decke bereits alles ab, ohne tatsächlich nachzuverfolgen, welche Kundenklauseln ihre Spezifikation abdeckt und welche nicht. Die Compliance-Matrix sieht vollständig aus. Die Lücken zeigen sich bei der FAT.

Grenzenloses Chaos im Tool-Management. DOORS, Jama und Polarion sind darauf ausgelegt, Anforderungen und Spezifikationen zu verwalten, die von Ihrem eigenen Engineering-Team erstellt wurden. Dafür sind sie hervorragend geeignet. Sie wurden jedoch nicht dafür entwickelt, ein kundenseitiges URS einzulesen, dessen Klauseln zu extrahieren und Ihre Compliance-Antwort für jede einzelne davon zu verwalten. Teams, die versuchen, Tools für die Erstellung für die Empfangsseite zu nutzen, landen bei einer Notlösung, die nur so lange funktioniert, bis sie es nicht mehr tut.

‍

„Die Diskrepanz bei den Tools ist die Hauptursache für die praktische Verwirrung. Teams nutzen DOORS, um ihre eigenen Produktanforderungen zu verwalten, und versuchen dann, das Kunden-URS in dieselbe Struktur zu importieren. Diese beiden Dinge gehören nicht in dieselbe Datenbank, da das eine von Ihnen erstellt wurde und das andere etwas ist, worauf Sie reagieren müssen.“

— Anuraj Suman, Principal AI Engineer, Booma

‍

Wie die beiden Seiten zusammenarbeiten

Anforderungen und Spezifikationen stehen nicht in Konkurrenz zueinander. Sie sind miteinander verbunden. Die Kette sieht wie folgt aus.

Der Kunde stellt ein URS aus. Es enthält Anforderungen: was Ihr geliefertes System leisten muss.

Sie extrahieren jede Klausel, klassifizieren sie und entwerfen eine Compliance-Antwort in Ihrer Compliance-Matrix. Die Matrix arbeitet auf der Ebene der Anforderungen: Sie adressiert die Anforderungen des Kunden, ohne bereits festzulegen, wie Ihr Engineering diese erfüllen wird.

Ihr Engineering-Team übersetzt Ihre Compliance-Zusagen in interne Spezifikationen: Designdokumente, Testpläne, Fertigungsanweisungen. Diese Spezifikationen definieren, wie Sie tatsächlich ein System bauen, das die in der Matrix gemachten Zusagen erfüllt.

Die Rückverfolgbarkeit verknüpft jede Kundenklausel über Ihre Compliance-Antwort mit der internen Spezifikation, die sie umsetzt, und dem Testschritt, der sie verifiziert. Dies ist die Kette, der FAT-Ingenieure folgen.

Jedes Glied dieser Kette erfordert ein Tool. Booma verwaltet die Empfangsseite: von der Kundenklausel über die Compliance-Antwort bis hin zur Compliance-Matrix. Ihre Engineering-Tools (DOORS, Jama, Ihre CAD- und PLM-Umgebung) verwalten die Spezifikationsseite: von Ihren Compliance-Zusagen über das Design bis hin zum Test. Die beiden Tools müssen an der Übergabestelle miteinander verbunden werden: bei der akzeptierten Compliance-Zusage, die Ihre interne Spezifikation steuert.

‍

Häufige Fehlerquellen

Compliance-Zusagen, die nicht auf interne Spezifikationen zurückführbar sind

Die Compliance-Matrix gibt „Vollständig konform“ an. Das interne Engineering-Team war sich der spezifischen Zusage nicht bewusst. Niemand hat die Compliance-Position in eine Spezifikationsanforderung für das Design-Team übersetzt. Das Produkt wird gemäß der Standardspezifikation gebaut. Die spezifische Kundenanforderung, zu der sich die Matrix verpflichtet hat, wird im Design nie berücksichtigt.

Interne Spezifikationen, die von Compliance-Zusagen abweichen

Die Compliance-Matrix wird eingereicht. Während der Projektdurchführung nimmt das Engineering-Team Designänderungen vor. Einige dieser Änderungen wirken sich auf die in der Compliance-Matrix gemachten Leistungszusagen aus. Niemand aktualisiert die Matrix. Bis zum FAT sind die eingereichte Compliance-Position und die tatsächliche Produktleistung auseinandergedriftet.

Kunden-URS-Klauseln werden im falschen Tool verwaltet

Ein Team nutzt DOORS sowohl für die Verwaltung der eigenen Produktanforderungen als auch für die vom Kunden bereitgestellten URS-Klauseln. Das Tool ist für Letzteres nicht ausgelegt. Die Extraktion erfolgt manuell. Der Compliance-Workflow ist eine Notlösung. Die Verknüpfung zwischen Kundenklausel und interner Spezifikation basiert auf Konventionen statt auf dem Tool und bricht unter Projektdruck zusammen.

Spezifikationen werden an Kunden übermittelt statt Compliance-Antworten

Einige Teams reagieren auf eine Kunden-URS, indem sie ihre interne Produktspezifikation senden, anstatt eine strukturierte Compliance-Matrix zu verwenden. Der Kunde muss die Spezifikation durcharbeiten, um zu beurteilen, welche Klauseln abgedeckt sind. Lücken bleiben unsichtbar. Diese Dokumentationspraxis bürdet dem Kunden die Last der Compliance-Bewertung auf und führt zu Streitigkeiten darüber, was zugesagt wurde.

‍

Vorteile der Trennung

[TABLE]

Vorteil

• Klare Verantwortlichkeiten
• Das richtige Werkzeug für jede Aufgabe
• Verteidigbare Compliance-Positionen
• Kontrolliertes Änderungsmanagement
• Audit-sichere Rückverfolgbarkeit

Was das in der Praxis bedeutet

• Kundenanforderungen werden vom Bid-Engineering-Team verwaltet. Interne Spezifikationen werden vom Engineering-Team verwaltet. Keines der Teams greift ohne formale Übergabe in den Bereich des anderen ein.
• Tools auf der Empfängerseite verwalten Kundenanforderungen und Compliance-Antworten. Tools auf der Erstellerseite verwalten interne Spezifikationen. Jedes Tool erfüllt seine Aufgabe ohne Umwege.
• Compliance-Aussagen lassen sich auf die internen Spezifikationen zurückführen, die sie belegen. Beim FAT ist die Kette von der Kundenklausel bis zum Nachweis lückenlos.
• Wenn der Kunde eine Anforderung ändert, übernimmt der Prozess auf der Empfängerseite die Überarbeitung. Wenn interne Designänderungen eine Compliance-Zusage betreffen, löst die Aktualisierung der Spezifikation eine Überprüfung der entsprechenden Compliance-Antwort aus.
• Die Kette von der Kundenklausel über die Compliance-Antwort und die interne Spezifikation bis hin zum FAT-Testschritt bildet den Compliance-Audit-Trail, den regulierte Beschaffungsprozesse erfordern.

Beispiel aus der Praxis

CIMC Pteris, Asiens größter Integrator für Flughafenlogistik, arbeitet mit Kundenspezifikationen, die zu den komplexesten der Branche zählen. Die eingehenden URS-Dokumente verweisen regelmäßig auf über sieben EN-ISO-Normen gleichzeitig, verteilt auf mehrere hundert Seiten.

Die Engineering-Teams erstellen interne Spezifikationen für die von ihnen entworfenen und installierten Systeme. Dabei handelt es sich um eigene technische Dokumente, die über ihre internen Design-Review- und Änderungskontrollprozesse verwaltet werden.

Die größte Herausforderung besteht darin, die Lücke zwischen den Anforderungen in der URS des Kunden und den internen technischen Spezifikationen zu schließen. Eine Kundenklausel, die die Einhaltung der EN ISO 12100 fordert, muss von der URS über die Compliance-Matrix bis hin zur spezifischen Konstruktionsdokumentation, die diese umsetzt, und dem Prüfprotokoll, das sie verifiziert, nachvollziehbar sein.

Vor Booma wurde diese Kette manuell gepflegt und riss vor allem bei Revisionen ab: Wenn ein Kunde eine neue URS-Version herausgab, erforderte die Identifizierung der betroffenen Compliance-Verpflichtungen und internen Spezifikationen einen manuellen Abgleich über verschiedene Dokumententypen hinweg.

Seit der Einführung von Booma wird die Empfangsseite dieser Kette automatisch verwaltet. Kundenklauseln werden extrahiert, klassifiziert und in einer strukturierten Umgebung mit Compliance-Antworten verknüpft. Die Übergabe an das interne Engineering ist nun sauber: eine akzeptierte Compliance-Verpflichtung mit dem spezifischen internen Nachweis.

Gustav Ryan, Operations Director bei CIMC Pteris: „Wenn ein Kunde mitten im Projekt eine Änderungsanforderung stellt, haben wir früher Tage damit verbracht, diese durch alle Dokumente zu verfolgen. Mit Booma können wir noch am selben Tag mit einer fundierten, prüfungssicheren Antwort reagieren.“

‍

Was sich durch KI verändert hat

Die manuelle Pflege dieser Schnittstelle bedeutete, Kundenklauseln von Hand mit internen Nachweisen zu verknüpfen – ein Prozess, der mit steigendem Auftragsvolumen immer langsamer und fehleranfälliger wurde. Zwei spezifische Funktionen haben dies grundlegend geändert.

Semantische Klassifizierung bei der Extraktion. KI kann heute eine Kundenklausel lesen und beurteilen, ob es sich eher um eine funktionale Anforderung, eine Leistungsanforderung, eine regulatorische Vorgabe oder eine Spezifikation handelt, die als Anforderung getarnt ist. Klauseln, in denen der Kunde faktisch bereits eine Spezifikation geschrieben hat (indem er eine bestimmte Komponente, Technologie oder einen Implementierungsansatz vorgibt), werden zur Überprüfung markiert, anstatt sie ungeprüft als Anforderung auf Antwortebene zu akzeptieren.

Dokumentübergreifende Ähnlichkeitsanalyse. Die KI kann die interne Spezifikation ermitteln, die eine neue Kundenklausel am wahrscheinlichsten abdeckt – basierend auf der semantischen Ähnlichkeit zu früheren Compliance-Antworten und den zitierten Nachweisdokumenten. Die Verknüpfung von Kundenanforderung zu interner Spezifikation, für die früher Expertenwissen erforderlich war, hat nun einen vorgeschlagenen Ausgangspunkt.

‍

[TABLE]

Traditionell

• Klassifizierung von Anforderungen vs. Spezifikationen durch manuelle Prüfung
• Interne Nachweise werden durch Expertenwissen gefunden
• Verknüpfungen zwischen Anforderungen und Spezifikationen werden manuell gepflegt
• Schnittstelle wird durch Konvention aufrechterhalten

KI-gestützt

• KI-Klassifizierung erkennt Klauseln auf Spezifikationsebene in Kundendokumenten
• Vorschläge für Nachweise basierend auf Ähnlichkeitsbewertungen aus früheren Angeboten
• KI-gestützte Verknüpfung von Kundenklauseln mit internen Nachweisen
  
• Durch Tool-Struktur definierte Abgrenzung

Wie Booma Sie unterstützt

Booma verwaltet die Eingangsseite der Schnittstelle zwischen Anforderungen und Spezifikationen: vom Eingang des Kundendokuments über die Extraktion, Klassifizierung und Compliance-Antwort bis hin zur Einreichung der Compliance-Matrix.

Jede Kundenklausel in Booma ist eine empfangene Anforderung. Das Tool ist speziell auf die Aufgaben der Eingangsseite ausgerichtet: Klauseln extrahieren, Compliance-Antworten verwalten, Revisionshistorien pflegen und frühere Nachweise bereitstellen.

Die Übergabe von Booma an Ihre Authoring-Tools erfolgt mit der akzeptierten Compliance-Zusage. Eine von Ihrem Engineering-Team akzeptierte Compliance-Position enthält bereits den Nachweisverweis, die zitierte interne Spezifikation und die Compliance-Historie. Dies bildet den Ausgangspunkt für Ihren internen Engineering-Prozess – nicht eine Kundenklausel, die erst neu interpretiert werden muss.

DOORS und Jama verwalten das, was Ihr Engineering-Team erstellt. Booma verwaltet das, was Ihre Kunden Ihnen senden. Zusammen decken sie beide Seiten dieser Schnittstelle ab.

Booma wird in Deutschland gehostet, ist ISO 27001-zertifiziert, DSGVO-konform und verwendet keine Kundendaten zum Training von KI-Modellen.

‍

Demo buchen →

[FAQ]

Was ist der Unterschied zwischen Anforderungen und Spezifikationen?

Anforderungen definieren aus der Perspektive eines Bedarfs, was ein System leisten muss. Spezifikationen definieren aus der Perspektive einer technischen Lösung, wie ein System gebaut wird, um diese Anforderungen zu erfüllen. Auf der Eingangsseite kommen Anforderungen von Ihren Kunden. Spezifikationen stammen von Ihrem eigenen Engineering-Team.

Warum ist diese Unterscheidung gerade auf der Eingangsseite so wichtig?

Weil Sie auf der Eingangsseite Dokumente verwalten, die Sie nicht selbst erstellt haben und nicht ändern können (Kundenanforderungen), sowie Dokumente, die Ihr eigenes Team verfasst hat (interne Spezifikationen). Werden diese im selben Tool, im selben Prozess oder vom selben Team vermischt, entstehen Verantwortlichkeitslücken und Probleme bei der Rückverfolgbarkeit, die spätestens bei der Werksabnahme (FAT) zutage treten.

Wie verhält sich die Compliance-Matrix zu Anforderungen und Spezifikationen?

Die Compliance-Matrix ist Ihre strukturierte Antwort auf Kundenanforderungen. Sie operiert auf der Ebene der Anforderungen: Sie adressiert jede Kundenklausel, ohne bereits festzulegen, wie Ihr Engineering diese umsetzen wird. Ihre internen Spezifikationen dienen dabei als Nachweis, der die Compliance-Aussagen in der Matrix belegt.

Welche Tools verwalten die jeweilige Seite der Schnittstelle?

Authoring-Tools wie DOORS, Jama, Polarion und Visure verwalten die Anforderungen und Spezifikationen, die Ihr Engineering-Team erstellt. Booma verwaltet die Anforderungen, die Sie von Ihren Kunden erhalten. Es handelt sich nicht um konkurrierende Tools. Sie decken unterschiedliche Seiten derselben Lieferkette ab.

Was passiert, wenn eine Klausel in einer Kundenspezifikation eigentlich eine Designvorgabe ist?

Manche Kunden schreiben Klauseln, die eine bestimmte Technologie, Komponente oder einen Implementierungsansatz vorgeben, anstatt eine Leistungsanforderung zu definieren. Dies sind Vorgaben auf Spezifikationsebene, die in einem Anforderungsdokument eingebettet sind. Auf der Empfängerseite müssen Sie diese zwar ebenfalls bearbeiten, sie sollten jedoch gekennzeichnet werden: Sie schränken Ihren Lösungsspielraum ein und können mit Ihrem Standardproduktdesign kollidieren.

[NEXT STEPS]

Möchten Sie verstehen, wie die Compliance-Matrix korrekt erstellt und dokumentiert wird?
Der Leitfaden zur Anforderungsdokumentation behandelt die Compliance-Matrix als Liefergegenstand: Was jede Zeile enthalten muss, wie die RTM mit der Matrix verknüpft ist und was eine Compliance-Position auch achtzehn Monate nach der Einreichung noch rechtssicher macht.

Müssen Sie verstehen, wie die Rückverfolgbarkeit Kundenanforderungen mit Ihren internen Spezifikationen bei der FAT verbindet?
Der Leitfaden zur Anforderungsrückverfolgbarkeit deckt die gesamte Kette ab – von der Kundenklausel über die Compliance-Antwort und interne Nachweise bis hin zur Abnahmeprüfung – und zeigt auf, was erforderlich ist, um diese Kette intakt zu halten.

Möchten Sie sehen, wie Booma die Empfängerseite der Schnittstelle zwischen Anforderungen und Spezifikationen verwaltet?Produkt entdecken → oder Demo buchen um zu sehen, wie CIMC Pteris und andere Teams Kundenanforderungen und interne Spezifikationen klar voneinander trennen und eine saubere Übergabe gewährleisten.

‍

‍

‍

‍

‍