„Die Anforderungen an die Lieferanten von Werkzeugen sind nicht auf dem neuesten Stand und das ist frustrierend“

Veröffentlicht am: 08 April 2022

Experte:

Cees Michielsen

Trainer

Lesen Sie mehr über Cees Michielsen

Aktie

---

Der Beruf des Requirements Engineering entwickelt sich so schnell, dass die Anbieter von Tools kaum Schritt halten können. „Die Software der großen Anbieter berücksichtigt kaum die neuesten Erkenntnisse in unserem Bereich“, sagt Cees Michielsen, Trainer für System Requirements Engineering am High Tech Institute.

Der Kunde rückt immer mehr in den Mittelpunkt, die Systeme werden immer komplexer und der Entwicklungsprozess wird immer stärker verflochten. Dies sind, kurz gesagt, die Faktoren, die den Wandel im Requirements Engineering vorantreiben. „Das Requirements Engineering ist aus seiner Blase herausgetreten“, sagt Cees Michielsen, Trainer für System Requirements Engineering am High Tech Institute. „Es ist jetzt ein integraler Bestandteil der Systemtechnik.“

„In der Vergangenheit haben wir nur auf den inneren Wert einer Anforderung geachtet. So war auch das Tooling ursprünglich aufgebaut. Inzwischen konzentrieren wir uns mehr und mehr darauf, was eine solche Anforderung in der Gesamtheit der Produktentwicklung bewirkt. Wir zoomen mehr heraus. Leider sind die Software-Tools nicht mit uns gewachsen.“

In den kommenden Monaten wird Michielsen in Bits&Chips eine Handvoll Trends in seinem Bereich beleuchten. In diesem Interview stellen wir Ihnen zunächst einige der Themen vor, die er behandeln wird.

Wichtige Trends

Beim Requirements Engineering geht es darum, sicherzustellen, dass die Kundenwünsche klar und eindeutig in den Produktentwicklungsprozess einfließen, ohne dass Informationen verloren gehen. Diese Informationen können sehr konkret sein: eine LED-Lampe mit 2.700 K und 350 Lumen. Aber sie kann auch vage sein: ein komfortabler Lastwagen. „Wir müssen das richtige Produkt finden“, sagt Michielsen. „Wir müssen das, was der Kunde will, auf effiziente, aber korrekte Weise umsetzen.

Grob gesagt, sieht Michielsen eine Handvoll wichtiger Trends im Requirements Engineering. So ist es zum Beispiel eine immerwährende Herausforderung für Ingenieure, die Anforderungen für ein Produkt vollständig zu erfassen. „Das ist eine immer wiederkehrende Frage von Teilnehmern meiner Schulungen“, bemerkt Michielsen. Es besteht auch der Wunsch, die Qualität der Anforderungen zu verbessern. Das ist zwar nicht immer aufregend, aber eine Herausforderung für Ingenieure, denn Sprache und Formulierung spielen bei der Erstellung von guten Anforderungen und Produktspezifikationen eine entscheidende Rolle.

Die zunehmende Notwendigkeit der Rückverfolgbarkeit könnte man vielleicht als einen wirklich neuen Trend bezeichnen. „Dieser Begriff bezieht sich auf die Möglichkeit, alle Ereignisse und Entscheidungen im Anforderungsentwicklungs-, Design- und Entscheidungsfindungsprozess nachzuvollziehen, von den Interessengruppen bis zur Produktimplementierung“, erklärt Michielsen. „Umgekehrt ist es vor allem bei größeren Projekten wichtig, dass Sie für jede Anforderung auf jeder Zerlegungsebene wissen, wie Sie zu den Bedürfnissen des Stakeholders zurückfinden. Warum sollte man einen Seitenspiegel an einem LKW durch eine Außenkamera und ein Display in der Kabine ersetzen? Sie wollen wissen, warum eine solche Anforderung überhaupt besteht und warum sie so wertvoll ist, wie sie ist. Welche Funktionen sollte die Kamera haben, wie groß ist das Display und welche Auflösung hat es? Welche Entscheidungsfindung hat zu diesen spezifischen Werten für diese Anforderung geführt?“

„Ein guter Requirements-Engineering-Prozess stellt sicher, dass die Anforderungen der Stakeholder über die verschiedenen Entwicklungsiterationen hinweg in die Implementierung einfließen, ohne dass Informationen verloren gehen, einschließlich der Absicht der Kundenanforderungen. Außerdem sollten keine Anforderungen hinzugefügt werden, für die es keinen Stakeholder gibt.“

Warum ist es so wichtig, nicht nur das Ergebnis einer Entscheidung aufzuzeichnen, sondern auch den Entscheidungsprozess?

„Sie möchten Änderungen an Ihrem Produkt schnell und effizient vornehmen können. Dazu müssen Sie auch die Gründe kennen, die Sie zu einer Lösung geführt haben. Wenn Sie den Entscheidungsprozess nicht aufzeichnen, müssen Sie bei jeder Änderung den gesamten Denkprozess erneut durchlaufen. Sie müssen den gesamten Prozess noch einmal durchlaufen und auf hohem Niveau neu darüber nachdenken, was die vorgeschlagene Änderung bedeutet.“

„Wenn Sie die Entscheidungsfindung aufzeichnen, sparen Sie unheimlich viel Zeit. Vor allem in Unternehmen, die mit vielen Produktvarianten arbeiten. Wenn Sie wissen, dass eine Anpassung nur mit dem Unterschied zwischen Variante 1 und Variante 2 zu tun hat, sind Sie viel schneller fertig. Sie können viel effizienter arbeiten.“

Das ist wichtig, wenn Sie hundert verschiedene Rasierapparate herstellen.

„Ja. Wenn Sie bei solchen Zahlen eine gute Rückverfolgbarkeit in Ihren Anforderungsentwicklungsprozess einbauen, ist Ihr Verwaltungsaufwand fast verschwunden.“

Trainer Cees Michielsen

Zu Michielsens großer Enttäuschung hinken fast alle Anbieter von Anforderungswerkzeugen der Realität in der Produktentwicklung deutlich hinterher. Dinge wie Rückverfolgbarkeit und die Beziehungen zwischen Anforderungen sind in den Softwaretools von Anbietern wie IBM und Siemens kaum berücksichtigt. „Es scheint, als hätten sie sich nie mit den Phasen beschäftigt, die die Anforderungen von den Bedürfnissen der Stakeholder bis zur Implementierung durchlaufen. Das Fehlen einer funktionalen und physischen Aufschlüsselung des Systems bedeutet, dass Sie die Anforderungen nicht mit diesen spezifischen Systemelementen verknüpfen können. Ihnen fehlt tatsächlich der größte Teil der funktionalen und physischen Aufschlüsselung – die linke Seite des V-Modells.“

„Ich denke, dass die Anbieter von Tools für das Product Lifecycle Management derzeit eine zu eingeschränkte Sicht auf die Rolle des Requirements Engineering innerhalb des Systems Engineering haben. Darüber hinaus unterstützen sie die linke Seite des V-Modells nicht oder nur unzureichend. Aus diesem Grund bin ich der Meinung, dass sie den Titel ‚PLM-Tool-Anbieter‘ nicht verdient haben. Schließlich unterstützen sie nur einen begrenzten Teil des Lebenszyklus.“

Können Sie anhand eines Beispiels erklären, was falsch ist?

„Bei der traditionellen Arbeitsweise behalten die Ingenieure den Überblick darüber, inwieweit jedes Teil oder Produkt Teil eines Funktionsmoduls ist. Nehmen wir als Beispiel einen Fahrradlenker des Typs X mit einer integrierten Fahrradklingel Q im Griff dieses Lenkers. Für den Fahrradlenkertyp X ist dies ein fester Bestandteil. Der Fahrradlenker Typ X enthält die Fahrradklingel Typ Q.“

„Nehmen wir an, dass der Fahrradlenkertyp Y mehrere Optionen für die Anbringung einer Fahrradklingel hat, darunter eine integrierte Version. Der Fahrradlenkertyp Y enthält optional den Fahrradklingeltyp Q. Traditionell erfassen wir die Beziehung zwischen dem Objekt Fahrradklingel Q und den Fahrradlenkern X und Y als charakteristische Information der Fahrradklingel Q. Dies führt dazu, dass das Objekt Fahrradklingel Q jedes Mal bei jeder neuen Beziehung zu einem Fahrradlenker geändert werden muss. Die Versions- oder Revisionsnummer, der Status und so weiter. Darüber hinaus müssen alle bestehenden Verknüpfungen überprüft werden. Das bedeutet einen großen Verwaltungsaufwand.“

„Aber das ist wirklich nicht nötig, denn das Objekt Fahrradklingel Q hat sich überhaupt nicht verändert. Nur die Beziehungen zwischen den Teilen haben sich geändert. Die Lösung ist relativ einfach: Sorgen Sie dafür, dass die Information, die die Art der Beziehung zwischen den Objekten angibt, eine bedingte Beziehung ist. Diese Fähigkeit fehlt jedoch in den aktuellen Tools. Der Verwaltungsaufwand zieht sich bis zu den Anforderungen durch, in denen die Beziehung zu anderen Objekten ebenfalls als Attribut beschrieben wird. Wir sprechen hier von den Werkzeugen der großen PLM-Anbieter! Im Moment können sie das einfach nicht leisten. Hier gibt es also noch viel zu gewinnen.“

Sie sagen, dass große Unternehmen wie IBM und Siemens mit ihren riesigen Entwicklungsabteilungen nicht auf dem neuesten Stand sind?

„Das sind sie noch nicht. Die Praxis der Anforderungsentwicklung hat große Schritte gemacht, aber die Anbieter von Werkzeugen sind noch nicht nachgezogen. Selbst kleinere Anbieter wie Top Team, Cockpit und Contact Software sind noch nicht so weit. Das ist eine große Enttäuschung.“

Neue Anbieter von Tools haben einen Markt zu erobern und sollten motiviert sein, Funktionen hinzuzufügen.

„Sie tun das noch nicht genug, obwohl sie als Newcomer die Flexibilität dazu haben. Das niederländische Unternehmen Relatics aus Ridderkerk ist ein Anbieter, der gut abschneidet, aber das Unternehmen ist hauptsächlich auf das Bauwesen und nicht auf den Maschinenbau ausgerichtet. Relatics hat sein ganzes Tool auf die semantische Modellierung ausgerichtet, bei der Sie die ganze Welt als Objekte und Beziehungen zwischen ihnen und allen dazugehörigen Attributen betrachten.“

Das Requirements Engineering beeinflusst auch die Art und Weise, wie wir die Produktentwicklung betrachten. In der High-Tech-Branche wird oft auf das V-Modell verwiesen, wenn es um den Prozess von der ersten Idee bis zur Produktimplementierung geht. Dieses Modell beginnt mit einer funktionalen Gliederung, dem linken Bein des V. Michielsen: „Ein praktisches Problem ist, dass man nicht alle Anforderungen in die traditionelle funktionale Gliederung aufnehmen kann. Das gilt unter anderem für die physikalischen Eigenschaften von Produkten. Masse, Volumen, diese Art von Informationen. Es wäre klug, in diesem linken Bein zwei parallele Trajektorien zu starten. Denn später wird sich herausstellen, dass Sie im aufsteigenden Bein, wenn Sie integrieren, nicht testen können, was Sie angegeben haben. Dies ist zum Beispiel der Fall, wenn ein Submodul oder eine Funktion auf mehrere physische Module verteilt oder aufgeteilt ist. In diesem Fall können Sie diese bestimmten Subsysteme nicht als separate Module testen, sondern nur eines nach dem anderen.

Das Teilsystem kann erst getestet werden, wenn die gesamte Maschine zusammengebaut ist?

„Sie würden eine solche Funktion gerne gleich zu Beginn testen, aber das funktioniert in der Tat nicht. Sie brauchen dann tatsächlich zwei parallele Entwicklungspfade, einschließlich der Verantwortlichkeiten und Budgets, die Sie ihnen zuweisen können. Bevor Sie überhaupt etwas herstellen oder montieren lassen, verwenden Sie Simulationswerkzeuge, um eine virtuelle Funktionsintegration und eine virtuelle physische Integration durchzuführen. Das Ziel ist es, zunächst festzustellen, ob das Design korrekt ist. Dass alles funktioniert und alles passt.“

„Wenn Sie am Ende dieser virtuellen Entwicklung angelangt sind, wissen Sie auch genau, dass Sie die richtigen Bausteine entwickelt haben. Sie sind vollständig, was die Funktionalität angeht. Gleichzeitig wissen Sie auch, wo diese Bausteine in den verschiedenen physischen Modulen landen, weil Sie das durch Ihr physisches Design demonstrieren können. Sobald alles virtuell passt, können Sie mit der Implementierung, der Konstruktion, der Programmierung und so weiter beginnen.

Das W-Modell, wie Michielsen diese Form der Entwicklung nennt, wird das Thema einer separaten Folge seiner Trendserie sein.

Die Trendserie zu den Systemanforderungen ist auch als Bits&Chips-Podcasts auf Apple, Buzzsprout und Spotify verfügbar.

Dieser Artikel wurde verfasst von René Raaijmakers, technischer Redakteur von Bits&Chips.