Systemanforderungen definiert durch Kaskaden von Kreativität

Veröffentlicht am: 12 Mai 2020

Experte:

Cees Michielsen

Trainer

Lesen Sie mehr über Cees Michielsen

Aktie

---

Cees Michielsen verfügt über mehr als 30 Jahre Erfahrung in der niederländischen High-Tech-Industrie. Er reflektiert über seine Erfahrungen und versucht, diese als Dozent der Schulung „Verbesserung der Systemanforderungen“ am High Tech Institute weiterzugeben.

Es war 1986, als Cees Michielsen seine ersten Schritte in der Welt der Hochtechnologie machte. Damals trat er in das EMT-Team von Philips ein, das später zu Assembleon und schließlich zu Kulicke & Soffa wurde, um beim Bau von SMD-Bestückungsrobotern mitzuwirken. „Damals waren unsere Hauptkunden Automobilunternehmen wie Ford, GM und Chrysler. Wir waren völlig eigenständig und hatten alle wesentlichen Disziplinen und Kompetenzen in unserer Geschäftseinheit“, erinnert sich Michielsen.

Als er in das Team eintrat, lag Michielsens Schwerpunkt auf der technischen Informatik, aber schon früh nahm die Entwicklung seiner Karriere einen Umweg. „Bei Philips begann ich, mich zu einem Systemdenker zu entwickeln und mich wirklich von meiner eigenen Software-Disziplin zu lösen“, erklärt Michielsen. „Im Nachhinein kann ich sagen, dass dies der beste Start in meine Karriere war. Die Erfahrung hat mir einen enormen Vorsprung verschafft und ist der Grund, warum ich heute noch so leidenschaftlich bei der Sache bin.“

„Bei Philips habe ich begonnen, mich zu einem Systemdenker zu entwickeln und mich von meiner eigenen Software-Disziplin zu lösen“, erklärt Cees Michielsen.

Jetzt, nach mehr als drei Jahrzehnten in der Branche, verbringt Michielsen seine Tage als Requirements Engineer bei ASML und als Dozent am High Tech Institute, wo er sein Wissen und seine vielen Erfahrungen mit der nächsten Generation von Ingenieuren im Rahmen des „Verbesserung der SystemanforderungstechnikAusbildung“.

Abstraktionsschichten

Bei der Entwicklung von Systemanforderungen, insbesondere auf Systemebene, ist die Eingrenzung des Problems das A und O. Es geht darum, genau zu bestimmen, welche Funktionen das System haben soll, die spezifischen Eigenschaften, die mit diesen Funktionen verbunden sind, und das zu lösende Problem genau zu definieren. „Wenn wir zum Beispiel über die Projektion von Mustern auf Wafern sprechen, können Sie sich vorstellen, dass dies die Hauptfunktion des Systems ist, und dass mehrere Unternehmen dasselbe tun könnten. Aber es sind die Eigenschaften dieser Funktion, die einen Konzern von seinen Konkurrenten unterscheiden – die Genauigkeit, der Ertrag, die Geschwindigkeit und die Zuverlässigkeit“, betont Michielsen.

Für Michielsen sind es genau diese Eigenschaften, die den Unterschied ausmachen, und Requirements Engineering ist die Kunst, die richtigen Funktionen zu identifizieren und ihre Eigenschaften zu quantifizieren, um das Problem zu definieren. „Wenn das Problem erst einmal klar definiert ist, ist es viel einfacher, eine Lösung zu finden“, betont Michielsen. „Aber Sie werden die Implementierung Ihrer Lösung nicht auf Anhieb finden, also werden Sie wahrscheinlich eine Reihe von Abstraktions- oder Dekompositionsschichten durchlaufen.

Kaskade

Während seiner Schulung erklärt Michielsen, dass in einem System die höchste Abstraktionsebene die Ebene mit den allgemeinsten Anforderungen ist, d.h. das System muss schnell sein oder ein bestimmtes Aussehen haben. Wenn Sie jedoch tiefer in das System eindringen, wird es viel detaillierter. Plötzlich beziehen sich die Ebenen auf unterschiedliche Themen oder verwenden unterschiedliche Sprachen, um die Anforderungen auszudrücken, was für Ingenieure etwas schwierig sein kann, um den Informationsfluss aufrechtzuerhalten.

„Das ist das eigentliche Ziel des Requirements Engineering: verschiedene Wege zu finden, um sicherzustellen, dass die Daten von oben nach unten und von den Bedürfnissen der Stakeholder bis zur Implementierung kaskadenartig weitergegeben werden, ohne dass Informationen verloren gehen“, schlägt Michielsen vor. „Wenn ich die Herausforderung für das Requirements Engineering zusammenfassen sollte, würde ich sagen, dass sie hauptsächlich in der Kaskadierung von Informationen durch jede Abstraktions- oder Dekompositionsschicht liegt.“

Quantifizierung

Laut Michielsen besteht ein sehr wichtiger Teil der Methode darin, den vollständigen Satz an Anforderungen für ein System zu finden. „Die Frage lautet schnell: ‚Wann ist der Satz vollständig?'“, stellt er fest. „Der beste Ansatz, den wir bisher gesehen haben, lässt sich durch eine Gleichung ausdrücken, die wir in der Schulung vermitteln. Sie ermöglicht es uns, ein System durch seine Funktionen, Eigenschaften und Einschränkungen vollständig zu definieren und kann von den höchsten Ebenen bis hin zu den Komponenten und Teilen an den untersten Punkten angewendet werden.“ Er fährt fort: „Durch die Spezifizierung und Quantifizierung dieser Kriterien lassen sich die wahren Anforderungen ableiten. Das ist einer der wichtigsten Schritte in der Ausbildung: zu lernen, wie man die einzelnen Eigenschaften des Systems bewertet.“

„Sobald die Ziele definiert sind, können wir Lösungen – Designoptionen – auf der Grundlage der angenommenen Fähigkeiten der Teilsysteme identifizieren. Hier führt die Kreativität den Produktentwicklungsprozess an, da viele verschiedene Optionen zur Lösung des Problems in Betracht gezogen werden“, schildert Michielsen. „Solange wir die Annahmen, die während dieses kreativen Designprozesses getroffen werden, dokumentieren, können wir diese Annahmen später in Anforderungen für die untergeordneten Subsysteme übersetzen, die wir für die Lösung benötigen.

Rechtfertigung

Für Michielsen ist dies eines der stärksten Elemente der gesamten Methode. Die Fähigkeit, die komplette Logiklinie von einer quantifizierten Systemdefinition über die Designentscheidungen bis hin zur konkreten Umsetzung einer Lösung zu sehen. Das heißt, wenn die Ingenieure in der Lage sind, die Kohärenz zwischen den Systemanforderungen, dem Systemdesign und den Systementscheidungen zu wahren – ein entscheidender Faktor.

„Solange die Informationen richtig eingespeist werden, können wir die Anforderungen für die nächste Ebene ableiten und die Kaskade fortsetzen. Auf diese Weise können wir sicherstellen, dass wir durch unsere Methode und unsere Rückverfolgbarkeit jede Anforderung und jede Entscheidung, die wir in jeder Schicht treffen, genau begründen können, egal, welche Anforderungen wir am Ende auf der untersten Komponentenebene haben. Das ist das Wesentliche an der Methode.

„Als Trainer möchte ich dazu beitragen, Vertrauen in den Prozess zu schaffen“, sagt Michielsen.

Nach mehr als 30 Jahren in der Branche, was möchten Sie in Ihren Schulungen am meisten vermitteln?

„Als Ausbilder möchte ich dazu beitragen, Vertrauen in den Prozess zu schaffen. Das Befolgen der Methode ist eine Möglichkeit, das zu erreichen, denn die Studenten bekommen das Gefühl, dass das System vollständig, konsistent und korrekt sein kann – was die Spezifikationen angeht. Das kann wirklich dazu beitragen, dass es weniger beängstigend wirkt. Sobald Sie diese Hürde überwunden haben, können die Studenten fast sofort damit beginnen, die Hauptfunktionen des Systems zu bestimmen und zu entscheiden, welche Eigenschaften zusammenhängen und welche Einschränkungen auf dieser Ebene gelten. Indem sie diese Aspekte quantifizieren, sagen sie nicht nur, dass das System zuverlässig sein sollte, sondern sie sagen ausdrücklich, wie zuverlässig das System sein sollte.“

Gelernte Lektionen

In seinen mehr als 30 Jahren in der Prozessarchitektur hat Michielsen mehrere praktische Methoden entwickelt, um den Informationsfluss von Schicht zu Schicht zu gewährleisten. Sein Erfolg in diesem Bereich öffnete ihm die Tür für die Zusammenarbeit mit führenden niederländischen und europäischen Unternehmen wie Prorail, Eurocontrol, Punch Powertrain und Vanderlande – und einigen anderen, um ihnen bei der Einführung und Umsetzung von Prozessen für ihre eigenen Requirements Engineering Programme zu helfen. „Ich habe festgestellt, dass es enorme Unterschiede zwischen den einzelnen Unternehmen gibt, insbesondere bei der Umsetzung“, erinnert sich Michielsen. „Als ich bei DAF anfing, haben wir innerhalb von drei Jahren einen kompletten Requirements-Engineering-Prozess eingeführt. Wir konnten Hunderte von Ingenieuren erfolgreich schulen und die Methode zahlte sich aus.“

Angesichts des Erfolgs des DAF-Projekts rief Siemens an und lockte Michielsen nach Deutschland, um den gleichen Ansatz für Daimler zu etablieren. „Es war ein großer Schritt für mich, eingeladen zu werden, das System zu implementieren, aber es wurde schnell klar, dass der Ansatz, den wir bei DAF entwickelt hatten, nicht auf Daimler übertragbar war“, erinnert sich Michielsen. „Daimler war einfach völlig anders organisiert, und die Zuständigkeiten waren auf Abteilungen und Mitarbeiter verteilt, was eine erfolgreiche Umsetzung wirklich schwierig machte. Die Unfähigkeit, dort etwas auf die Beine zu stellen, war enttäuschend“, sagt er und fährt fort: „Es war sicherlich eine große Lernerfahrung für mich, und ich habe eine Menge harter Lektionen gelernt.“

Sind es diese Erfahrungen, die Sie in diesem Bereich antreiben?

„Teilweise, ja. Ich habe eine enorme Leidenschaft für diesen ganzen Prozess. Ich möchte dazu beitragen, die Produktkapazitäten und die Möglichkeiten der Produktherstellung zu verbessern, insbesondere in der Gegend, in der ich lebe und arbeite. Ich möchte die Industrie in diesem Sinne beeinflussen, denn wir haben so viel gelernt und ich möchte diese Informationen weitergeben“, betont Michielsen. „Das ist nicht nur mein Verdienst, sondern auch das der Unternehmen, für die ich gearbeitet habe, und all meiner Erfahrungen. Ich bin sehr dankbar dafür, dass ich das tun konnte, und ich möchte dieses Wissen weitergeben, damit das gesamte Ökosystem davon profitieren kann und wir daran wachsen.“

Dieser Artikel wurde von Collin Arocho geschrieben, Tech-Redakteur von Bits&Chips.