Wie werden Anforderungen in Subsysteme zerlegt?

In dieser Episode des Zukunftsarchitekten-Podcasts geht es darum, wie Anforderungen in Subsysteme aufgeteilt werden können und welche Vorteile dies für das Projektmanagement hat. Wir erklären, dass es wichtig ist, Anforderungen von Kunden und Markt zu kennen, um erfolgreich Produkte verkaufen zu können. Neben den Systemanforderungen gibt es auch auf Unternehmensebene spezifische Anforderungen an Software, Elektronik, Elektrik und andere Bereiche. Diese Anforderungen müssen aufgeteilt werden, um die Umsetzung durch die entsprechenden Teams zu ermöglichen und Arbeitspakete zu bilden. Wir teilen die Anforderungen in funktionale Elemente auf, um ihnen bestimmte Funktionen zuzuweisen. Dadurch können wir die Anforderungen genauer planen und die entsprechenden Attribute und Metadaten festlegen. Eine bewährte Methode ist die Dreiteilung, bei der wir die Anforderungen grob und auf einer High-Level-Ebene aufschreiben, dann die Funktionen bestimmen, die mit diesen Anforderungen erfüllt werden müssen, und schließlich eine logische Aufteilung des Systems vornehmen. Wir nutzen den morphologischen Kasten, um verschiedene Möglichkeiten zur Erfüllung der Funktionen zu betrachten und Varianten zu bilden, die später bewertet werden können. Dadurch können wir die Anforderungen strukturiert aufteilen und besser verfolgen, welche bereits umgesetzt sind und welche noch bewertet werden müssen. Bei der Architekturbewertung können verschiedene Kriterien wie Preis oder Entwicklungsgeschwindigkeit betrachtet werden. Nachdem ich meine Auswahl aus dem morphologischen Kasten getroffen habe, überführe ich meine funktionale Architektur in eine logische Architektur und weise dort die einzelnen Elemente zu. Es kann sein, dass beim Einbau der Elemente in das Produkt weitere Anforderungen auftauchen, die zuvor nicht berücksichtigt wurden. Diese Anforderungen werden ebenfalls dokumentiert und den logischen Elementen zugewiesen. Auf der physikalischen Ebene betrachten wir die mechanischen Bauteile, Elektronik und Software, die auf dem System läuft. Auch Software betrachte ich als physikalisches Element, da sie auf dieser Ebene besser einzuordnen ist und oft ein eigenes Software-Team vorhanden ist. Bei den physikalischen Elementen schaue ich zunächst, welche bereits im Unternehmen vorhanden sind und wiederverwendet werden können. Falls dies nicht der Fall ist, gucken wir, was mit kleinen Änderungen wiederverwendet werden kann. Im schlimmsten Fall entsteht ein neues Teilprodukt oder eine Bausteinvariante. Im besten Fall kann ein Baustein sowohl im alten als auch im neuen System verwendet werden. Es spart Zeit, vorhandene Bausteine wiederverwendet, solange die Änderungen akzeptabel sind. Es besteht auch die Möglichkeit, Zukaufteile wie Widerstände oder Embedded-Systeme wie Arduino oder Raspberry Pi zu verwenden. Diese müssen jedoch auch Industrie-Tauglichkeit, EMV, etc. erfüllen. Man kann sie entweder direkt zukaufen oder bei der eigenen Entwicklung oder einem externen Entwicklungsunternehmen beauftragen. Es entstehen weitere Anforderungen, wenn wir physikalische Elemente gestalten, die unseren logischen und funktionalen Architekturen entsprechen. Zum Beispiel benötigen wir für die Erhitzung eines Gartengrills einen Brenner. Die Implementierung eines solchen Brenners erfordert spezifische Schnittstellen wie ein Ventil zum Regulieren des Gaseinlasses. Hier müssen wir uns überlegen, welche Anforderungen sich aus dem Einsatz dieses Ventils ergeben, wie beispielsweise der Durchmesser und die Anschlussgeometrie. Auch die Luftzufuhr und der Abgasschutz müssen berücksichtigt werden. Indem wir unser System dekomponieren und Entscheidungen treffen, können wir die erforderlichen Anforderungen filtern und ihnen Traceability und Informationen zuordnen. Zusammenfassend gibt es drei Tipps: Klarheit über die Teams und Organisationseinheiten im Unternehmen, Erstellung des Systemdesigns und Zuordnung von Anforderungen zu den Systemelementen, und die Erzeugung von Sublastenheften für externe oder interne Teams. Wenn du Unterstützung bei der Anwendung oder Einführung von Systems Engineering benötigst, kontaktiere mich per E-Mail. Vielen Dank fürs Zuhören und viel Erfolg bei dem, was du tust. Auf Wiedersehen bis zum nächsten Mal.