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. Theoretisch ist diese Unterscheidung klar genug.

Kompliziert wird es in der Lieferkette.

Wenn ein Kunde ein 400-seitiges URS an einen Lieferanten sendet, enthält dieses Dokument Anforderungen aus der 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 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 Verwechslung von 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 welches Dokument verwaltet, wer dafür verantwortlich ist, wie das Lieferobjekt für den Kunden aussieht und wo die Haftung liegt, wenn etwas schiefgeht.

‍

[KEY TAKEAWAYS]

• Anforderungen definieren, was ein System leisten muss. Spezifikationen definieren, wie es gebaut wird, um dies zu erreichen. Diese Unterscheidung gilt sowohl für die erstellende als auch für die empfangende Seite.
• Auf der Empfängerseite enthält das vom Kunden ausgestellte URS, die Anfrage (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 tun, erreichen oder erfüllen muss, ohne vorzugeben, wie. Sie ist aus der Perspektive eines Bedarfs geschrieben: ein Leistungsniveau, ein Sicherheitsgrenzwert, eine regulatorische Verpflichtung, ein Nutzerergebnis. Der Test für eine gut formulierte Anforderung ist, dass mehrere technisch valide Lösungen sie erfüllen könnten.

Auf der Empfängerseite gehen Anforderungen in Dokumenten ein, die Ihr Kunde kontrolliert: eine User Requirements Specification, eine Angebotsanfrage, eine Ausschreibung, eine technische Beschaffungsspezifikation oder ein Lieferanten-Qualitätshandbuch. Der Kunde besitzt diese Dokumente. Der Kunde entscheidet, wann sie sich ändern und was in der neuen Version steht. Ihre Aufgabe ist es, darauf zu reagieren.

Sie haben diese Anforderungen nicht geschrieben. Sie können sie nicht umschreiben. Sie können sie nicht aufschieben. Sie bewerten, ob Sie sie erfüllen können, dokumentieren Ihren Compliance-Status und stehen für die Dauer des Projekts zu dieser Position.

‍

Was Spezifikationen sind

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

Auf der Empfängerseite sind Spezifikationen Dokumente, die Ihr Unternehmen kontrolliert: Ihre Standardproduktspezifikation, Ihre technische Designdokumentation, 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 Dokumenteneigentümerschaft erkennen.

Das vom Kunden herausgegebene URS ist ein Anforderungsdokument. Der Kunde kontrolliert es. Wenn sich daran etwas ändert, entscheidet der Kunde. Ihre Verpflichtung besteht darin, auf jede einzelne Klausel zu reagieren.

Ihre Compliance-Matrix ist Ihre strukturierte Antwort auf die Anforderungen des Kunden. Sie kontrollieren sie auf Ihrer Seite, der Kunde empfängt sie, und bei Auftragsvergabe wird sie in der Regel 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 belegt. Wenn in der Compliance-Matrix „Vollständig konform“ steht, ist Ihre Spezifikation das, womit das Produkt vollständig konform ist.

Die Rückverfolgbarkeitskette, die diese Elemente verbindet, verläuft von der Kundenanforderung über die Compliance-Antwort bis hin zur internen Spezifikation. Diese Kette dient als 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 jedoch vom Engineering-Team des Kunden für den Kontext des Kunden geschrieben. Sie lassen sich möglicherweise nicht nahtlos auf die Konstruktion Ihres Produkts übertragen. Konflikte treten während der Entwicklung auf, und niemand weiß, ob sie durch eine Änderung des Designs oder durch eine Rückmeldung an den Kunden gelöst werden sollen.

Eigene Spezifikationen als Anforderungen des Kunden behandeln. Manche Teams reagieren auf ein Kunden-URS mit der Behauptung, ihre Standard-Produktspezifikation 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 erst bei der FAT.

Verlust der Grenze im Tool-Management. DOORS, Jama und Polarion sind darauf ausgelegt, Anforderungen und Spezifikationen zu verwalten, die von Ihrem eigenen Engineering-Team erstellt wurden. Sie sind hervorragend für diese Aufgabe geeignet. Sie wurden nicht dafür entwickelt, ein vom Kunden herausgegebenes URS einzulesen, dessen Klauseln zu extrahieren und Ihre Compliance-Antwort auf jede einzelne zu verwalten. Teams, die versuchen, Tools für die Erstellerseite für die Aufgaben der Empfängerseite zu nutzen, enden mit 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. Die beiden Dinge gehören nicht in dieselbe Datenbank, da das eine etwas ist, das Sie selbst erstellt haben, und das andere etwas, auf das Sie reagieren.“

—Anuraj Suman, Principal AI Engineer, Booma

‍

Wie die beiden Seiten zusammenarbeiten

Anforderungen und Spezifikationen konkurrieren nicht. Sie sind miteinander verbunden. Die Kette sieht wie folgt aus.

Der Kunde gibt ein URS heraus. 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 Anforderungsebene: Sie adressiert die Anforderungen des Kunden, ohne bereits festzulegen, wie Ihre Technik diese erfüllen wird.

Ihr Engineering-Team übersetzt Ihre Compliance-Verpflichtungen in interne Spezifikationen: Designdokumente, Testpläne, Fertigungsanweisungen. Diese Spezifikationen definieren, wie Sie tatsächlich ein System bauen, das dem entspricht, wozu Sie sich in der Matrix verpflichtet haben.

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

Jedes Glied dieser Kette erfordert ein Werkzeug. 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-Verpflichtungen über das Design bis hin zum Test. Die beiden Werkzeuge müssen an der Übergabestelle miteinander verbunden werden: bei der akzeptierten Compliance-Verpflichtung, die Ihre interne Spezifikation steuert.

‍

Häufige Fehlerquellen

Compliance-Verpflichtungen ohne Rückverfolgbarkeit zu internen Spezifikationen

Die Compliance-Matrix gibt „Vollständig konform“ an. Das interne Engineering-Team war sich der spezifischen Verpflichtung jedoch nicht bewusst. Niemand hat die Compliance-Position in eine Spezifikationsanforderung für das Designteam ü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-Verpflichtungen 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.

URS-Klauseln von Kunden, die im falschen Werkzeug verwaltet werden

Ein Team verwendet DOORS, um sowohl seine eigenen Produktanforderungen als auch die vom Kunden herausgegebenen URS-Klauseln zu verwalten. Das Werkzeug war für Letzteres nicht konzipiert. Die Extraktion erfolgt manuell. Der Compliance-Workflow ist eine Notlösung. Die Verbindung zwischen Kundenklausel und interner Spezifikation wird eher durch Konventionen als durch das Werkzeug aufrechterhalten und bricht unter Projektdruck zusammen.

Spezifikationen, die an Kunden übermittelt werden, anstatt Compliance-Antworten

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

‍

Vorteile der Aufrechterhaltung 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 Angebots-Engineering-Team verwaltet. Interne Spezifikationen werden vom Engineering-Team verwaltet. Keines der Teams greift ohne formelle Übergabe in den Bereich des anderen ein.
• Werkzeuge auf der Empfangsseite verwalten Kundenanforderungen und Compliance-Antworten. Werkzeuge auf der Erstellungsseite verwalten interne Spezifikationen. Jedes erfüllt seine Aufgabe ohne Notlösungen.
• Compliance-Zusagen lassen sich auf die internen Spezifikationen zurückführen, die sie belegen. Beim FAT ist die Kette von der Kundenklausel bis zum Nachweis intakt.
• Wenn der Kunde eine Anforderung ändert, übernimmt der Prozess auf der Empfangsseite die Überarbeitung. Wenn interne Designänderungen eine Compliance-Verpflichtung 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.

Praxisbeispiel

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

Ihre Ingenieurteams erstellen interne Spezifikationen für die Systeme, die sie entwerfen und installieren. Dabei handelt es sich um ihre eigenen technischen Dokumente, die über ihre eigenen Designprüfungs- und Änderungskontrollprozesse verwaltet werden.

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

Vor Booma wurde diese Kette manuell gepflegt und brach vor allem bei der Überarbeitung zusammen: 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.

Nach der Implementierung 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 die interne Technik ist 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 in den Dokumenten nachzuverfolgen. Mit Booma können wir noch am selben Tag mit einer fundierten, prüfungssicheren Antwort reagieren.“

‍

Was sich durch KI geändert hat

Die manuelle Pflege dieser Schnittstelle bei wachsendem Auftragsvolumen bedeutete, Kundenklauseln von Hand mit internen Nachweisen zu verknüpfen, was zunehmend langsamer und fehleranfälliger wurde. Zwei spezifische Funktionen haben dies geändert.

Semantische Klassifizierung bei der Extraktion. KI kann nun eine Kundenklausel lesen und beurteilen, ob es sich eher um eine funktionale Anforderung, eine Leistungsanforderung, eine regulatorische Anforderung oder eine Spezifikationsvorgabe handelt, die als Anforderung getarnt ist. Klauseln, bei denen der Kunde faktisch eine Spezifikation geschrieben hat (durch die Vorgabe einer bestimmten Komponente, Technologie oder eines Implementierungsansatzes), werden zur Überprüfung markiert, anstatt sie ungeprüft als Anforderung auf Antwortebene zu akzeptieren.

Dokumentübergreifende Ähnlichkeit. KI kann die interne Spezifikation vorschlagen, die am wahrscheinlichsten eine neue Kundenklausel abdeckt, basierend auf der semantischen Ähnlichkeit mit 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 menschliche Prüfung
• Interne Nachweise durch Expertenwissen lokalisiert
• Manuelle Pflege der Verknüpfungen zwischen Anforderungen und Spezifikationen
• Schnittstelle durch Konvention gewahrt

KI-gestützt

• KI-Klassifizierung markiert Spezifikationsklauseln in Kundendokumenten
• Nach Ähnlichkeit bewertete Nachweisvorschläge aus der bisherigen Angebotshistorie
• KI-gestützte Verknüpfungen von Kundenklauseln zu internen Nachweisen
  
• Durch Tool-Struktur erzwungene Abgrenzung

Wie Booma hilft

Booma verwaltet die Empfangsseite 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 auf die Aufgaben der Empfangsseite ausgerichtet: Extrahieren von Klauseln, Verwalten von Compliance-Antworten, Pflegen der Revisionshistorie und Bereitstellen früherer Nachweise.

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

DOORS und Jama verwalten das, was Ihre Engineering-Organisation erstellt. Booma verwaltet das, was Ihre Kunden Ihnen senden. Zusammen decken sie beide Seiten der 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 Empfangsseite kommen Anforderungen von Ihren Kunden. Spezifikationen stammen von Ihrem eigenen Engineering-Team.

Warum ist diese Unterscheidung gerade auf der Empfangsseite wichtig?

Weil Sie auf der Empfangsseite Dokumente verwalten, die Sie nicht selbst erstellt haben und nicht ändern können (Kundenanforderungen), sowie Dokumente, die Ihr eigenes Team erstellt hat (interne Spezifikationen). Wenn diese im selben Tool, im selben Prozess oder durch dasselbe Team vermischt werden, entstehen Lücken in der Verantwortlichkeit und Fehler 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 arbeitet auf der Ebene der Anforderungen: Sie adressiert jede Kundenklausel, ohne bereits festzulegen, wie Ihr Engineering diese erfüllen wird. Ihre internen Spezifikationen sind der 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 Ihre Engineering-Organisation erstellt. Booma verwaltet die Anforderungen, die Ihre Kunden Ihnen senden. Es handelt sich nicht um konkurrierende Tools. Sie adressieren unterschiedliche Seiten derselben Lieferkette.

Was passiert, wenn eine Kundenspezifikationsklausel eigentlich eine Designvorgabe ist?

Manche Kunden schreiben Klauseln, die eine bestimmte Technologie, Komponente oder einen Implementierungsansatz vorgeben, anstatt eine Leistungsanforderung zu definieren. Dies sind Spezifikationsvorgaben, die in einem Anforderungsdokument eingebettet sind. Auf der Empfangsseite müssen Sie diese zwar ebenfalls beantworten, sie müssen jedoch als solche markiert werden: Sie schränken Ihren Lösungsraum ein und können mit Ihrem Standardproduktdesign in Konflikt stehen.

[NEXT STEPS]

Möchten Sie verstehen, wie die Compliance-Matrix korrekt erstellt und dokumentiert wird?

DerLeitfaden zur Anforderungsdokumentation behandelt, was jede Zeile enthalten muss, wie sich die RTM zur Matrix verhält und was eine Compliance-Position auch achtzehn Monate nach der Einreichung noch verteidigbar macht.

Sie möchten wissen, wie die Rückverfolgbarkeit Kundenanforderungen mit Ihren internen Spezifikationen bei der Werksabnahme (FAT) verknüpft?

DerLeitfaden zur Anforderungsrückverfolgbarkeit deckt die gesamte Kette von der Kundenklausel über die Compliance-Antwort und interne Nachweise bis hin zur Abnahmeprüfung ab – und zeigt, was nötig ist, um diese Kette lückenlos zu halten.

Möchten Sie sehen, wie Booma die Empfangsseite dieser Schnittstelle verwaltet?

Entdecken SieAnforderungsmanagement-Software für kundenseitige Dokumente →oderbuchen Sie eine Demo um zu erfahren, wie CIMC Pteris und andere Teams Kundenanforderungen und interne Spezifikationen trennen und eine saubere Übergabe zwischen beiden sicherstellen.