Episode 211 – Wie werden Anforderungen in Subsysteme zerlegt? Music. Herzlich willkommen beim Zukunftsarchitekten, der Systems Engineering Podcast für Macher und Entscheider. Am Mikrofon ist wieder Björn Schorre. Als Systemingenieur gebe ich dir Tipps und Impulse, damit du dein Projekt zum Erfolg führen kannst.
Music. In der heutigen Episode wirst du erfahren, wie Anforderungen an ein Gesamtsystem so aufgeteilt werden können, dass du sie den Subsystemen zuweisen kannst und welche Vorteile dieses Vorgehen für dein Projektmanagement hat. Ja, herzlich willkommen, liebe Hörer, liebe Hörerinnen hier bei mir im Podcast. Ich habe
eine Hörerfrage von Gunther bekommen. Gunther fragte mich, das Zerlegen einer Gesamtheit an Anforderungen, also Klammer auf komplette Maschine, in Subsysteme und die strukturelle Aufteilung der Anforderungen aufbereitet für die einzelnen Gewerke, nämlich Mechanik, Elektrik, Elektronik, Software. Das ist seine größte Herausforderung bei den Anforderungen und bei der Architektur.
Ja, und da habe ich mir dann überlegt, wie kann ich auf diese Frage antworten? Und ich möchte erst einmal ganz, ganz sachte anfangen und einmal die Frage stellen, warum müssen Anforderungen überhaupt aufgenommen werden? Warum sind sie überhaupt zu Anfang so wichtig? Also ganz zu Anfang ist es natürlich wichtig zu wissen, was will der Kunde oder was will das Produktmanagement überhaupt haben.
Das ist notwendig, damit über den Vertrieb diese Produkte nachher auch in den Markt gebracht werden können und darüber dann der Umsatz generiert werden kann. Also da sollte drinnen stehen, die Anforderungen vom Kunden oder vom Markt oder von irgendwelchen Stakeholdern. Da sollte drinnen stehen, was überhaupt gewünscht wird, was notwendig ist, damit das Produkt am Markt zum Erfolg werden kann.
Dann werden wir Anforderungen haben oder erstellen müssen aus der Entwicklungsabteilung selber, und das fängt schon auf Systemebene oder Gesamtsystemebene an. Da soll drinstehen, wie sich denn die Entwicklungsmannschaft, also das gesamte Team, denkt, wie diese Anforderungen, die vom Markt, vom Kunden kommen, wie die denn umgesetzt werden können. So, und dann ist das quasi die Antwort auf das, was der Produktmanager sich erstmal gewünscht hat.
Ich sag mal, der Kunde kann sich natürlich, oder der Produktmanager, also der Auftraggeber am Ende des Tages, kann sich natürlich alles Mögliche wünschen. Aber es gibt gewisse Einschränkungen, technische, organisatorische, vielleicht sogar noch weitere, die für ein Entwicklungsteam gewisse Grenzen aufzeigen. Und dann können die nur in einem gewissen Rahmen diese Anforderungen erfüllen. Also das ist die Antwort darauf. Und diese
bezeichnet man üblicherweise dann als die Systemanforderungen. Also das, was das Entwicklungsteam realisieren kann, das was von der Hinsicht her technisch möglich ist. Und dann gibt es noch weitere Ebenen, die nach Bedarf mit Anforderungen gefüllt werden müssen. Üblicherweise orientieren sich diese Ebenen dann auch an der Unternehmensstruktur. Also wenn ich eine Softwareabteilung habe, dann wird es üblicherweise auch irgendein Element geben, was sich Software XY nennt.
Und dann werde ich Anforderungen an dieses Softwareelement haben. Habe ich eine Elektronikentwicklung, zusammen mit einer Elektrikentwicklung, dann habe ich wahrscheinlich dort irgendwie ein, zwei Teile, die sich irgendwie was Elektronik-Elektrik schimpfen.
Es kann natürlich auch sein, dass es zwei Abteilungen sind. Ich habe es erlebt, da gab es eine Steuerplatine, die wurde natürlich nur mit 5 bis 12 Volt betrieben, und Niederspannungsbereich und es gab dann das Hochvolt-Team, also eine Leistungselektronik-Abteilung. Also sowas gibt es dann halt auch, da wird dann halt auch nochmal entsprechend aufgeteilt. Und diese Systemelemente, die werdet ihr nachher dann auch finden und daran Anforderungen herauskristallisieren.
Da gibt es noch viele weitere Teams, Abteilungen, Organisationseinheiten, die daran beteiligt sein können. Das waren jetzt nur zwei, drei, die ich genannt habe. Es kann aber auch noch irgendwas in Richtung Mechanik geben, natürlich. Optik könnte auch ein Punkt sein oder irgendwas in Richtung Chemie, Bio. Wenn man so an Medizintechnik denkt, dann könnte da auch sowas auftauchen. Also das hat aber auch sehr stark mit der Unternehmensstruktur zu tun, wie die aufgestellt ist.
Und daraus wird sich das dann herauskristallisieren, wie ihr das aufteilen werdet oder müsst. Ja, und damit komme ich dann zum ersten Teil der Frage von Gunther. Warum müssen die Anforderungen eigentlich aufgeteilt werden? Zum einen ist mir dann eingefallen, natürlich muss ich die aufteilen, weil es werden auf Stakeholder-Ebene oder System-Ebene nicht alle Anforderungen beschrieben, also im kleinsten Detail, weil ich das auf den Ebenen auch noch gar nicht brauche.
Das ist nicht wichtig, zu beschreiben, wie der Softwarezustand von einer Komponente in einer bestimmten Situation ist. Das muss ich da auf der Top-Ebene nicht beschreiben. Ich werde noch einen weiteren Podcast aufnehmen, da geht es nochmal darum, welche Attribute wann wo beschrieben werden sollten. Und den werde ich dann auch verlinken in den Show Notes.
Also, was ich dann brauche ist, oder was ich dann machen werde, mit den Anforderungen, ich werde üblicherweise weitere Anforderungen finden und weitere Anforderungen erheben müssen, um mein System noch besser zu beschreiben, noch detaillierter zu beschreiben, und zwar für die jeweiligen Teams, die dann damit zu tun haben.
Warum muss ich die Anforderungen noch aufteilen? Aus diesen Anforderungen werden üblicherweise dann Arbeitspakete geschnürt, die an Teams oder an Mitarbeitende weitergegeben werden oder denen zugelost werden, zugeordnet werden, damit die diese Anforderungen dann auch entsprechend umsetzen können. Auch sind diese Arbeitspakete Teil des Projektstrukturplans vom Projektmanagement. Also, dieser Projektstrukturplan, der bricht ja alle Arbeiten, die im Projekt getan werden müssen, so auf,
dass sie einzeln kontrolliert werden können. Sind sie schon angefangen, sind sie gerade in der Bearbeitung? Gibt es vielleicht irgendwelche Probleme, müssen wir irgendwo steuern? Also dafür ist es wichtig, dass im Projektstrukturplan diese Elemente alle enthalten sind. Warum muss ich sie noch aufteilen? Es kann auch sein, dass wir Teile unseres Systems nehmen und die nicht unbedingt im eigenen Haus entwickeln und so muss es ein Sublastenheft geben.
Also angenommen, wir sind ein Softwarehaus und wir haben plötzlich eine Embedded-Elektronik zu entwickeln. Ja, Software, okay, das können wir, aber den Elektronikteil, den können wir nicht. Und da ist es jetzt gut, wenn wir da ein Sublastenheft erstellen können, was wir dann an eine Firma rausgeben können, die uns diese Elektronik entwickelt. Und dann hilft uns dieses Sublastenheft, da vielleicht ein, zwei Angebote einholen zu können und dann bewerten zu können, bei wem wir was machen wollen.
Und denen dann diesen Auftrag zuschustern. Also ich habe dann ein Sublastenheft für einen Teil meines Gesamtsystems und kann das dann entsprechend nach außen geben und mir entwickeln lassen. Ja, und dann brauche ich diese Anforderungen ja auch, um sie zu verfolgen. Also ich möchte natürlich wissen, welche Anforderungen sind schon umgesetzt von meinem Gesamtpaket? Welche sind noch gar nicht bewertet? Wo hängen vielleicht schon Testfälle hinter und wo eben nicht?
Also all solche Fragen tauchen ja auf in einem Projekt und je besser ich dann meine Anforderungen da strukturiert habe und je besser ich mir im Vorfeld überlegt habe, welche Aussagen muss ich denn treffen in Richtung des Projektleitenden oder des Topmanagements, desto besser weiß ich auch im Vorfeld, wie ich die Anforderungen schreibe, wie ich sie aufteile, welche Attribute und welche Metadaten dann entsprechend auch gefüllt werden müssen.
Ja, so, und wie kommen wir jetzt dazu, dass wir die Anforderungen überhaupt aufteilen können und diesen Systemelementen auch zuweisen können? Aus meiner Sicht hat sich immer eine Dreiteilung relativ gut bewährt, und zwar, wenn ich die Anforderungen auf einer sehr groben und sehr High-Level-Ebene schon mal aufgeschrieben habe, dann wird sich üblicherweise schon mal herausstellen, dass ich gewisse Funktionen mit diesen Anforderungen erfüllen muss.
Oder mit meinem System erfüllen muss. So, und was will ich jetzt machen? Ich will natürlich diese Anforderungen, diesen funktionalen Elementen, diesen funktionalen Einheiten auch irgendwie zuweisen. Und deswegen muss es aus meiner Sicht dann dort so eine funktionale Aufteilung geben.
Dann erst kann ich die Anforderungen zuweisen, diesen funktionalen Elementen, Das heißt also, wenn da zum Beispiel eine Funktion, die die Funktion eines Grills ist, wo dann etwas erhitzt werden soll, dann hätte ich diese Funktion Erhitzung und dort kann ich dann gewisse Anforderungen drauf allokieren.
Der muss ja auch irgendwo stehen, der braucht irgendwo eine Kraftübertragung, dass er nicht einfach umkippt oder sowas, das wäre dann irgendwo die Standfläche oder die Stoßdämpfung, sodass ich dann dort den weiteren Anforderungen an diese Funktionen zuweisen kann. Wenn ich das gemacht habe, dann weiß ich ja aber immer noch nicht, wie kann ich denn diese Funktion umsetzen.
Und da gehen wir jetzt in die logische Architektur rein, machen dort eine logische Aufteilung oder ein logisches Design von unserem System und dazu nutzt man üblicherweise, ich habe es kennengelernt in der Mechanikentwicklung, da gibt es einen sogenannten morphologischen Kasten. In einem morphologischen Kasten gibt es jetzt für eine spezielle Funktion, also bei uns war es jetzt die Erhitzung, da gibt es jetzt verschiedene Möglichkeiten, um das zu machen.
Das wäre natürlich zum einen, indem wir da irgendwie einen Elektrostab drunter machen, der über elektrische Energie erhitzt wird oder Hitze erzeugt. Oder ich kann mir überlegen, na, das möchte ich lieber mit einem offenen Feuer machen. Und das heißt also, wir brauchen da irgendeine Art von Brenner. Genau, ein Gasbrenner. Oder ich kann natürlich auch überlegen, okay, wenn ich beim offenen Feuer bin, dann könnte ich natürlich auch einen anderen fossilen Brennstoff noch da drunter legen,
um von dort dann die Hitze zu bekommen. Also das wäre jetzt der Inhalt eines morphologischen Kastens für dieses funktionale Element der Erhitzung. Und da kann ich mir jetzt daraus auswählen, was ich denn ganz gerne haben möchte. Und jetzt gibt es in so einem morphologischen Kasten nicht nur diese eine Funktion und diese drei Möglichkeiten, sondern es gibt ja noch viele weitere Funktionen. Wir hatten das ja eben mit der Stoßdämpfung für den Grill,
der dann irgendwo auf die Standfläche greift. Also diese Stoßdämpfung, die könnte jetzt auch über verschiedene Möglichkeiten gehen. Und so kann man denn diesen morphologischen Kasten nutzen, um daraus sich gewisse Varianten zu bilden. Das könnte einmal die luxuriöse Variante sein oder die kostengünstigste Variante. Also solche Spielarten gibt es dann daraus und da kann ich dann diese Varianten bilden und das nachher dann auch bewerten.
Bewertung geht dann in verschiedene Richtungen. Ich hatte es ja gerade gesagt, einmal wäre es bestimmt der Preis, der andere Bewertung wäre vielleicht die Entwicklungsgeschwindigkeit. Also solche Sachen kann man dann dort tun. Wenn ich also fertig bin mit der Auswahl aus meinem morphologischen Kasten, dann habe ich meine funktionale Architektur in eine logische Architektur überführt und kann dann dort auch wiederum die Zuweisungen machen.
Also man sieht genau, die funktionalen Elemente werden jetzt ersetzt durch logische Einheiten, und ich kann dann dort diese Verbindungen herstellen, damit ich halt da auch die Anforderungen entsprechend durchreichen kann. Jetzt kann es sein, wenn wir aus dem morphologischen Kasten Elemente genommen haben und eingebaut in unserem Gartengrill, den ich hier jetzt als Beispiel mal hatte, dann kann es sein,
dass dort weitere Anforderungen herausfallen. Also diese weiteren Anforderungen tauchen jetzt, ich sag mal, plötzlich auf, weil wir mehr ins Detail gegangen sind, weil wir wissen, wie wir diesen Grill genauer bauen wollen. Und jetzt tauchen da plötzlich diese zusätzlichen Anforderungen auf, wo wir uns vorher noch gar keine Gedanken drum gemacht haben oder gemacht konnten. Auch die sollte ich dokumentieren und auch die weise ich dann hier an dieser Stelle
schon diesen logischen Elementen zu. Das kann ich jetzt direkt hier machen, weil mir ist ja klar, die sind deswegen entstanden, weil ich dieses logische Element entdeckt habe. Zu guter Letzt geht es dann in die sogenannte physikalische Ebene, physikalische Architektur und dort werde ich natürlich physikalische Elemente entdecken.
Und hier möchte ich einmal einen kleinen Hinweis geben. Für mich sind physikalische Elemente natürlich die Mechanikbauteile, die ich benötige, um überhaupt eine Tragstruktur aufbauen zu können, um Kräfte leiten zu können und so weiter. Dann natürlich die Elektronik und auch die Software,
die auf dem System läuft. Viele sagen, Software kann ich ja nicht anfassen, also ist es kein physikalisches Element, aber wenn ich es auf diese Ebene einsortiere, dann habe ich gedanklich, das besser vor Augen, wo denn diese Software angeordnet werden kann. Und wenn ich die Software irgendwie mal auf eine CD brenne oder auf einen USB-Stick packe, dann könnte ich auch sagen, so hier ist sie drauf und das ist das physikalische Element. Ich lege jetzt mal alle drei Sachen nebeneinander.
Und habe dann dort meine Teilsysteme, Teilelemente vorliegen. Also das ist so für mich meine kleine Erklärung, warum ich Software auf dieser Ebene als eigenes Element betrachte. Außerdem noch ein weiteres Argument, in der Organisationsstruktur taucht ja auch oft das Software-Team auf, eine Software-Abteilung auf, weil genau die da Experten haben, die sich um die Softwareentwicklung kümmert und auch um die Systeme, die dann die Software baut.
Also, das kurz dazu, das ist meine Meinung, deswegen sehe ich hier als physikalisches Element auch die Software in dieser Architektur. So, was können wir jetzt hier mit den physikalischen Elementen machen? Zunächst einmal schau dich in deinem Unternehmen um, welche Elemente dort schon vorhanden sind. Oftmals gibt es schon erste grobe Blöcke, erste Entwürfe, die schon da sind.
Vielleicht wird das auch schon jahrelang irgendwo eingebaut und du kannst es einfach so weiterverwenden in deinem ja jetzt neuen System, was gebaut werden soll. Ist das nicht der Fall, auch dann gucken, was kann wiederverwendet werden. Was kann unter Umständen mit kleinen Änderungen wiederverwendet werden? Weil, ehrlich gesagt, können auch Bausteine, die schon länger verwendet werden, ja auch mit etwas wenig Aufwand angepasst werden.
Im schlimmsten Fall macht man daraus ein neues Teilprodukt, einen neuen Baustein oder eine Bausteinvariante. Die bekommt dann eine neue Nummer. Das ist in diesem Fall dann der schlimmste Fall. Im einfachsten Fall wird es so verändert, dass es in dem Altsystem wie auch in dem Neusystem weiterverwendet werden kann. Das wäre natürlich besonders charmant. Aber das muss man entsprechend bewerten, wie groß dann die gewünschten Änderungen daran sind.
Wichtig ist, spart euch Zeit dadurch, dass ihr die Dinger wieder verwendet, wenn sie schon da sind und wenn die Änderungen in einem gewissen Rahmen akzeptabel sind. Dann kann es sein, dass ihr in dem Produkt, was ihr baut, wo ihr sollt, auch einfach Zukaufteile reinpackt. Ganz einfach sieht man das, wenn wir eine Elektronikentwicklung machen, dann werden Widerstände nicht selber entwickelt, sondern die werden zugekauft.
Und genauso kann es natürlich auf einer höheren Ebene sein, wenn ihr euch überlegt, Okay, ich brauche hier ein kleines Embedded-System. Dann könnte man sich überlegen, ob man das mit einem Arduino macht oder mit einem Raspberry Pi. Ja, den gibt es schon am Markt. Könnte man zukaufen und einbauen. Jetzt muss der natürlich auch unsere Anforderungen an Industrie-Tauglichkeit, an EMV und so weiter erfüllen.
Das ist dann entsprechend auch wiederum zu bewerten, oder man schaut, welcher Raspberry Pi als Zukaufteil kann denn diese Anforderungen erfüllen. Das bedeutet wiederum, ich kann nicht den aus dem Hausgebrauchskatalog bestellen, sondern ich muss dann vielleicht zu einer speziellen Firma gehen, die Raspberry Pis industrietauglich gemacht hat. Aber auch das geht, auch da kann ich mich umschauen und kann halt Teile zukaufen.
So, und dann gibt es die Möglichkeit, dass ich die physikalischen Elemente, die ich brauche, auch bei der eigenen Entwicklung im Haus, oder vielleicht auch extern, wenn es ein externes Entwicklungsunternehmen gibt, was das machen kann, dass ich das dann dort beauftrage. Auch da brauche ich diese physikalischen Elemente, also da werde ich diese physikalische Aufteilung benötigen, um diese Entwicklung entsprechend zu beauftragen. So, und auch hier werden wiederum weitere Anforderungen entstehen.
Wenn ich also diese physikalischen Elemente gestaltet habe, wie ich sie verwenden möchte, wo ich mir vorstellen kann, dass diese, die meine logische Architektur und meine funktionale Architektur erfüllen, Dann habe ich da auch wiederum Anforderungen, weil jetzt habe ich natürlich auch sehr, sehr konkrete Schnittstellen, wenn wir jetzt mal zurückgehen auf unseren Gartengrill, da habe ich ja gesagt, wir brauchen für die Erhitzung, nehmen wir vielleicht mal einen
Brenner und jetzt gibt es die Implementierung des Brenners, dass wir da vielleicht einen Ring unten drin liegen haben, wo dann das Gas eingeströmt wird. Und dieses Gas muss natürlich über ein Ventil geregelt werden können und dieses Ventil kaufe ich mir jetzt vielleicht auch noch wiederum zu. Oder das Ventil kaufe ich mir zu, so. Aber den Ringbrenner, den muss ich selber entwickeln und jetzt muss ich natürlich gucken.
Welche Anforderungen entstehen mir jetzt hier, dadurch, dass ich dieses Ventil eingekauft habe, weil das Ventil wird einen bestimmten Durchmesser haben, einen bestimmten Anschlussgeometrie haben und darauf muss ich eingehen. Das muss ich jetzt als Anforderung an meinen Ringbrenner mit in mein System übernehmen.
Außerdem entstehen dort ja jetzt auch, oder muss ja zur Verbrennung auch noch irgendwie die Luft zugeführt werden, wenn der Verbrennungsvorgang zustande kommt, durchgeführt wird, dann entstehen ja auch wiederum Abgase. Also muss ich mir jetzt überlegen, wie kriege ich von diesem Brenner die Luft hinzugefügt und die Abgase wieder abgeführt. Also solche Sachen muss ich mir jetzt dann an der Stelle überlegen und diese Anforderungen hier dann entsprechend eintragen.
Ja, und auch die physikalischen Elemente sind natürlich verlinkt und verbunden mit den Elementen aus der logischen Architektur und den Funktionen aus der funktionalen Architektur. Und weil ich ganz oben die Anforderungen, die Top-Level-Anforderungen daran angehängt habe, kann ich da jetzt eine Traceability aufbauen und herausfiltern, welche Anforderungen denn für das physikalische Element umgesetzt werden müssen.
Also durch diese ganze Dekomposition meines Systems und die Entscheidungen, die ich da auf diesem Weg getroffen habe, kann ich jetzt die Anforderungen herausfiltern, die für das eine oder das andere Element umzusetzen sind. Und auch die Anforderungen, die auf der logischen Ebene oder auf der physikalischen Ebene noch dazugekommen sind, auch die zählen natürlich dazu und ich kann sie dann entsprechend mit herausziehen.
Ich habe vorhin vom morphologischen Kasten gesprochen. In der Mechanik-Entwicklung ist der durchaus bekannt, in der Software-Technik eher weniger. Hast du eventuell ein Beispiel aus dem Bereich der Software-Technik, was du mir nennen kannst, dann gehe in die Show Notes, klicke auf meine E-Mail, die du unten findest und schreibe mir eine Mail. Ich werde das dann aufnehmen und den Hörern hier in den Show Notes nach und nach zur Verfügung stellen.
Zusammenfassend zu der heutigen Episode habe ich nochmal drei Tipps für dich. Zum einen werde dir klar darüber, welche Teams in deinem Unternehmen oder welche Organisationseinheiten in deinem Unternehmen vorhanden sind, denn üblicherweise wird deine Systemarchitektur nachher auch so oder ähnlich aussehen.
Dann erstellst du dein Systemdesign, deine Architektur, wählst die Elemente aus, die du dann da verwenden willst und ordnest dann die Anforderungen diesen entstandenen Systemelementen zu und bist dann in der Lage, daraus Sublastenhefte zu erzeugen.
Die kannst du nicht nur, wie ich es eben gesagt habe, für die Beauftragung von externen Entwicklungen benutzen, sondern auch als Sublastenhefte für die Teams, für die internen Teams, denn die sind ja auch angewiesen darauf, dass sie einen Auszug von den Systemanforderungen bekommen, damit sie sich auf diese konzentrieren und nicht alles Mögliche andere auch noch versuchen zu entwickeln.
Sondern du bist ja dafür verantwortlich, das aufzuteilen als Systemingenieur und musst das dann auch deinen Teams entsprechend übergeben und zur Verfügung stellen. Du bist dabei, Systems Engineering anzuwenden oder musst es in deiner Firma einführen. Der Fortschritt lässt aber zu wünschen übrig. Dann scrolle in den Show Notes nach unten, dort findest du meine E-Mail-Adresse. Klicke da drauf, schreibe mir eine E-Mail und ich melde mich bei dir, damit wir darüber sprechen, wie ich dir helfen kann.
Das war die heutige Episode des Zukunftsarchitekten, der Systems Engineering Podcast für Macher und Entscheider. Mein Name ist Björn Schorow und ich danke Dir fürs Zuhören. Hab Spaß an dem, was Du machst und vor allem auch einen hohen Wirkungsgrad. Tschüss und bis zum nächsten Mal. Music.