Requirements Engineering in der Hardwareentwicklung

Seien wir ehrlich: Nur sehr wenige Menschen begeistern sich für Anforderungen. Und doch hat jedes Hardware-Team schon die Kosten unklarer Anforderungen zu spüren bekommen: Nacharbeit, die erst spät sichtbar wird, oder ein Build, das an dem vorbeigeht, was die Stakeholder tatsächlich gefordert haben. 

Requirements Engineering (RE) ist die Disziplin, die einem strukturierten Prozess zur Definition, Dokumentation und Verwaltung von Anforderungen folgt, damit das Endprodukt das richtige Problem löst. Richtig angewendet, hilft es dabei, Fehler früh zu erkennen, das Team auf ein gemeinsames Ziel auszurichten und allen die Sicherheit zu geben, dass am Ende genau das ausgeliefert wird, was tatsächlich vereinbart wurde.

Der Begriff sorgt jedoch häufig für Verwirrung, weil er sowohl im Software Engineering als auch im Systems Engineering von Hardware-Produkten verwurzelt ist. 

In diesem Artikel erhalten Sie eine klare Definition von Requirements Engineering und seiner Rolle in der Entwicklung von Hardware-Produkten. Wir behandeln sowohl einen theoretischen Überblick als auch ein praxisnahes Framework dafür, wie es in einem Hardware-Projekt angewendet wird – mit Beispielen aus der Praxis sowie einer Liste der häufigsten Fallstricke und wie man sie vermeidet.

Wichtige Erkenntnisse

• Requirements Engineering hilft Hardware-Teams dabei, die Designabsicht in klare Anforderungen zu überführen und alle im Team aufeinander abgestimmt zu halten.
• Anforderungen steuern das Projekt von der frühen Planung und Entwicklung bis hin zu Tests, Änderungen und der abschließenden Dokumentation.
• Ein guter Anforderungsprozess hilft Entwicklungsteams, Probleme früh zu erkennen, kostspielige Redesigns zu vermeiden und sicherzustellen, dass das Endprodukt dem entspricht, was vereinbart wurde.

Was ist Requirements Engineering?

Requirements Engineering ist ein systematischer, disziplinierter Ansatz zur Definition, Dokumentation und Verwaltung von Anforderungen während der Entwicklung von Hardware-Produkten.

Es hilft Teams dabei, das zu lösende Problem zu verstehen, die Bedürfnisse der Stakeholder zu klären und zu analysieren, Konflikte und Zielkonflikte aufzulösen, zu dokumentieren, was das Produkt leisten muss, und dieses Verständnis aktuell zu halten, während sich das Produkt weiterentwickelt.

In der Praxis schaffen Anforderungen ein gemeinsames Verständnis zwischen Stakeholdern und Engineering-Teams darüber, was entwickelt wird, warum es entwickelt wird und woran das Team erkennen kann, ob das Endprodukt der Designabsicht entspricht.

Vorteile von Requirements Engineering

Wenn RE gut umgesetzt wird, hilft es dabei, Missverständnisse und kostspielige Fehler zu vermeiden, das Team aufeinander abgestimmt zu halten und sicherzustellen, dass das Endprodukt seine Anforderungen erfüllt.

Zu den wichtigsten Vorteilen von RE gehören:

• Gemeinsame Vision: Hält Stakeholder, Manager und Engineering-Teams auf eine gemeinsame Vorstellung davon ausgerichtet, was entwickelt wird.
• Klarer Umfang: Macht deutlich, was Teil des Projekts ist und was nicht, und hilft so, unkontrollierte Erweiterungen des Projektumfangs – bekannt als Scope Creep – zu verhindern.
• Kostspielige Fehler reduzieren: Hilft dabei, Probleme in den Anforderungen früh zu erkennen, bevor sie zu teurer Überarbeitung des Designs, neuen Prototypen oder wiederholten Tests führen.
• Verbessert Planung und Terminierung: Gibt Teams ein klareres Bild davon, was entwickelt werden muss, und erleichtert so die Aufwandsschätzung und die Erstellung realistischer Zeitpläne.
• Verbessert die Produktqualität: Hilft sicherzustellen, dass das Endprodukt das tut, was vereinbart wurde, und die geforderten Qualitätsstandards erfüllt.

Entwicklung der Disziplin Requirements Engineering

Requirements Engineering hat seine Wurzeln sowohl im Systems Engineering als auch im Software Engineering. Diese beiden Entwicklungslinien sind in unterschiedlichen technischen Kontexten entstanden, daher kann der Begriff je nach Quelle noch immer einen leicht unterschiedlichen Umfang haben.

Im Kontext des Software Engineering liegt der Fokus in erster Linie auf Anforderungen an die Softwareentwicklung: was die Software tun soll, wie sie sich verhalten soll und welche Qualitätsmerkmale sie erfüllen soll. Softwareingenieure denken dabei an funktionale und nicht-funktionale Anforderungen, dokumentiert als User Stories, Use Cases und Akzeptanzkriterien. Im Kontext des Systems Engineering ist der Umfang breiter. Anforderungen beziehen sich dort auf das gesamte System, einschließlich Hardware, Software, Menschen, Prozesse, Schnittstellen, Betriebsbedingungen und anderer Systemeigenschaften. Systemingenieure sprechen von Systemanforderungen auf höherer Ebene, die auf Hardware, Mechanik, Elektrik, Firmware und Sicherheitsaspekte heruntergebrochen werden und als formale Anforderungsbeschreibungen sowie in Rückverfolgbarkeitsmatrizen für Anforderungen erfasst werden.

In der Hardware-Entwicklung führt RE beide Perspektiven zusammen. Es kombiniert die Strenge und den multidisziplinären Umfang des Systems Engineering, die erforderlich sind, um mit Stücklistenkosten (BOM), thermischen Randbedingungen und Fertigungsgrenzen umzugehen, mit der im Software Engineering genutzten Rückverfolgbarkeit über den gesamten Lebenszyklus, damit Anforderungen testbar bleiben und während der gesamten Entwicklung miteinander verknüpft sind.

Verwandte Disziplinen des Requirements Engineering

Requirements Engineering ist eng mit anderen Disziplinen der Produktentwicklung verbunden, insbesondere mit Systems Engineering und Produktmanagement.

Systems Engineering

Systems Engineering betrachtet ein Produkt als vollständiges System. Ein Systemingenieur stellt sicher, dass unterschiedliche Teile wie Hardware, Software, mechanische Komponenten und Tests ordnungsgemäß zusammenarbeiten und nicht miteinander in Konflikt stehen.

Dies ist eng mit RE verbunden, weil Anforderungen all diesen Teams eine gemeinsame Referenz dafür geben, was das Produkt erreichen muss.

Wenn Sie Analogien mögen, stellen Sie sich den Bau eines Hauses vor. Verschiedene Spezialisten kümmern sich um Fundament, Elektrik, Sanitär und Heizung, aber trotzdem muss jemand sicherstellen, dass all diese Teile tatsächlich zu einer vollständigen Struktur zusammenpassen. Genau diese Rolle übernimmt Systems Engineering in der Produktentwicklung.

Produktmanagement

Produktmanagement hilft zu entscheiden, was entwickelt werden soll und warum. Produktmanager sprechen mit Kunden, analysieren den Markt, betrachten Wettbewerber und arbeiten mit dem Unternehmen zusammen, um zu entscheiden, welche Probleme es wert sind, gelöst zu werden, und welche Funktionen am wichtigsten sind.

Auch das ist mit RE verbunden, denn diese übergeordneten Kundenbedürfnisse und Geschäftsziele werden zum Ausgangspunkt für die Definition von Produktanforderungen.

Phasen des Requirements-Engineering-Prozesses

Der RE-Prozess kann je nach Anwendungsbereich, beteiligten Personen und Organisation unterschiedlich strukturiert sein. In manchen Projekten finden die Aktivitäten überwiegend nacheinander statt, während sie in anderen wiederholt und erneut aufgegriffen werden, wenn das Team mehr lernt.

Wie in einem Artikel beschrieben, der im Journal Requirements Engineering veröffentlicht wurde, unterteilt ein verbreiteter Lehrbuchansatz den RE-Prozess in vier Kernaktivitäten (Phasen):

• Anforderungserhebung: das Sammeln von Anforderungen von Stakeholdern und aus anderen Quellen, um zu verstehen, was das System tun muss und unter welchen Bedingungen es betrieben werden muss.
• Anforderungsanalyse und -spezifikation: die Überprüfung der gesammelten Informationen, das Auflösen unklarer oder widersprüchlicher Angaben und ihre Umwandlung in klare Anforderungen, die das Engineering-Team nutzen kann.
• Anforderungsvalidierung: die Prüfung, ob die Anforderungen korrekt und vollständig sind und beschreiben, was das System erreichen soll.
• Anforderungsmanagement: das Nachverfolgen von Anforderungen und ihrer Änderungen im Zeitverlauf, einschließlich der Gründe für Änderungen und der Frage, welche anderen Anforderungen, Designarbeiten oder Tests davon betroffen sein könnten.

Wer am Prozess beteiligt ist

Mehrere zentrale Rollen sind am RE-Framework beteiligt und arbeiten zusammen, um festzulegen, was ein Produkt leisten soll:

• Verantwortlicher für Anforderungen: Der Ingenieur, der vage Stakeholder-Anforderungen aufnimmt, die richtigen Fragen stellt und sie in einen Satz von Anforderungen überführt, den das Engineering-Team tatsächlich für die Produktentwicklung nutzen kann. Dies ist häufig ein Systemingenieur, Lead Engineer oder jemand mit vergleichbarer Verantwortung.
• Technische Produktverantwortung: Die Personen, die mit der Stakeholder-/Business-Seite kommunizieren, deren Anforderungen verstehen und diese anschließend in ein klares Produktziel überführen. Dazu können Product Manager, Program Manager oder ähnliche Rollen gehören.
• Implementierungsingenieur: Der Ingenieur, der diese definierten Anforderungen nutzt, um das Produkt zu entwerfen und zu entwickeln. Dazu können Elektronik-, Mechanik-, Software- oder Firmware-Ingenieure gehören.
• Verifikationsverantwortlicher: Die Person, die festlegt, wie die Anforderungen geprüft werden, und sicherstellt, dass die erforderlichen Reviews und Tests durchgeführt werden. Dazu können Verifikationsingenieure, Testingenieure oder QA-Ingenieure gehören.

Praxisnahes Requirements-Engineering-Framework für die Hardware-Entwicklung

Während die vier oben genannten Aktivitäten den Kern des RE-Prozesses definieren, benötigen Hardware-Teams eine praktische Möglichkeit, sie über den gesamten Projektverlauf hinweg anzuwenden.

Im Folgenden finden Sie eine praxisnahe Sicht auf das Requirements-Engineering-Framework für die Hardware-Entwicklung, die zeigt, wie Anforderungen in jede Phase eingebettet sind.

Projektstart: Absicht erfassen

Zu Beginn eines Projekts erhalten Technical Leads in der Regel vage Eingaben wie Kundenanfragen, Requests for Proposal (RFPs), Geschäftsziele oder Vorgaben zu Kosten, Größe oder Zeitplan. So könnte ein Kunde beispielsweise nach einem kleineren Gerät fragen, das einen bestimmten Anwendungsfall unterstützt.

Gemeinsam mit dem Verantwortlichen für Anforderungen klären Technical Leads, was benötigt wird, und überführen diese Eingaben in übergeordnete Anforderungen, die beschreiben, was das Produkt erreichen soll.

Requirements Engineering: Anforderungen definieren

Die übergeordneten Anforderungen aus der Phase des Projektstarts sind für ein detailliertes Design noch zu allgemein. In dieser Phase definiert der Verantwortliche für Anforderungen das Gesamtsystem, zerlegt es in Teile und Subsysteme und wandelt diese übergeordneten Anforderungen in spezifischere Anforderungen für jeden Teil um.

Außerdem prüft er, dass die Anforderungen sich nicht widersprechen, dass nichts Wichtiges fehlt und dass jede einzelne klar und testbar ist. Das Ergebnis ist ein abgestimmter Satz von Anforderungen, den das Engineering-Team als Ausgangspunkt für das Produktdesign nutzen kann.

Implementierung: Designs entwickeln

Implementierungsingenieure nutzen die abgestimmten Anforderungen, um ihren Teil des Produkts zu entwerfen und zu entwickeln – sei es durch das Erstellen eines Schaltplans, das Modellieren eines 3D-Teils oder das Schreiben von Software oder Firmware. Während sich das Design weiterentwickelt, verknüpfen sie jede Anforderung mit dem Designmerkmal, das sie erfüllt. Diese Verknüpfungen schaffen die Rückverfolgbarkeit des Projekts und helfen dem Verantwortlichen für Anforderungen zu erkennen, wie die Anforderungen umgesetzt wurden.

Verifikation & Validierung: Testen & Verifizieren

Anforderungen legen auch fest, was bei Reviews und Tests überprüft werden muss. Der Verifikationsingenieur definiert, wie jede Anforderung geprüft wird, arbeitet mit den Implementierungsingenieuren zusammen, um die erforderlichen Reviews, Messungen oder Tests durchzuführen, und dokumentiert die Ergebnisse. Dadurch wird verknüpft, was das Produkt leisten sollte, mit den Nachweisen dafür, ob es dies tatsächlich erreicht hat.

Änderungsmanagement: Überarbeiten & Iterieren

Anforderungen und Produktdesigns ändern sich während der Entwicklung häufig. Es kann sich herausstellen, dass eine Anforderung nicht erfüllbar ist, eine Komponente am Markt nicht mehr verfügbar ist oder eine neue Randbedingung hinzukommt. In diesem Fall verfolgt der Verantwortliche für Anforderungen nach, was sich geändert hat, warum es sich geändert hat und welche Anforderungen, Designteile oder Tests davon betroffen sind.

Dokumentation & Übergabe: Projekt abschließen

Am Ende des Projekts arbeitet der Requirements Owner mit dem Verification Engineer und dem restlichen Team zusammen, um Anforderungen, Design-Reviews und Verifizierungsaktivitäten abzuschließen. Die abschließende Dokumentation sollte einen nachvollziehbaren Nachweis darüber liefern, was gefordert war, was gebaut wurde und wie es verifiziert wurde. Kunden, Hersteller, Auditoren oder Teams, die später weiter am Produkt arbeiten, werden diese Informationen benötigen.

Beispiele für Requirements Engineering

Requirements Engineering bei Medizinprodukten

Requirements Engineering wird in medizinischen und pflegetechnischen Produkten eingesetzt. Anforderungen begleiten das Produkt während der gesamten Entwicklung. Teams übersetzen die Bedürfnisse der Stakeholder in strukturierte Systemanforderungen, halten sie bei Änderungen der Spezifikationen miteinander verknüpft und nutzen sie, um die Verifizierung zu planen und Testergebnisse zu dokumentieren.

Bei Medizinprodukten kommt eine regulatorische Ebene hinzu. Teams investieren mehr Aufwand in Rückverfolgbarkeit, Verifizierung sowie Dokumentation und Nachweisführung. Das unterstützt die regulatorische Zulassung im Rahmen von Vorgaben wie FDA 21 CFR Part 820 in den USA und ISO 13485:2016 in der EU und anderen Märkten.

Der HitIQ-Mundschutz ist ein Beispiel für ein medizinisches Wearable, bei dem Sicherheitsanforderungen jede technische Spezifikation bestimmen. Erfahren Sie in der vollständigen Customer Success Story, wie das umgesetzt wird.

Requirements Engineering in der Consumer- und Industrieelektronik

Der grundlegende Requirements-Engineering-Prozess ist in der Consumer- und Industrieelektronik ähnlich, aber die Produkte werden unter unterschiedlichen Bedingungen entwickelt. Consumer-Produkte wie Smart-Home-Geräte oder Wearables werden in hohen Stückzahlen verkauft und schnell auf den Markt gebracht. Industrieprodukte wie speicherprogrammierbare Steuerungen (SPS) oder Motorantriebe müssen über Jahre hinweg unter rauen Bedingungen funktionieren.

In beiden Fällen halten Teams fest, was das Produkt leisten muss, verknüpfen jede Anforderung mit dem Design, aktualisieren Anforderungen bei Änderungen und testen gegen diese Anforderungen.

Der Unterschied liegt darin, worauf Teams den zusätzlichen Aufwand konzentrieren. In der Consumer-Elektronik geht es darum, mit schnellen Änderungen Schritt zu halten, denn eine falsch verstandene Anforderung kann bedeuten, dass das Board neu entwickelt werden muss. In der Industrieelektronik liegt der Schwerpunkt auf der Verifizierung, weil das Produkt vor der Auslieferung auf lange Lebensdauer und den Einsatz unter rauen Bedingungen getestet werden muss.

Um zuverlässige Hardware zu entwickeln, die Sicherheitsvorschriften erfüllt, ist es entscheidend, Anforderungen und Designänderungen miteinander verknüpft zu halten. Lesen Sie in der vollständigen Success Story, wie MakeSafe Tools dies umsetzt.

So vermeiden Sie häufige Fallstricke im Requirements Engineering

Requirements Engineering bringt einige typische Herausforderungen mit sich. Wenn man weiß, was schiefgehen kann, lassen sich Probleme bei der Entwicklung von Hardwareprodukten früher erkennen und vermeiden.

Hier sind einige der häufigsten Fallstricke, auf die Sie achten sollten, und wie Sie sie vermeiden können:

Software-Tools für Requirements Engineering

Eine kleine Menge an Anforderungen zu verwalten, ist relativ einfach. Wenn ein Projekt wächst, erfordert es mehr Aufwand, alles organisiert und aktuell zu halten. Ab diesem Punkt wird die Art und Weise, wie Sie Anforderungen verwalten, immer wichtiger.

In der Praxis arbeiten Teams in der Regel mit einem dieser Ansätze:

• Tabellen und Dokumente: Vertraut und leicht für den Einstieg, was sie für kleinere Projekte nützlich macht. Mit wachsendem Projekt erfordern sie jedoch mehr manuellen Aufwand in der Pflege.
• Dedizierte Requirements-Management-(RM)-Tools: Bieten mehr Struktur und Kontrolle, wenn Projekte komplexer werden. Der Nachteil ist, dass einige Tools auch mehr Prozesse mit sich bringen, als ein kleineres Team benötigt.

Das Ziel ist, für das Projekt genug Struktur zu nutzen, ohne das Anforderungsmanagement unnötig zu verkomplizieren.

Für kleinere Hardware-Teams, die aus Tabellen herausgewachsen sind, aber keinen umfangreichen Enterprise-RM-Workflow benötigen, ist Requirements Portal eine praktische Option. Es wurde entwickelt, um kleineren Teams eine strukturiertere Möglichkeit zur Verwaltung von Anforderungen zu geben, ohne den Overhead eines klassischen Enterprise-Systems.

Fazit & nächste Schritte

Sie sollten nun ein klares Verständnis der wichtigsten Konzepte des Requirements Engineering haben und wissen, wie sie in der Praxis angewendet werden.

Wenn Sie mehr über Requirements Engineering lernen möchten, sind diese Ressourcen ein guter Ausgangspunkt:

• ISO/IEC/IEEE 29148:2018 bietet den internationalen Standard für Prozesse und Praktiken im Requirements Engineering. Er gibt zusätzliche Orientierung dazu, wie Anforderungen formuliert, strukturiert, dokumentiert und verwaltet werden sollten.
• NASA Systems Engineering Handbook bietet praxisnahe Hinweise dazu, wie Anforderungen während der Systementwicklung erstellt, formuliert, geprüft und genutzt werden.
• Guide to the Systems Engineering Body of Knowledge (SEBoK) erklärt, wie Anforderungen in den größeren Systems-Engineering-Prozess passen und wie verschiedene Teile eines Systems gemeinsam entwickelt werden.
• Requirements Engineering journal veröffentlicht Forschungsergebnisse, Branchenbeispiele und verschiedene Ansätze zum Requirements Engineering in größerer Tiefe.

Wenn Sie bereit sind, von der Theorie zur Praxis überzugehen, testen Sie Requirements Portal und arbeiten Sie noch heute mit strukturierten Anforderungen an einem echten Hardwareprojekt – kostenlos und ohne erforderliches Setup.

Häufig gestellte Fragen

Warum ist Requirements Engineering wichtig?

Requirements Engineering ist wichtig, weil es dem Team hilft, das richtige Produkt zu entwickeln, indem die Bedürfnisse der Stakeholder klar verstanden werden, bevor Design und Entwicklung zu weit fortgeschritten sind.

Welche Rolle hat ein Requirements Engineer?

Ein Requirements Engineer übersetzt die Bedürfnisse der Stakeholder in klare Anforderungen, mit denen das Engineering-Team arbeiten kann, und hält diese Anforderungen organisiert, wenn sich das Projekt verändert. Er fungiert als Brücke zwischen Kunden und Entwicklungsteams. 

Was ist der Unterschied zwischen Requirements Engineering und Requirements Management?

Requirements Engineering ist der gesamte Prozess, in dem zunächst ermittelt, verstanden und dokumentiert wird, was ein System überhaupt leisten muss. Requirements Management ist der spezifische Teil dieser Aufgabe, der diese Anforderungen organisiert hält und Änderungen nachverfolgt, sobald sie formuliert wurden.