Eine Anforderungsebene besteht aus fachlichen Inhalten und ihrer Dokumentation. Die fachlichen Inhalte derselben Ebene sind dadurch gekennzeichnet, dass sie einem gemeinsamen Zweck dienen (im Falle der Systemanforderungen, das System vollständig und lösungsneutral zu beschreiben) und dass sie ein ähnliches Abstraktionsniveau aufweisen. Darüber hinaus haben die Inhalte einer Ebene gemeinsam, dass die Erstellung der nächsten Ebene eines ähnlichen Transformationsschrittes bedarf. Etwa im Falle des Übergangs von Kunden- zu Systemanforderungen besteht der Transformationsschritt aus einer Vervollständigung und Detaillierung der Kundenanforderungen und ihrer Übersetzung in die Sprache des Systemherstellers.
In aller Regel sind verschiedene Ebenen unterschiedlichen Verantwortungsbereichen innerhalb einer Organisation zugeordnet. Häufig werden zur Erstellung und Pflege der verschiedenen Ebenen unterschiedliche Methoden [3], Werkzeuge, Dokumente und Prozesse verwendet. Zum Beispiel werden für die Pflege der Systemanforderungen oft Werkzeuge des Requirements- Engineerings eingesetzt, für die Systemarchitektur hingegen Modellierungswerkzeuge.
Um verschiedene Ebenen noch klarer gegeneinander abzugrenzen, bleibt zu bemerken, dass sich eine Anforderungsebene in den seltensten Fällen dadurch auszeichnet, dass die fachlichen Inhalte dieser Ebene vom selben Autor oder von derselben Abteilung erstellt werden. Auch die Verbraucher der fachlichen Inhalte einer Ebene sind in aller Regel ganz unterschiedlich. Betrachtet man die Systemarchitektur, so stellt man fest, dass sowohl die Software- Abteilung als auch die Mechanik- und Hardware-Abteilung die Systemarchitektur als Input zur Erstellung ihrer Arbeitsergebnisse benötigen.
Die Abgrenzung der verschiedenen Ebenen gegeneinander und die Zuordnung der fachlichen Inhalte zur gleichen Ebene sind wichtig und nötig, da im Entwicklungsprojekt ansonsten der richtige Umgang mit den Anforderungen nicht möglich ist. Es wäre schwierig, bei vermischten Ebenen den Überblick zu behalten und dem Zweck der Ebene Genüge zu leisten. Wer etwa die Systemanforderungen bereits mit Lösungsvorschlägen versieht, die in der Systemarchitektur ihren Platz haben, verliert die Wiederverwendbarkeit der Systemspezifikation und die Austauschbarkeit der Systemarchitektur zugunsten besserer Lösungen [4].
Die Familien-Lasagne
Nun soll die gesamte Lieferantenkette betrachtet werden, die nötig ist, um die ursprüngliche Vision des OEM zu realisieren (Bild 2). Die Lieferantenkette besteht aus dem OEM an der Spitze, der mit einigen direkten Lieferanten zusammenarbeitet. Der OEM holt alle Entwicklungsprodukte seiner Lieferanten ein und stellt sie auf Basis seiner System- und Subsystemarchitektur zu einem Gesamtsystem „Fahrzeug“ zusammen. Aus der Menge der direkten Lieferanten greifen wir exemplarisch den Lieferanten für das Radio-Navigationssystem heraus. Das Radio-Navigationssystem stellt hierbei einen Teil des beim OEM definierten Infotainment- Subsystems dar und dient dazu, die Positionierung des Fahrzeugs im Premium-Segment zu unterstreichen.
Der Hersteller des Radio-Navigationssystems hat seinerseits wiederum einige Zulieferer, unter anderem einen Lieferanten für die Navigations-Hardware, bestehend aus einer eigenen Platine und einem eigenen Prozessor, auf dem die aufwendigen Navigationsberechnungen vorgenommen werden sollen. Der Lieferant für die Navigations- Hardware beauftragt seinerseits einen Zulieferer für die Erstellung einer Navigations- DVD, welche die Kartendaten und die Ansagetexte für die Sprachansagen in verschiedenen Sprachen enthält. Die Richtungshinweise über Sprachansagen sollen die Fahrsicherheit erhöhen. Zusätzlich zu der DVD liefert der Hersteller eine Software- Bibliothek mit einfachen Zugriffsfunktionen auf die Kartendaten.