Eingebettete Systeme übernehmen heutzutage eine Vielzahl von Überwachungs-, Steuerungs- und Regelfunktionen und sind aus unserem alltäglichen Leben nicht mehr wegzudenken. Sie verrichten viefältige Aufgaben in diversen Anwendungsbereichen und Geräten wie zum Beispiel in Geräten der Medizintechnik, Flugzeugen, Fahrzeugen, Fernsehern, DVD-Playern und Mobiltelefonen. In komplexen Gesamtsystemen wie Fahrzeugen und Flugzeugen finden sich Vernetzungen von sonst autonomen, eingebetteten Systemen.</br> Die Entwicklung solch komplexer Gesamtsysteme weist einige Besonderheiten auf. Der Hersteller (z.B. Fahrzeug- oder Flugzeughersteller) zerlegt das komplexe Gesamtsystem in Teilsysteme und weist die Entwicklung dieser Teilsysteme einzelnen Abteilungen oder externen Zulieferern zu. Sind die Teilsysteme entwickelt, übernimmt der Hersteller wieder die Aufgabe, die entwickelten Teilsysteme zu einem Gesamtsystem zu integrieren. Natürlich erhalten die Zulieferer eine Liste von Anforderungen, die das von ihnen zu entwickelnde Teilsystem zu erfüllen hat. Dennoch haben sie aber auch viele Freiheiten bezüglich der Entwicklung dieser Teilsysteme. Der Hersteller hingegen hat eine Black-Box-Sicht auf die entwickelten Teilsysteme und kann bis auf kleinere Modifikationen keine größeren Änderungen an den geliefereten Teilsystemen vornehmen. Daher stellt die Integration der Teilsysteme zu einem komplexen Gesamtsystem eine große Herausforderung dar. Die Kommunikation zwischen Zulieferern und Herstellern kann und sollte verbessert werden. Wenn jeder Zulieferer nicht nur sein eigenes Teilsystem entwickeln würde, sondern auch die Erwartungen, die er an andere Teilsysteme hat, explizit machen würde, würde dies die Integration erheblich erleichtern. Doch häufig werden diese Erwartungen nicht systematisch und strukturiert dokumentiert und bleiben daher implizit. Um die Integration zu vereinfachen, sollten Zulieferer aber nicht nur die Anforderungen dokumentieren, die das von ihnen entwickelte Teilsystem erfüllt, sondern auch die Annahmen explizit machen, die sie über die Umgebung des Teilsystems treffen, im Folgenden als Domänenwissen (engl. domain knowledge) bezeichnet. Es reicht aber nicht aus, Entwicklern zu sagen, dass sie Domänenwissen dokumentieren sollten. Da sich Domänenwissen auf die Umgebung bezieht und die Umgebung ein Teil der realen Welt ist, stellt sich die Frage, was und wieviel über die Umgebung zu dokumentieren ist. Entwickler brauchen eine sytematische Unterstützung in dieser Hinsicht. Es gibt einige existierende Ansätze, die diese Unterstützung zum Teil bieten. Diese existierenden Ansätze sind aber nicht auf die Besonderheiten der Entwicklung eingebetteter Systeme zugeschnitten und stellen sich daher nicht den daraus resultierenden Herausforderungen. Das Ziel dieser Arbeit ist es daher, Methoden zu entwickeln, die die Dokumentation von Domänenwissen während des Requirements Engineerings unterstützen und auf die Besonderheiten eingehen, die sich aus der Entwicklung eingebetteter Systeme ergeben.</br> Ein eingebettetes System muss verschiedene Arten von Anforderungen (z.B. funktionale Anforderungen und verschiedene Arten von Qualitätsanforderungen) erfüllen. Für jede Anforderungsart muss eine andere Form von Domänenwissen dokumentiert werden. In dieser Arbeit wird daher die Frage beantwortet, welche Form von Domänenwissen für welche Anforderungsart dokumentiert werden muss und wie diese Dokumentation erfolgen kann (d.h. mit welcher Systematik und mit welchen Mitteln). Die folgenden Anforderungsarten werden dabei betrachtet: funktionale Anforderungen, Sicherheitsanforderungen in zweierlei Hinsicht: Security und Safety, Anforderungen an die Vertrauenswürdigkeit des Systems und Produktlinienanforderungen. Funktionale Anforderungen müssen betrachtet werden, da sie für jedes eingebettete Systeme relevant sind. Sicherheitsanforderungen im Bereich Safety sind von großer Bedeutung, weil eingebettete Systeme häufig Teil von komplexen sicherheitskritischen Systemen wie Fahrzeugen und Flugzeugen sind. Heutzutage werden diese komplexen sicherheitskritischen Systeme mit dem Internet verbunden. Dies resultiert bei Nutzern (aber auch anderen Beteiligten) in Bedenken bezüglich der Sicherheit (d.h. Security) und Vertrauenswürdigkeit dieser Systeme. Aus diesem Grund ist es notwendig, Sicherheits- (Security) und Vertrauenswürdigkeitsanforderungen zu betrachten. Da Hersteller und Zulieferer häufig Produktlinienansätze in ihren Entwicklungsprozessen einsetzen (um nicht nur ein System zu entwickeln, sondern mehrere Versionen eines Systems und damit einen größeren Markt bedienen zu können), werden darüber hinaus auch Produktlinienanforderungen betrachtet. </br> Die Methoden, die in dieser Arbeit vorgestellt werden, basieren auf der Nutzung von sogenannten Problemdiagrammen. Daher können die Methoden und somit die gesamte Arbeit als problem-basiert bezeichnet werden. Um die Anwendbarkeit der entwickelten Methoden zu veranschaulichen, werden zwei Fallstudien aus dem Automobilbereich genutzt.