Der interdisziplinäre Ansatz des Systems Engineering ist eine Aufgabe von immer größerer Komplexität. Nur wenn Arbeitsschritte und Modifikationen über alle Designebenen hinweg rückverfolgbar sind und synchronisiert werden, können groß angelegte Entwicklungsprogramme rationalisiert werden. Häufig fehlt in einem Top-down-Designprozess jedoch ein Bindeglied zwischen dem Systems Engineering und der Design-Implementierung. Systems Engineering kommt die große Aufgabe zu, den Balanceakt zwischen immer größeren und komplexeren Systemen und deren vielfältige Anforderungen sowie den Einschränkungen hinsichtlich Leistung, Kosten, Markteinführungszeit, Energieverbrauch, Gewicht und anderen Bereichen zu meistern. Das Ergebnis dieses Prozesses ist in der Regel eine Reihe von Ausgangspunkten für das Design der Unterkomponenten mit Schnittstellenbeschreibungen, Unterbeschränkungen und abgeleiteten Anforderungen. Die größte Herausforderung besteht darin, sich auf jede Komponente im System zu konzentrieren, ohne den Überblick zu verlieren. Essentielle Informationen zum Systemkontext oder die Rückverfolgbarkeit der Anforderungen auf Systemebene und (abgeleiteter) Komponentenebene sind dabei von entscheidender Bedeutung. Ein einfacher Übergang für eine Weiterentwicklung des Systems und garantierte Konsistenz sind weitere wichtige Erfolgsfaktoren.
Zerlegung der Anforderungen
Zuerst sollte ein Anforderungsprofil erstellt werden. Ein Systems Engineering-Projekt beginnt typischerweise mit Anforderungen auf hoher Ebene und optional einem Vorgängersystem, das bis zu einem gewissen Grad wiederverwendet werden kann. Die Hauptaufgabe besteht dann in der Erstellung einer Architektur mit Unterkomponenten, die jeweils abgeleiteten Anforderungen zugeordnet sind, um ihren Anteil an der Gesamtfunktionalität zu erfüllen. Hierbei sind so viele Hierarchieebenen beteiligt wie nötig. Diese strukturelle Zerlegung geht also mit einer korrespondierenden Zerlegung der Anforderungen einher, sodass die Einschränkungen jeder Unterkomponente ausreichend definiert sind.
Nicht-funktionale Anforderungen
Viele Anforderungen beziehen sich auf Fragen des Lebenszyklus oder andere nicht-funktionale Einschränkungen wie Gewicht, Kosten, Zuverlässigkeit, Entwicklungsaufwand und andere domänenspezifische Designdaten. Dementsprechend muss eine Hierarchie von Stereotypen definiert werden, die jede Art von Unterkomponente repräsentiert und Eigenschaften nach Bedarf erfasst, einschließlich der oben erwähnten nicht-funktionalen Anforderungen.
Funktionale Anforderungen
Abgesehen von zeitlichen Randbedingungen werden funktionale Anforderungen in der Regel auf der Architekturebene nicht speziell behandelt, außer dass sie parallel zur Systemzerlegung ebenfalls in abgeleitete Anforderungen zerlegt werden. Die vollständige Analyse in diesem frühen Stadium ist mit formalisierten Anforderungen prinzipiell möglich. Aber aufgrund der Schwierigkeit, einen vollständigen Satz von Anforderungen und Annahmen zu erhalten, wird sie in der Praxis nur sehr selten angewandt. Stattdessen wird eine Simulation auf Komponenten- und Architekturebene vorgeschlagen, um die Konsistenz der Anforderungen sowohl lokal als auch im Gesamtsystemverhalten zu validieren. Dafür ist es essenziell, das Gesamtarchitekturmodell simulieren zu können, das zur Definition der Komponenten mit ihren Schnittstellen und Verbindungen verwendet wurde. So lassen sich viele Fehler vermeiden, die durch einen Bruch des Systems Engineering und des Designablaufs verursacht werden.