Das Dokument behandelt die Bedeutung des Requirements-Engineerings (RE) in der Softwareentwicklung, wobei es auf die Notwendigkeit einer systematischen Erfassung und Analyse von Anforderungen hinweist, um die Qualität und Kosten von Systemen zu optimieren. Es beschreibt die Herausforderungen bei der Anforderungsdefinition und -dokumentation sowie die Notwendigkeit, diese Prozesse zu standardisieren, insbesondere in globalen und interdisziplinären Projekten. Ziel ist die Entwicklung eines Requirements-Engineering-Referenzmodells, das eine strukturierte und benchmarks-orientierte Vorgehensweise bietet, um den steigenden Anforderungen an Softwareprodukte gerecht zu werden.

1. HAUPTBEITRAG / REQUIREMENTS-ENGINEERING }
Ein Requirements-Engineering-
Referenzmodell
Manfred Broy · Eva Geisberger
Jürgen Kazmeier · Arnold Rudorfer
Klaus Beetz
Requirements-
Engineering ist Sehr früh war gerade Folge von Aufgaben der Anforderungsdefinition
integraler Bestand- im Umfeld der Soft- und Detaillierung, aber auch der Überprüfung der
teil der Entwicklung wareerstellung den Anforderungen durch Validierung und Verifikation.
von Produkten, von Entwicklern aus guten Untersuchungen zeigen, dass das Beherrschen
Systemen und natürlich Gründen bewusst, dass der Anforderungen und der Anforderungsanalyse
auch von Software. Anforderungen und eine der wichtigsten Erfolgsvoraussetzungen für
Anforderungsanalysen die Durchführung von Projekten ist. Umso mehr
entscheidend für die erfolgreiche Durchführung erstaunt es, dass es bisher keine allgemeingültigen
von Softwareprojekten sind. Eine Vielzahl unter- Ansätze zur Durchführung der Anforderungsanalyse
schiedlicher Ansätze in Praxis und Wissenschaft gibt. Auch die Dokumentation von Anforderungen
zielen auf die Analysephase, allerdings häufig nur und die Frage, was dabei alles zu berücksichtigen ist,
auf bestimmte Aspekte. Eine ganzheitliche Anfor- ist bisher nicht wirklich in umfassenden Ansätzen
derungsanalyse für Softwaresysteme und allgemein dargestellt. Das ist umso kritischer, als – gerade
Systeme mit hohem Softwareanteil schließt viele für die Praxis – eine stärkere Standardisierung der
unterschiedliche Gesichtspunkte ein, angefan- Anforderungsdokumente von hoher Bedeutung
gen von den generellen Geschäftszielen über die ist, da es in der Zusammenarbeit zwischen unter-
funktionalen Anforderungen, die festlegen, wel- schiedlichen Firmen äußerst hilfreich wäre, auf
che Funktionen im Sinne der Nutzer ein System einheitliche Verfahren zur Definition und Festlegung
realisiert, werden bis hin zu den vielfältigen nicht- der Anforderungen zurückzugreifen.
funktionalen Anforderungen, die sich auf Fragen Natürlich betreffen gerade die Festlegungen der
der Qualität, der Kosten, der Entwicklungszeit, des Anforderungen alle Aspekte eines Softwaresystems,
Entwicklungsprozesses und vieles mehr richten. da die Anforderungen sich auf die unterschiedlichs-
Einleitung
DOI 10.1007/s00287-007-0149-5
Mit den wachsenden Umfängen und der steigen- © Springer-Verlag 2007
den Komplexität von Software, mit der Zunahme Manfred Broy · Eva Geisberger
der Rolle von Software als Innovationstreiber für Technische Universität München,
Boltzmannstr. 3,
Systeme und Produkte kommt dem Requirements- 85748 Garching
E-Mail: broy@in.tum.de, geisberg@in.tum.de
Engineering eine immer tragendere Rolle zu. Hinzu
Jürgen Kazmeier · Arnold Rudorfer
kommt, dass heute große Softwaresysteme oft in Siemens Corporate Research Inc.,
Firmenverbünden entwickelt werden, sodass über Princeton
E-Mail: Juergen.Kazmeier@siemens.com,
die Firmengrenzen hinweg gerade die Anforde- Arnold.Rudorfer@siemens.com
rungen zentrales Bindeglied sind, sowohl bei der Klaus Beetz
Auftragsvergabe als auch bei der Zergliederung Siemens Corporate Research & Technology,
München
von Systemen in Untersysteme. Dies umfasst eine E-Mail: Klaus.Beetz@siemens.com

2. { REQUIREMENTS-ENGINEERING
Bedeutung zu. Nur, wenn alle sicherheitsrelevanten
Zusammenfassung Anforderungen sauber erfasst werden, kann sicher-
Requirements-Engineering zielt auf die sys- gestellt werden, dass von diesem System keine Ge-
tematische Erhebung der Anforderungen für fährdung ausgeht, alle Risiken bedacht sind und über
ein zu entwickelndes Produkt oder System die Anforderungen entsprechend adressiert werden.
auf Basis genereller Geschäftsziele und Vor- Zahllose Probleme mit Systemen mit hohen
gaben ab. Angestrebt werden dokumentierte Softwareanteilen haben aus Sicht der Benutzer
Anforderungen an Produkte oder Systeme, die oft nicht mit der Frage zu tun, ob Anforderungen
optimal nutzbar und vermarktbar sind und in korrekt umgesetzt werden, was durch Verifikation
jeder Hinsicht möglichst gut den Erwartungen nachgewiesen wird, sondern betreffen eher den
aller Beteiligten entsprechen. Bedingt durch Punkt, dass die Anforderungen nicht im Sinne der
den hohen Innovationsgrad bei Software oder Nutzer angemessen festgelegt sind. Die berühmte
Produkten mit hohem Softwareanteil und den Frage ,,Is it a bug or a feature?“ hat nur zu oft ihre
steigenden Ansprüchen in Hinblick auf Funktio- Ursache in der ungenügenden Festlegung der An-
nalität kommt dem Requirements-Engineering forderungen. Wenn Systeme unerwartet und damit
eine Schlüsselstellung im Software und Systems aus Sicht der Nutzer fehlerhaft reagieren, handelt es
Engineering zu. Vor diesem Hintergrund hat die sich eben nicht immer um Implementierungsfehler,
Technische Universität München und Siemens bei denen die Spezifikation nicht korrekt umgesetzt
Corporate Research in Princeton, USA, ein ist, sondern allzu häufig auch um eine Diskrepanz
Requirements-Engineering–Referenzmodell zwischen dem, was der Nutzer erwartet und dem,
(REM) entwickelt, das Struktur und Inhalte der was die Spezifikation festgelegt hat.
Ergebnisse (,,Artefakte“) des Requirements- Untersuchungen zeigen, dass der Stand und
Engineering vorgibt. Es ist durch ,,Tailoring“ die Beherrschung des Requirements-Engineering
auf unterschiedliche Anwendungsdomänen und in der Praxis unbefriedigend sind. Vor diesem Hin-
Dokumentenvorgaben zuschneidbar. Es unter- tergrund sind die Technische Universität München,
stützt iterative Prozesse und eine modellbasierte vertreten durch den Lehrstuhl für Software und
Entwicklung. Systems Engineering, und die Siemens AG, vertreten
Der Ansatz REM wurde bereits erfolgreich durch Siemens Corporate Research Princeton, seit
zur Analyse und Bewertung durchgeführter Ent- einigen Jahren eine langfristige strategische Zusam-
wicklungsprozesse eingesetzt. Hierzu wurden menarbeit zum Thema Requirements-Engineering
die im untersuchten Projekt erstellten Spezi- eingegangen. Das Ziel des akademischen Partners
fikationsdokumente (beispielsweise Vision- & liegt auf der Hand: Fundiertere Methoden und grö-
Scope-Dokument, Lasten- und Pflichtenhefte, ßere Systematik zum Requirements-Engineering,
Architekturdokumente, usw.) hinsichtlich der wie dies in den letzten Jahren in wissenschaftlichen
im Artefaktmodell festgelegten Inhalte und Arbeiten entwickelt wurde, stärker in die Praxis
Beziehungen analysiert und bewertet. Gemein- zu bringen. Das Ziel des industriellen Partners ist
sam mit der entsprechenden Untersuchung andererseits auch klar: Auf Basis einer Vielzahl
des eingesetzten Requirements-Management- von Erfahrungen auf diesem Gebiet und vor dem
Werkzeugkonzepts können hieraus Aussagen Hintergrund von Best-Practice-Ansätzen mithilfe
zur Vollständigkeit und Qualität der betrach- von wissenschaftlichen Beiträgen das Thema zu
teten Spezifikationsdokumente und ihres konsolidieren und in eine langfristige Zusammen-
Erarbeitungsprozesses gefolgert werden. arbeit einzutreten, um industrielle Projekte besser
unterstützen zu können.
ten Teilaspekte eines Systems erstrecken. Die Fest- Requirements-Engineering und seine
legung der Anforderungen bestimmt entscheidend wirtschaftliche Bedeutung
sowohl die Qualität als auch die Kosten eines Systems Waren die Anfänge des Einsatzes von Software
und damit auch dessen wirtschaftlichen Erfolg. in Prozessen und Produkten eher von der Auto-
In sicherheitskritischen Anwendungen kommt matisierung bekannter Funktionen geprägt, so
der Anforderungsanalyse noch eine zusätzliche bestimmen die Entwicklung und den Einsatz von

3. und welchen Beitrag es zur Bewältigung der
Abstract damit verbundenen Herausforderungen liefern
Engineering supports a systematic collection kann.
of product or system requirements regarding
business goals and constraints. The goal is to Beherrschung der wachsenden Komplexität
assure that the developed system optimally Produkte, in denen immer häufiger verteilte Sys-
meets the user and market needs. That means teme mit vielfältigen Einsatzfunktionen eingebettet
that all stakeholder expectations have been sind, werden zunehmend umfangreicher, an-
taken in consideration. With regards to the high spruchsvoller und komplexer. Sie offerieren Ihren
pace of innovation in software and software in- Nutzern reichhaltige Interaktionen mit Zugriff auf
tensive systems and also the rapidly increasing hoch innovative Funktionen (oder Features1 ). Aber
functional complexity Requirements Enginee- oft kommt es zur sogenannten ,,Software Pollution“
ring excellence is now a critical success factor und zum ,,Over Engineering“, siehe Abb. 1. Das
in product and system development. In this heißt, das Produkt umfasst weit mehr Funktionen
context the Technical University Munich and als der Nutzer und damit der Markt wirklich benö-
Siemens Corporate Research are cooperating tigt. Häufig sind auch mehr Features implementiert
in developing a Engineering Reference Model als tatsächlich ausgeliefert werden: Zum einen, um
(REM) that defines the structure and content of für eventuelle zukünftige Benutzeranforderungen
the results (“artifacts”) of Requirements Engi- gerüstet zu sein und zum anderen, weil die aktu-
neering activities. It includes a tailoring concept ellen Anforderungen zu vage formuliert sind und
that allows its adaptation to different application deshalb mit weiteren Funktionen experimentiert
domains and documentation constraints. REM wird.
supports iterative processes and model based Dies zeigt, dass ein Großteil der zunehmenden
development. Komplexität hausgemacht und damit vermeid-
bar ist. Allerdings ist hierzu ein professionelles
Requirements-Engineering nötig, insbesondere
Software immer stärker auch innovative Funktionen. ein wohl definierter Erhebungsprozess und eine
Diese erfordern zwangsläufig einen Lernprozess Methodik zur Bestimmung des ,,Geschäftswertes“
in Hinblick auf die wesentlichen funktionalen einer Funktion oder Anforderung. Eine Methodik,
und nichtfunktionalen Anforderungen. Damit die die Priorisierung der Anforderungen bezüglich
kommt dem Requirements-Engineering eine immer ihres Geschäftsnutzens unterstützt, garantiert nur
tragendere Rolle zu. die Implementierung der wesentlichen Anforde-
rungen. Um sicherzustellen, dass auch wirklich
Trends in der Industrie nur diese Features implementiert werden, müssen
Drei große Trends und die damit verbundenen diese Anforderungen über den Entwicklungsprozess
Herausorderungen bestimmen heute unter anderem verfolgt und entsprechende Testfälle erstellt werden,
die industrielle Fertigung von Produkten ebenso wie um die Minimalität der Entwicklung sicherstellen zu
die Entwicklung komplexer Systeme wie Verkehrs- können.
leitsysteme, Computertomografien, Autoelektronik,
Automatisierungssysteme oder Systeme für den Neue Funktionalitäten –
Energiebereich. Software als Innovationstreiber mit
Diese aktuellen Trends sind: immer kürzeren Innovationszyklen
In den vergangenen Jahren ist der Anteil von
· stark wachsende Komplexität der Produkte, Software in Produkten, Dienstleistungen und Sys-
· Software als Innovationstreiber, folglich immer kürzere temlösungen kontinuierlich gewachsen. Bei Siemens
Innovationszyklen und beträgt der Softwareanteil in der Produkt- und
· voranschreitende Globalisierung mit verteilter Entwicklung. Lösungsentwicklung heute schon (schätzungsweise)
mehr als 60%.
Im Folgenden zeigen wir kurz die Rolle des
Requirements-Engineering für diese Trends 1 Ein Feature ist eine Gruppe von Produktfunktionen.

4. { REQUIREMENTS-ENGINEERING
Abb. 1 Software Pollution [10]
Produktinnovationen werden zu einem stark in allgemeine und Zielgruppen oder marktspe-
wachsenden Teil in Softwarekomponenten rea- zifische Anforderungen erforderlich, sowie ein
lisiert. 50% der Produkte, Dienstleistungen und entsprechender Prozess, der alle Beteiligten von
Systemlösungen bei Siemens sind jünger als fünf der Unternehmensführung, über Vertrieb, Marke-
Jahre. In Hochtechnologiebranchen wie etwa der der ting, Produktmanagement bis zur Entwicklung mit
Medizintechnik sind 90% der Produkte sogar jünger einschließt.
als drei Jahre. Eine weitere Dimension der Globalisierung
Bei diesen extrem kurzen Innovationszyklen ist ist die zunehmende verteilte Entwicklung das Off-
ein effizientes und systematisches Requirements- shoring in Niedriglohnländer. Beides erhöht die
Engineering mit einem wohl definierten Übergang Anforderungen an das Requirements-Engineering
von innovativen Produktideen in den Realisie- enorm, da all die informellen Kommunikationswege
rungsprozess unabdingbar. Falls Missverständnisse wegfallen und zusätzlich kulturelle Differenzen die
und Unklarheiten der Produktanforderungen in Kommunikation erschweren.
den frühen Phasen nicht beseitigt werden können,
führen diese zu einem stark erhöhtem Aufwand in Requirements-Engineering in der Praxis
der Produktrealisierung und im schlimmsten Fall Unter Requirements-Engineering verstehen wir das
zum Scheitern des Produkts, wenn es am Markt Erfassen, Analysieren, Entwickeln, Strukturieren
vorbeientwickelt wird. und Dokumentieren von Anforderungen und Lö-
sungskonzepten. Wesentliche Aufgaben sind hierbei
Voranschreitende Globalisierung das Validieren und Abstimmen verschiedener,
Die Industrie entwickelt heute nicht mehr nur für möglicherweise widersprüchlicher Aspekte der
lokale Märkte sondern für den Weltmarkt. Doch der Produktentwicklung und die entsprechende Priori-
Weltmarkt besteht aus vielen lokalen Märkten, die sierung und Entscheidung über Anforderungen und
ihre spezifischen Anforderungen haben. zu realisierende Produktfunktionen.
Um auf diesem Weltmarkt bestehen zu können, Requirements-Engineering umfasst:
müssen die Produkte und Lösungen adaptierbar
und auf die Anforderungen der lokalen Märkte ab- · die Identifikation aller Lebenszyklus-Aktivitäten mit dem
gestimmt sein. Für die technologische Realisierung Ziel, Geschäfts- und Anwenderanforderungen zu gewinnen,
leicht adaptierbarer Produkte müssen jedoch die · die Identifikation von Anforderungen und Randbe-
Anforderungen systematisch analysiert, die Gemein- dingungen abgeleitet aus der Zielumgebung und
samkeiten herausgearbeitet und von den variablen Realisierungstechnologien,
Anforderungen separiert werden. Gleiches gilt für · die Analyse von Anforderungen und Ableitung detaillierter
unterschiedliche Nutzergruppen und Zielmärkte. zusätzlicher Anforderungen,
Hierfür ist eine systematische Methodik zur · die Dokumentation und Management von Anforderungen
Erfassung und Unterscheidung der Anforderungen und Spezifikationen,

5. · die Validierung und Verifikation der dokumentierten mentierbar und nicht skalierbar strukturiert. Verfügbare
Anforderungen gegen die Nutzerbedürfnisse, Werkzeuge sind sehr ineffektiv, bieten nur sehr generi-
· ein intuitives und eindeutiges Medium zur Kommunikation sche Konzepte, sind zu implementierungsnah, fordern
der Produkt- und Funktionalitätsideen zwischen Anwendern hohen Administrationsaufwand und bieten schlechte
und Entwicklern, Visualisierungskonzepte an.
· die Entwicklung innovativer Produktkonzepte, welche oft · Zwischen Produktmanagement, Forschung & Ent-
durch Software ermöglicht werden und wicklung, Marketing und Vertrieb gibt es keine klar
· die Verwaltung und Instandhaltung der Produktanforde- abgestimmten Vorgehensweisen und kein einheitliches
rungen von der Auslieferung bis zur Abkündigung. Kommunikationsmedium.
· Häufige und späte Änderungen der Anforderungen sind
Bedeutung von Requirements-Engineering nicht vermeidbar und werden insbesondere bei Prozessen
im Entwicklungs-Life-Cycle mit sequenziellen Vorgehensweisen nicht ausreichend
Industriestudien zum Thema Requirements-Engin- beherrscht. Änderungsraten von 2–3% pro Monat [13] sind
eering (RE) zeigen auf, wie stark der Einfluss von nicht untypisch.
RE auf den Projekterfolg ist. So weist der Standish
Report [9, 30] nach, dass mehr als 50% der ,,Schlüs- Industrielle Programme
selfaktoren“ für einen Projekterfolg im Require- Um den genannten Herausforderungen in der Sys-
ments-Engineering zu finden sind. Wingrove, Wie- tementwicklung zu begegnen und die identifizierten
gers und Gottesdiener schätzen, dass 40% bis 60% Schwachstellen im Requirements-Engineering zu
aller Produktdefekte im Requirements-Engineering beheben, wurden in betroffenen Unternehmen sys-
ihren Ursprung haben [14, 33, 34]. tematische Verbesserungsmaßnahmen initiiert. Die
Schon länger unbestritten ist, dass eine frühe Siemens AG hat wie auch Alcatel [13] und Intel [25]
Fehlerfindung durch eine stärkere Fokussierung auf ein Programm zur Verbesserung des Requirements-
die frühen Entwicklungsphasen insgesamt zu einer Engineering für Projekte aufgesetzt. Innerhalb
Kostenreduktion führt. Barry Boehm hat bereits von Siemens ist Siemens Corporate Research für
darauf hingewiesen, dass Fehlerkorrekturen in die Ausgestaltung des Requirements-Engineering-
den frühen Phasen 50 bis 200 mal billiger sind als Programms verantwortlich. Es ist organisatorisch
wenn das Produkt im Feld ist [4]. Steve McConnell mit dem unternehmensweiten top+ Programm
ermittelte Faktoren zwischen 10 und 100 in seinen assoziiert. Das Ziel ist Exzellenz im Requirements-
Arbeiten [23]. Engineering und soll durch folgende Maßnahmen
Capers Jones untersuchte die Zeitaufwände für erreicht werden:
das überarbeiten der Requirements-Engineering-
Defekte mit einem Ergebnis von 40% bis 50% des · Zur Verfügung stellen und Entwickeln von ,,state-of-the-art“-
gesamten Projektaufwandes [19, 20]. Requirements-Prozessen, Methoden, Tools und Metriken –
insbesondere für spezifische Geschäftsdomänen.
Schwächen heutiger · Einbettung von Requirements-Engineering in die Siemens-
Requirements-Engineering-Praxis Geschäftsprozesse (Produktmanagement, Marketing,
Capers Jones stellte in seiner Untersuchung fest, dass Innovation Management etc.).
die Requirements-Engineering-Disziplin in mehr als · Aufbau von Trainings- und Zertifizierungsangeboten für die
75% aller Unternehmen nur sehr mangelhaft durch- Mitarbeiter.
geführt wird [19, 20]. Seine Ergebnisse machen
deutlich, dass ein großes Verbesserungspotenzial Das Programm ist auf sechs Säulen aufgebaut
vorhanden ist. Aufbauend auf seine Kategorisie- (s. Abb. 2), um obige Zielsetzung auch umfassend
rung sehen wir folgende Herausforderungen als und nachhaltig umzusetzen.
besonders kritisch: Das Programm ist in die Siemens-Software-
Initiative integriert und es wurden bereits drei
· Es gibt keine eindeutige Definition, was eine ,,Best Practice“ erfolgreiche internationale Konferenzen mit Gast-
ist, letztendlich fehlen akzeptierte Referenzmodelle. rednern aus Industrie und Forschung durchgeführt.
· Die Anforderungen sind mangelhaft dokumentiert, zu Speziell für Projekteiter und Manager wurde eine
lösungsorientiert, unvollständig, inkonsistent, nicht imple- Checkliste entwickelt, die zehn kritische Erfolgs-

6. { REQUIREMENTS-ENGINEERING
faktoren für eine erfolgreiche Produktdefinition
festlegt. Sie erhebt keinen Anspruch auf Vollständig-
keit, aber wenn mehrere dieser Faktoren in einem
Projekt nicht beachtet werden, sind Probleme zu
erwarten (s. Abb. 3).
Requirements-Engineering
an der TU München (TUM)
Das Thema Spezifikation hat in Forschungsarbei-
ten der Informatik sehr früh Eingang gefunden.
Bereits in den 60er und 70er Jahren gab es eine
Fülle von Arbeiten, die gerade dem Thema der
formalen Spezifikation von Datenstrukturen und
Programmen gewidmet waren. Dazu gehören
grundlegende Arbeiten zum Thema Semantik
Abb. 2 Säulen des Siemens-Corporate-Research-Requirements- von Programmiersprachen, aber auch methodi-
Engineering-Programms [1] sche Arbeiten zur Spezifikation von Programmen
Abb. 3 Zehn kritische Erfolgsfaktoren der erfolgreichen Produktdefinition und Anforderungsanalyse [3]

7. durch Annotationen und letztlich auch Arbeiten späteren Entwurfsphasen integriertes, bewertbares,
in Verbindung mit den Ansätzen der Programm- quantifizierbares und in Teilen automatisierbares
verifikation. Diese Ansätze im Umfeld sogenannter Requirements-Engineering ist das konsequente Ein-
formaler Methoden waren aber deutlich getrennt führen von Modellen in das Requirements-Engin-
von stärker pragmatischen Überlegungen, die auch eering. Dabei handelt es sich einmal um Modelle,
mit praktischen Fragestellungen in Verbindung zu die geeignet sind, funktionale Anforderungen zu
sehen sind, wie Methoden der strukturierten Ana- beschreiben, zum anderen um Modelle, die stärker
lyse, die bereits auch diagrammatische Techniken auf Architekturen ausgerichtet sind und in einem
einsetzten, um Anforderungsanalyse zu betreiben. Zusammenhang zu nichtfunktionalen Anforderun-
In einem umfassenden Sinn wurde das Thema gen zu sehen sind, aber auch um weiterführende
Requirements-Engineering jedoch auf akademi- Modellbildungen im Zusammenhang mit Qualitäts-
scher Seite in diesen frühen Zeiten nicht behandelt. modellen und nichtfunktionalen Anforderungen.
Im Laufe der Jahre entstanden, parallel zu den Ar- Hier finden sich viele faszinierende Forschungs-
beiten der formalen Methoden, schließlich stärker fragen, die in vielerlei Hinsicht noch nicht genügend
pragmatische Ansätze zur systematischen Analyse bearbeitet sind.
und Erarbeitung von Anforderungen. Die wissen-
schaftlichen Gruppierungen zum Thema formaler Ausgangspunkt
Methoden und die Forschergruppen, die sich stärker Der Lehrstuhl für Software und Systems Engineer-
mit Requirements-Engineering als pragmatische ing der Technischen Universität München (TUM)
Aufgabenstellung beschäftigten, blieben aber im arbeitet seit langem auf dem Gebiet der formalen
Laufe der Jahre weitgehend disjunkt. Modellierung und Systemspezifikation. Ziel ist
Es zeigt sich, dass für fortgeschrittenes Require- es präzise und adäquate/brauchbare System-
ments-Engineering eine Synthese aus diesen eher beschreibungsmodelle zu entwickeln, die mit
formalen Ansätzen und den pragmatischen Vorge- entsprechenden Techniken die qualitativ höher-
hensweisen, die eine breitere Sicht auf das Require- wertige Systemdefinition unterstützen. Dies umfasst
ments-Engineering haben, erforderlich ist. Hinzu modellbasierte Methoden der Systemspezifikation,
kommen die Ideen der modellbasierten Entwick- Verifikation, Codegenerierung, Qualitätssiche-
lung, die eine konsequente Fortsetzung der Ansätze rung und Testspezifikation. Abbildung 4 zeigt
formaler Methoden sind und heute in der Praxis die Systembeschreibungsmodelle des Werkzeuges
stärker pragmatisch eingesetzt werden. Ein Ziel für AutoFocus [2, 5, 36]. Es ist ein modellbasiertes Ent-
ein stärker werkzeugunterstütztes, besser in die wicklungswerkzeug für den Entwurf eingebetteter
Abb. 4 Grafische Systembeschreibungstechniken in AutoFocus

8. { REQUIREMENTS-ENGINEERING
Systeme. Es verbindet Konzepte der Design- beitung von modellbasierten Methoden schrittweise
Modellierung, der Simulation sowie der Code- und REM hinzuzufügen.
Testfallgenerierung, und erlaubt die Verifikation
von Software-Komponenten. Die mathematisch Requirements-Engineering-
fundierten2 Systemsichten mit ihren grafischen Referenzmodell (REM)
Beschreibungstechniken sind (s. Abb. 4): Ausgangspunkte für die Entwicklung von REM
waren die Forschungsaktivitäten der TUM sowie
· hierarchische Strukturdiagramme (SSDs), Erfahrungen und Projekte der Siemens Corporate
· Zustandsautomaten (STDs), Research (SCR) in Princeton, USA und Siemens
· erweiterte Sequenzdiagramme (EETs) und Corporate Research & Technology (CT) in Mün-
· Datentypdefinitionen (DTDs). chen. Die zentralen Forschungseinheiten haben die
Aufgabe, die Siemens-Geschäftsbereiche durch Best-
Nachdem der Schwerpunkt bisher auf der Practice-Sharing und Innovation in diesem Bereich
präzisen und angemessenen Spezifikation des er- zu unterstützen.
forderlichen Systemverhaltens lag, geht man jetzt
dazu über modellbasierte Methoden auch in der Zielsetzung
Kernphase des Requirements-Engineering anzu- Zielsetzung von REM ist die Unterstützung und
wenden, bis hin zu ihrem systematischen Einsatz zur Prozessdefinition des Requirements-Engineering
schrittweisen Konstruktion, Analyse und zielorien- (RE) auf der Basis eines grundlegenden Modells
tierten Konsolidierung von Anforderungsmodellen. zu erarbeitender Spezifikationsartefakte und ihrer
Entsprechende Grundkonzepte des modellbasierten Beziehungen. Hierzu definiert REM
Requirements-Engineering, der artefakt-zentrierten
Prozessdefinition, der Qualitätssicherung und der
· eine Kernmenge von RE Artefakten und ihren Abhängig-
keiten – das RE-Artefaktmodell – und
messbaren Entscheidungsunterstützung sind in [15]
zusammengefasst.
· ein artefakt-zentriertes Tailoring-Konzept.
Der Ansatz des Requirements-Engineering-Re- In Analogie zum V-Modell XT unterstützt dies eine
ferenzmodell (REM) [16], wie er im nachfolgenden artefakt-basierte Prozessdefinition und definiert
Abschnitt ausführlich dargestellt wird, ist ein erster Meilensteine in der Systementwicklung auf der
Schritt in Richtung auf eine Synthese zwischen Basis von zu erarbeitenden RE-Artefakten. Für die
formalen Techniken, insbesondere Modellierungs- Anwendung und Instanziierung des Ansatzes in
techniken und einem breit angelegten methodischen konkreten Projekten und Domänen ist ein Tailoring-
Ansatz zum Requirements-Engineering. Konzept definiert.
Gemeinsam mit den Erfahrungen der Siemens-
Forschung zum Requirements-Engineering und REM im Produktlebenszyklus
weiteren Vorarbeiten der TUM zu Qualitätsmodel- REM geht von folgenden Aufgaben des Require-
len [6, 11] und der artefakt-orientierten Prozess- ments-Engineering im Lebenszyklus eines Pro-
definition im V-Modell XT [35] sind diese Ansätze duktes aus. Hierzu gibt Abb. 5 einen allgemeinen
in REM umgesetzt und im Kontext komplexer Überblick über Entstehung, Einsatz und Wartung
industrieller Anforderungen präzisiert worden. eines Produktes und seiner schrittweisen Weiterent-
REM schafft hierbei zunächst ein Referenzmo- wicklung auf Basis von Kundenerfahrungen, neuen
dell, das die wesentlichen Artefakte, die als Ergebnis Marktstrategien und Technologien.
eines strukturiert angelegten Requirements-Engin- Die Aufgaben des Requirements-Engineering
eering zu erarbeiten sind, festlegen und zueinander sind hierbei:
in Beziehung setzt. Für REM existieren erste Ausprä-
gungen zum Einsatz formaler Methoden, zumindest · Marketinginformationen und Nutzeranforderungen zu
für die konstruktive Erarbeitung und qualitative analysieren, die funktionalen und nichtfunktionalen Anfor-
Überprüfung bestimmter Artefakte. In weiteren derungen abzuleiten und den entsprechenden funktionalen
Schritten ist geplant, hier eine umfassendere Ausar- Entwurf des Systems zu steuern.
· Die Auswirkungen dieser Anforderungen auf das Geschäft
2 Der strombasierte Ansatz von FOCUS [7] zur Systemmodellierung. und den Erfolg des Produktes im Markt zu verstehen.

9. Abb. 5 Der Produktentstehungsprozess im Überblick
· Diese Anforderungen abzustimmen, zu konsolidieren und der zu erarbeitenden Spezifikationsdokumente der
in einer Anforderungs- und Systemspezifikation konsistent fachübergreifenden Abstimmungsaktivitäten der
und vollständig zu spezifizieren. Produktentwicklung.
Das Modell ist nach folgenden Paradigmen
Somit hat das Requirements-Engineering eine der integrierten Anforderungsanalyse und System-
zentrale Rolle in der Produktdefinition und Ent- definition gestaltet:
wicklung. Die erarbeiteten Spezifikationsartefakte
sind die Basis für Produktdesignentscheidung · ziel- und nutzerorientierte Analyse und Verfeinerung von
und Projektmanagement während des gesamten Anforderungen und funktionalen Entwurfskonzepten,
Produktlebenszyklus. Die Qualität und Angemes- · Analyse und Verfeinerung von ,,high-level“ funktionalen
senheit der Artefakte ist ein Schlüsselfaktor für die und nichtfunktionalen Anforderungen mithilfe eines grund-
erfolgreiche Systementwicklung. legenden Beschreibungskonzeptes für Systeme und ihres
Verhaltens aufbauend auf der Modellierung funktionaler
Das Artefaktmodell Systemsichten und
REM strukturiert und gibt Vorgaben für die · qualitative Überarbeitung erarbeiteter Spezifikationen auf
Anforderungsanalyse- und Systementwurfsak- Basis definierter Beziehungen zwischen verschiedenen
tivitäten mittels eines grundlegenden Modells von Klassen von Anforderungen und Systemmodellen (RE-
Requirements–Engineering-Spezifikationspro- Artefakten) des Artefaktmodells. Diese Abhängigkeiten
dukten – dem RE-Artefaktmodell. Abbildung 6 zwischen Artefakten bilden messbare Konsistenzbe-
zeigt einen Überblick über das Modell und seine dingungen und können für die Verifikation und
Struktur. Es unterteilt die zu erarbeitenden An- Validierung erstellter Systemanforderungen genutzt
forderungen (RE-Artefakte) in die Gruppen werden.
Business-Needs, Requirements-Specification und
System-Specification. Die Artefakte mit ihren defi- Entsprechend dieser methodischen Konzepte ist die
nierten Inhalten bestimmen die Struktur und Inhalte Beschreibung der einzelnen RE-Artefakte aufgebaut

10. { REQUIREMENTS-ENGINEERING
Abb. 6 Überblick über das REM-Requirements-Engineering-Artefaktmodell
und gibt Vorschläge einzusetzender Methoden und · General Conditions und Scope & Limitations spezifizieren
Beschreibungstechniken zur Konstruktion, Kommu- ,,high-level“-nichtfunktionale Anforderungen und Beschrän-
nikation und Konsolidierung ihrer erforderlichen kungen und grenzen den relevanten Ausschnitt der Anwen-
Inhalte (Content-Items). Die weitere Unterteilung dungsdomäne und gegebenenfalls der Produktlinie ab.
der Artefakte in Content-Items wird in Abb. 7 am Bei- · Return of Investment (ROI) und Business-Risk fassen die
spiel der Requirements-Specification-Artefaktgruppe Ergebnisse mehrfacher Kosten-Nutzen-Analysen, erwartete
demonstriert. Verkaufserlöse, Entwicklungs- und Markteinführungskosten
zusammen und stellen die entsprechende Risikoanalyse von
Artefaktgruppen Anforderungen in den Mittelpunkt.
· System-Success-Factors spezifizieren und priorisieren die
Business-Needs-Artefakte Kriterien für den finalen Produkterfolg.
Die Business-Needs-Artefakte spezifizieren kunden-
und produktstrategische Anforderungen, ins- Diese Produktziele und Abgrenzung sind das Er-
besondere die Geschäfts- und Produktziele der gebnis sorgfältiger Marketing-, Portfolio- und
Systementwicklung. Zu der Gruppe gehören Kundenabstimmung. Gemeinsam mit wiederhol-
folgende Artefakte: ten Return-of-Investment- und Risikoanalysen
legen sie die Basis für die nachfolgende Ent-
· Business-Objectives und Customer-Requirements spe- wicklungsarbeit und bilden die Grundlage für
zifizieren Kundenanforderungen und beschreiben die Produktdesign-Entscheidungen.
Marktpositionierung des zukünftigen Produktes.
· System-Vision listet die geforderten funktionalen Requirements–Specification-Artefakte
Anforderungen/Features auf und legt die Planungsan- Die Requirements-Specification-Artefakte bein-
nahmen und Projektabhängigkeiten der Produkt- oder halten die funktionalen und nichtfunktionalen
Produktlinienentwicklung fest. Anforderungen an das zu entwickelnde System.

11. Abb. 7 Überblick über die Requirements-Specification-Artefakte
Mithilfe dieser Artefakte werden die Ziele und Vor- Annahmen (Assumptions & Dependencies) und Constraints
gaben der Business-Needs-Artefakte aus Kunden- (Design-Constraints) und bilden diese auf die detaillierten
und Nutzersicht analysiert, strukturiert und detail- Anforderungen der System-Specification ab.
lierte Anforderungen und Qualitätsvorgaben an das · Acceptance-Criteria spezifizieren die Abnahme- und
Nutzungserhalten des Systems abgeleitet. Zu ihnen Testkriterien des auszuliefernden Systems.
gehören diese Artefakte:
Die wesentliche Rolle der Analysemodelle der Re-
· Functional-Analysis-Models enthalten Analyse- und quirements-Specification-Artefakte ist die Verfei-
Beschreibungsmodelle der Geschäfts- und Anwendungs- nerung und Strukturierung der ,,high-level“-fest-
prozesse. Sie dienen der Kommunikation der Kunden- gelegten Business-Needs sowie ihrer Abbildung auf
und Nutzeranforderungen, der Bestimmung erforderlicher die detaillierten Systemanforderungen des entspre-
Systemdienste/Features und Qualitätseigenschaften und chenden Systementwurfskonzeptes. Sie bilden die
sie bilden die Basis für die Evaluierung und Bewertung Entscheidungsbasis für die Priorisierung von Anfor-
erarbeiteter System-Specifications. derungen und ermöglichen begründete und nach-
· Domain-Models sind eine strukturierte Spezifikation der vollziehbare Produktdesignentscheidungen. Zuge-
Anwendungsdomäne und ihrer Charakteristika und wer- schnitten auf domän- und projektspezifische Erfor-
den ergänzt durch eine Modellierung der operationellen dernisse können hier passende Methoden und Be-
Umgebung des zukünftigen Systems. schreibungstechniken für die Erarbeitung und Ab-
· Nichtfunktionale Anforderungsmodelle verfeinern und struk- stimmung der RE-Artefakte eingesetzt werden. Ak-
turieren Qualitätsanforderungen (Quality Requirements), tuelle Ansätze der Prozess- und Szenarioanalyse hier-

12. { REQUIREMENTS-ENGINEERING
zu sind Strukturierungsmethoden von [27, 28], der Phasen in der Produktdefinition – weniger auf den
Fraunhofer-QUASAR-Ansatz [29], AutoRAID [15, 17], konkreten Aufbau der Dokumente. Spezifikations-
die aufgabenorientierte Szenarioanalyse von [8, 31] dokumente als Basis für Meilensteinentscheidungen
und Methoden der szenariobasierten Testfallab- setzen sich aus Inhalten quer über das Artefakt-
leitung [18]. Ansätze der Ziel- und Qualitätsmodel- modell zusammen. Die spezifisch erforderlichen
lierung sind KAOS [22], ATAM [21], TROPOS [32] Dokumentstrukturen eines Entwicklungsprojektes
sowie die ASPIRE-Methode für die Konstruktion werden durch das domänenspezifische Tailoring
erfahrungsbasierter Qualitätsmodelle [12]. Das des Artefaktmodells und der daraus folgenden
grundlegende Konzept von REM, Anforderungen Prozessdefinition bestimmt.
mithilfe funktionaler Systemsichten herauszuar-
beiten und zu strukturieren (AutoRAID/Auto- Prozessdefinition und Tailoring
Focus [2, 15, 17, 36]) findet sich auch in den Ansätzen Das RE-Artefaktmodell bildet den Ausgangspunkt
von [26, 27] wieder. für das domänenspezifische Tailoring und eine
artefakt-zentrierte Prozessdefinition. REM definiert
System-Specification-Artefakte Meilensteine und Entscheidungspunkte im Produkt-
Die System–Specification-Artefakte adressieren den entstehungsprozess in Form von Vollständigkeits-
detaillierten Entwurf des funktionalen Systemkon- bzw. Qualitätsstufen auf den RE-Artefakten.
zeptes: Es spezifiziert das erforderliche Verhalten
des betrachteten Systems und seine Integration in Artefakt-basierte Prozessdefinition
das technische Gesamtsystem und die Anwendungs- Abbildung 8 zeigt dieses Konzept der artefakt-
umgebung. Zusätzlich werden die Bedingungen für zentrierten Prozessdefinition: Das Artefaktmodell
den detaillierten Entwurf und die Realisierung des definiert Inhalt und Struktur der gesamten
Systems innerhalb der Entwicklungsdisziplinen Spezifikationsdokumente. Ihre festegelegten Voll-
(Software, Elektrik/Elektronik und Mechanik) ständigkeitsstufen bilden die messbare Grundlage
festgelegt. Folgende Artefakte bestimmen die für Reviews und Entscheidungen in Produktdefini-
System-Specification Artefaktgruppe: tion und Realisierung. Für ihre einfache Darstellung
sind diese Vollständigkeitsstufen durch Prozent-
· User–Interface-Specification und User-Documentation be- zahlen der RE-Artefakte zusammengefasst. Sie
schreiben die Nutzungsschnittstelle und mögliche Abläufe repräsentieren den gewünschten Grad an Qualität
wie die Nutzer das System benutzen können. und Vollständigkeit zu dem erreichten Zeitpunkt des
· Functional-System-Concept: Detaillierte Systeman- betreffenden Entscheidungspunktes. Zugehörige
forderungen spezifizieren die erforderlichen Versionen der Spezifikationsdokumente bilden die
Systemdienste/Funktionen, mit entsprechenden Anfor- Decision-Base (Entscheidungsbasis) D(i) für Meilen-
derungen an Interaktion, Verhalten, Datenstrukturen, steine oder Quality Gates im Entwicklungsprozess,
das zugrunde liegende Datenmodell und die Nut- und sie sind Input für die artefakt-spezifische
zungsbedingungen des Systems. Gemeinsam mit der Planung (Plan) und Durchführung iterativer
External-Interface-Specification wird die Integration des Konstruktions- (Develop) und Abstimmungsaktivi-
Systems in das Gesamtsystem definiert. täten (Verify) der interdisziplinären Anforderungs-
· External-Interface-Specifications definieren die Schnittstellen und Systemdefinition.
des Systems zu kooperierenden Komponenten und Sys- REM geht von einer grundlegenden iterativen
temen der Umgebung und zu genutzten Software- und Erarbeitung der Systemspezifikation aus, in der An-
Hardware-Komponenten. forderungen und Lösungskonzepte in wechselnden
· Design-Constraints begrenzen den detaillierten Sys- Phasen der Entwicklung und Abstimmung (Develop
tementwurf und die Realisierung innerhalb der und Verify) systematisch mithilfe grundlegender
Engineering-Disziplinen. methoden-abhängiger Modellierungskonzepte
· System-Test-Criteria bilden Akzeptanz- und Testkriterien für analysiert (Analyze), verfeinert (Refine), struktu-
Systemintegration und Evaluierung. riert/modelliert (Structure & Model), vervollständigt
und konsolidiert (Complete) werden.
Diese drei Gruppen des RE-Artefaktmodells zielen Anzahl und inhaltliche Gestaltung solcher
auf die vorherrschenden Inhalte der wesentlichen vordefinierten Entscheidungspunkte sind abhängig

13. Abb. 8 Prozessdefinition mittels Vollständigkeitsstufen von Spezifikationsdokumenten
vom der jeweils gewählten Prozessstrategie, z.B. · Prozessstrategie – Entscheiden über die Prozessstrategie
einer agilen, komponenten-orientierten oder eher und Festlegen der Reihenfolge in der die RE-Artefakte zu
traditionellen Vorgehensweise. erarbeiten und zu vervollständigen sind und entsprechende
Definition der Entscheidungspunkte, Meilensteine oder
Tailoring Quality-Gates. REM empfiehlt ein iteratives und review-
Die artefakt-orientierte Prozessdefinition erfolgt basiertes Vorgehen.
nach folgenden Tailoringschritten: · Zuordnen von Teammitgliedern zu Rollen und von Rollen
zu Spezifikationsdokumenten und Inhalten (RE-Artefakte).
· Pruning des Artefaktmodells – Zuschneiden und Anpassen In Anlehnung an das Microsoft Teammodell [24] definiert
der zu erarbeitenden Anforderungsinhalte (RE-Artefakte) das Rollenkonzept in REM grundlegende Rollen-Cluster
und Spezifikationsdokumente. REM definiert mandatory, und ihre Zuständigkeit für Teile des Artefaktmodells. Für
recommended, optional RE-Artefakte und Inhaltspunkte jedes RE-Artefakt sind in REM Responsible- und Contributing-
(Content-Items). Rollen definiert.
· Auswählen, Zuordnen und Anpassen von Methoden und
Beschreibungstechniken für das Herausarbeiten und Abbildung 9 fasst das Tailoring-Konzept von REM
Spezifizieren der RE-Artefakte und Content-Items. zusammen: Aktivitäten (Activities), Meilensteine
Abb. 9 Überblick über artefakt-orientiertes
Prozess-Tailoring in REM

14. { REQUIREMENTS-ENGINEERING
Abb. 10 Meilensteindefinition in REM am Beispiel des Siemens Product-Life-Cycle-Process (PLM)
(Decision-Gates) und Rollen (Roles) sind nach die zielorientierte und effektive Entwicklung von
RE-Artefakten (RE-Artifacts) bzw. Spezifikations- Anforderungen und Systemkonzepten.
dokumenten (Documents) strukturiert. Durch das Abbildung 10 zeigt ein Beispiel des Tailoring
Tailoring erfolgt die domänen-/projektspezifische in REM anhand des Siemens Product-Life-
Anpassung des Artefaktmodells, die Festlegung Cycle-Process (PLM) und der entsprechenden
der Spezifikationsdokumente und die Definition Vollständigkeitsstufen der Spezifikationsdokumente
der Entscheidungspunkte mittels dokumentspezifi- an den PLM-Meilensteinen M100, M150, und M200.
scher Art und Vollständigkeitsstufen. Dies schließt
die Festlegung von Methoden und Tools für die Methoden und Werkzeugunterstützung
Konstruktion der Artefakte und Dokumente mit ein. für REM
Das Ergebnis der Prozessinstanziierung ist Der Ansatz REM liefert ein Referenzmodell für
ein Arbeitsplan mit Aktivitäten zur Erarbeitung die Struktur und Inhalte der Ergebnisse des
der Dokumente, RE-Artefakte und ihrer Inhalte. Requirements-Engineerings. REM ist in seiner
Entsprechend der definierten Vollständigkeitsstufen jetzigen Form weitgehend methoden-, werkzeug-
können die zugehörigen Dokumente iterativ in und prozessunspezifisch. In zukünftigen Schritten
Versionen entwickelt werden. werden Methoden in REM integriert. In [16] wer-
Durch die Bereitstellung von Templates, den explizit für alle Artefakte die heute üblichen
Checklisten, Methoden und Tools bietet das Methoden zur Beschreibung aufgezählt. Eine spe-
artefakt-basierte Tailoring in REM die Grund- zielle Betonung oder Bewertung objektorientierter
lage für Qualitäts- und Fortschrittsmessung im Methoden wird nicht durchgeführt. Generell sind
Requirements-Engineering und damit die Basis für Strukturierungs- und Modularisierungskonzepte

15. für alle Methoden insbesondere in Hinblick auf erreichen, ist es unabdingbar, Erfahrungen aus in-
eine zufrieden stellende Skalierbarkeit essenziell. dustriellen Softwareprojekten zusammenzuführen.
Daher sind entsprechende Methoden für industrielle Wesentlich zu klären ist die Frage, welche einzel-
Projekte vorzuziehen. nen Methoden für die Erarbeitung der Artefakte
Eine besondere Rolle kommt dem Prototyping sich anbieten und wie diese Methoden ineinander
im Requirements-Engineering zu. Prototyping kann greifen. Für den praktischen Einsatz von REM sind
insbesondere bei vagen Anforderungen und hoch Instanzen zu bilden, die auch die Wahl spezieller
innovativen Produktentwicklungen in den Entwick- Methoden für die Erarbeitung der Artefakte und ent-
lungsprozess systematisch integriert werden, um die sprechender Unterstützungswerkzeuge umfassen.
Stakeholder in die Anforderungsanalyse intensiver Diese Instanzen bilden dann umfassendere konkrete,
einzubinden. Prototyping kann zur Erarbeitung der praktisch einsetzbare Vorgehensmodelle für das
Artefakte in das Referenzmodell integriert werden, Requirements-Engineering. Die Bildung spezifischer
ist aber letztlich nur eine Methode zur Erfassung Instanzen ist aktuelles Thema laufender Forschungs-
und Konsolidierung von Anforderungen und daher arbeiten an der Technischen Universität München
nicht im Fokus dieser Arbeit. und bei Siemens Corporate Research Princeton.
Zur Werkzeugunterstützung von REM gibt es Verschiedene Formen der Anwendung bieten
einen ersten Prototyp, der parallel zur Entwicklung sich für REM an. REM kann als Methoden-
von REM entstanden ist. Es handelt sich dabei Framework, als Planungswerkzeug für anstehende
um das von der TUM entwickelte Requirements- Requirements-Engineering-Projekte, als Bewer-
Management und Systemspezifikationswerkzeug tungswerkzeug für laufende oder abgeschlossene
AutoRAID/AutoFocus [17, 36]. Das Werkzeug betont Requirements-Engineering-Projekte, als Bei-
den Ansatz des modellbasierten Requirements- spielsammlung (Best Practice) für (ausgewählte)
Engineering. Es ist prototypisch umgesetzt und Requirements-Engineering-Projekttypen etc. ein-
anhand von Fallstudien erfolgreich erprobt. gesetzt werden. Damit können dann auch bekannte
Schwächen im Requirements-Engineering von Soft-
Fazit und Ausblick wareprojekten (z. B. Dokumentation, Skalierbarkeit,
Es bleibt die Frage, was wir bisher mit REM er- Implementierbarkeit, Änderungsmanagement, und
reicht haben. Das entwickelte Referenzmodell Metriken zur Bewertung der Qualität der Anforde-
für Requirements-Engineering (REM) ist ein rungen und der Anforderungsprozesse) aufgedeckt
erster wichtiger Schritt um sich das Thema des und behoben oder sogar frühzeitig vermieden
Requirements-Engineering durch Systematisierung werden.
stärker zu erschließen. Es dient zum Abstecken
der Bestandteile eines umfassenden Requirements- Literatur
Engineering-Ansatzes und wird dazu beitragen, dass 1. Achatz, R., Berenbach, B., Broy, M., Kazmeier, J., Ros, J., Rudorfer, A., Subrama-
ein einheitlicheres und strukturiertes Verständnis nyan, R.: Requirements Engineering: A Key to Business Success for Siemens.
Siemens Corporate Research (SCR) Technical Report, March (2006)
für das Thema Requirements-Engineering erreicht 2. AutoFocus: AutoFocus – A CASE tool for Requirements, Design, Code Generation
wird – und zwar für Forschung und die industri- and Simulation: http://www4../∼af2 (2006)
3. Berenbach, B.: Requirements Engineering Checklist. Siemens Corporate Research
elle Praxis. Die flexible Prozessdefinition und das (SCR) SE, Internal Publication (2005)
Tailoring erlauben es zudem, einen Requirements- 4. Boehm, B., Pappaccio, C.: Understanding and Controlling Chaos. IEEE Transactions
of Software Engineering, October (1988)
Engineering Prozess projektspezifisch anzupassen. 5. Braun, P., Lötzbeyer, H., Schätz, B., Slotosch, O.: Consistent Integration of Formal
Damit werden sowohl das Vorgehen als auch die Methods. In: Proc. Intl. Conf. On Tools fort he Analysis of Correct Systems
(TACAS), LNCS 2280 (2006)
Kommunikation zwischen Projektbeteiligten (z.B. 6. Broy, M., Deissenboeck, F., Pizka, M.: Demystifying Maintainability. WoSQ ’06:
Produktmanagement, Forschung & Entwicklung, Proceedings of the 4th Workshop on Software Quality (2006)
Marketing und Verkauf) abgestimmt. 7. Broy, M., Stoelen, K.: Specification and Development of Interactive Systems.
Springer (2001)
Viele Fragen sind auch durch REM in seiner 8. Carroll, J.: Scenario-Based Design: Envisioning Work and Technology in System
aktuellen Form naturgemäß nicht beantwortet und Development. Wiley & Sons (1995)
9. Chaos Report 2001: http://www.projectsmart.co.uk/docs/chaos_report.pdf
viele Forschungsthemen sind noch nicht bearbeitet. 10. Cohen, D., Larson, G., Ware, B.: Improving Software Investment Through Require-
Um REM als Referenzmodell zu etablieren, ist es ments Validation. Sente Corporation (2002)
11. Deissenboeck, F., Seifert, T.: Kontinuierliche Qualitätsüberwachung mit ConQAT.
notwendig, das Modell für die Forschung und Praxis Jahrestagung der Gesellschaft für Informatik 2006, Workshop Software-Leitstände
weiter auszuarbeiten und zu verfeinern. Um dies zu (2006)

16. { REQUIREMENTS-ENGINEERING
12. Doerr, J., Kerkow, D., Koenig, T., Olsson, T., Suzuki, T.: Non-Functional Require- 23. McConnell, S.: Rapid Development: Taming Wild Software Schedules. Microsoft
ments in Industry – Three Case Studies Adopting the ASPIRE NFR Method. IESE- Press (1996)
Report No. 025.05/E (2005) 24. Microsoft Solution Framework (MSF) Team Model. White Paper. 2002. Homepage:
13. Ebert, C.: Requirements Before Requirements: Understanding the Upstream Im- http://www.microsoft.com/msf (2006)
pacts. In: Proceedings RE’05, Paris (2005) 25. Nesland, S.: Initial Lessons Learned from the Definition and Implementation of
14. Firesmith, D.: A Business Case for Requirements Engineering. Presentation at SEI, a Platform Requirements Engineering Process at Intel Corporation. In: Proceedings
September 2003: http://www.sei.cmu.edu/programs/acquisition-support/ RE’05, Paris (2005)
presentations/firesmith/business-case/case.pdf (2006) 26. Paech, B., Von Knethen, A., Doerr, J., Bayer, J., Kerkow, D., Kolb, R., Trendowicz,
15. Geisberger, E.: Requirements Engineering Eingebetteter Systeme – ein interdiszi- A., Punter, T., Dutoit, A.: An Experience-Based Approach for Integrating Architec-
plinärer Modellierungsansatz. Dissertation, Technische Universität München, 2005. ture and Requirements Engineering, ICSE’03 Workshop “From Software Require-
Shaker Verlag, ISBN: 3-8322-4619-3, www.shaker-online.com/ ments to Architectures” (2003)
16. Geisberger, E., Berenbach, B., Broy, B., Kazmeier, J., Paulish, D., Rudorfer, A.: Re- 27. Pohl, K., Brandenburg, M., Gülich, A.: Integrating Requirement and Achitecture
quirements Engineering Reference Model (REM). Technischer Bericht TUM-I0618, Information – A Scenario and Meta-Model Based Approach. In: Proc. of REFSQ
TU München, November (2006) 2001 Workshop. Interlaken, Schweiz (2001)
17. Geisberger, E., Schätz, B.: Modellbasierte Anforderungsanalyse mit AutoRAID. 28. Pohl, K., Haumer, P.: Modelling Contextual Information about Scenarios. In: Proc.
GI Informatik – Forschung und Entwicklung, Springer Verlag (2007) of the 3rd Intl. Workshop on Requirements Engineering – Foundation of Software
18. Halmans, G., Kamsties, E., Pohl, K., Reis, S., Reuys, A.: Seamless Transition from Quality (REFSQ ‘97). University Press Namur, Barcelona, Spain (1997)
Requirements to Test Cases: How to Test a Software Product Line? In: Proceed- 29. QUASAR-Projekt. Homepage: http://www.first.fraunhofer.de/quasar (2006)
ings of the Conference on Software Testing, ICSTEST-E (Bilbao, Spain, November 30. Standish Group Reports: http://www.standishgroup.com/sample_research/
2004). SQS, Düsseldorf (2004) PDFpages/q3-spotlight.pdf (2006), http://www.standishgroup.com/
19. Jones, C.: Applied Software Measurement – Assuring Productivity & Quality. New sample_research/Pdfpages/extreme_chaos.pdf (2006)
York, McGraw Hill (1996) 31. Sommerville, I.: Software Engineering. 7th Edition. Addison Wesley (2004)
20. Jones, C.: Estimating Software Requirements. In CROSSTALK – The Journal of De- 32. TROPOS-Projekt. Homepage: www.troposproject.org/ (2006)
fense Software Engineering, June 2002: http://www.stsc.hill.af.mil/crosstalk/ 33. Wiegers, K.: Software Requirements. 2nd Edition, Microsoft Press (2003)
2002/06/jones.pdf (2006) 34. Wiegers, K., Lawrence, B., Ebert, C.: The Top Risks of Requirements Engineering.
21. Kazman, R., Klein, M., Clements, P.: ATAM: Method for Archtecture Evaluation. IEEE Software, November/December (2001)
Technical Report, CMU/SEI-2000-TR-004 (2000) 35. V-Modell XT. http://www.v-modell-xt.de/ (2006)
22. Lamsweerde, A., Darimont, R., Letier, E.: Managing Conflicts in Goal-Driven Re- 36. Wild, D.: AutoFocus 2 – Das Bilderbuch. Technische Universität München, Techni-
quirements Engineering. IEEE Trans. Software Eng. 24(11), 908–926 (1998) cal Report: TUM-I0610, May (2006)