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

Ein Requirements Engineering Referenzmodell

  • View
    1.222

  • Download
    0

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Ein Requirements Engineering Referenzmodell

HAUPTBEITRAG / REQUIREMENTS-ENGINEERING }

Ein Requirements-Engineering-Referenzmodell

Manfred Broy · Eva GeisbergerJürgen Kazmeier · Arnold Rudorfer

Klaus Beetz

Requirements-Engineering ist

integraler Bestand-teil der Entwicklungvon Produkten, von

Systemen und natürlichauch von Software.

Sehr früh war geradeim Umfeld der Soft-wareerstellung denEntwicklern aus gutenGründen bewusst, dassAnforderungen undAnforderungsanalysen

entscheidend für die erfolgreiche Durchführungvon Softwareprojekten sind. Eine Vielzahl unter-schiedlicher Ansätze in Praxis und Wissenschaftzielen auf die Analysephase, allerdings häufig nurauf bestimmte Aspekte. Eine ganzheitliche Anfor-derungsanalyse für Softwaresysteme und allgemeinSysteme mit hohem Softwareanteil schließt vieleunterschiedliche Gesichtspunkte ein, angefan-gen von den generellen Geschäftszielen über diefunktionalen Anforderungen, die festlegen, wel-che Funktionen im Sinne der Nutzer ein Systemrealisiert, werden bis hin zu den vielfältigen nicht-funktionalen Anforderungen, die sich auf Fragender Qualität, der Kosten, der Entwicklungszeit, desEntwicklungsprozesses und vieles mehr richten.

EinleitungMit den wachsenden Umfängen und der steigen-den Komplexität von Software, mit der Zunahmeder Rolle von Software als Innovationstreiber fürSysteme und Produkte kommt dem Requirements-Engineering eine immer tragendere Rolle zu. Hinzukommt, dass heute große Softwaresysteme oft inFirmenverbünden entwickelt werden, sodass überdie Firmengrenzen hinweg gerade die Anforde-rungen zentrales Bindeglied sind, sowohl bei derAuftragsvergabe als auch bei der Zergliederungvon Systemen in Untersysteme. Dies umfasst eine

Folge von Aufgaben der Anforderungsdefinitionund Detaillierung, aber auch der Überprüfung derAnforderungen durch Validierung und Verifikation.

Untersuchungen zeigen, dass das Beherrschender Anforderungen und der Anforderungsanalyseeine der wichtigsten Erfolgsvoraussetzungen fürdie Durchführung von Projekten ist. Umso mehrerstaunt es, dass es bisher keine allgemeingültigenAnsätze zur Durchführung der Anforderungsanalysegibt. Auch die Dokumentation von Anforderungenund die Frage, was dabei alles zu berücksichtigen ist,ist bisher nicht wirklich in umfassenden Ansätzendargestellt. Das ist umso kritischer, als – geradefür die Praxis – eine stärkere Standardisierung derAnforderungsdokumente von hoher Bedeutungist, da es in der Zusammenarbeit zwischen unter-schiedlichen Firmen äußerst hilfreich wäre, aufeinheitliche Verfahren zur Definition und Festlegungder Anforderungen zurückzugreifen.

Natürlich betreffen gerade die Festlegungen derAnforderungen alle Aspekte eines Softwaresystems,da die Anforderungen sich auf die unterschiedlichs-

DOI 10.1007/s00287-007-0149-5© Springer-Verlag 2007

Manfred Broy · Eva GeisbergerTechnische Universität München,Boltzmannstr. 3,85748 GarchingE-Mail: [email protected], [email protected]

Jürgen Kazmeier · Arnold RudorferSiemens Corporate Research Inc.,PrincetonE-Mail: [email protected],[email protected]

Klaus BeetzSiemens Corporate Research & Technology,MünchenE-Mail: [email protected]

Page 2: Ein Requirements Engineering Referenzmodell

{ REQUIREMENTS-ENGINEERING

ZusammenfassungRequirements-Engineering zielt auf die sys-tematische Erhebung der Anforderungen fürein zu entwickelndes Produkt oder Systemauf Basis genereller Geschäftsziele und Vor-gaben ab. Angestrebt werden dokumentierteAnforderungen an Produkte oder Systeme, dieoptimal nutzbar und vermarktbar sind und injeder Hinsicht möglichst gut den Erwartungenaller Beteiligten entsprechen. Bedingt durchden hohen Innovationsgrad bei Software oderProdukten mit hohem Softwareanteil und densteigenden Ansprüchen in Hinblick auf Funktio-nalität kommt dem Requirements-Engineeringeine Schlüsselstellung im Software und SystemsEngineering zu. Vor diesem Hintergrund hat dieTechnische Universität München und SiemensCorporate Research in Princeton, USA, einRequirements-Engineering–Referenzmodell(REM) entwickelt, das Struktur und Inhalte derErgebnisse (,,Artefakte“) des Requirements-Engineering vorgibt. Es ist durch ,,Tailoring“auf unterschiedliche Anwendungsdomänen undDokumentenvorgaben zuschneidbar. Es unter-stützt iterative Prozesse und eine modellbasierteEntwicklung.

Der Ansatz REM wurde bereits erfolgreichzur Analyse und Bewertung durchgeführter Ent-wicklungsprozesse eingesetzt. Hierzu wurdendie im untersuchten Projekt erstellten Spezi-fikationsdokumente (beispielsweise Vision- &Scope-Dokument, Lasten- und Pflichtenhefte,Architekturdokumente, usw.) hinsichtlich derim Artefaktmodell festgelegten Inhalte undBeziehungen analysiert und bewertet. Gemein-sam mit der entsprechenden Untersuchungdes eingesetzten Requirements-Management-Werkzeugkonzepts können hieraus Aussagenzur Vollständigkeit und Qualität der betrach-teten Spezifikationsdokumente und ihresErarbeitungsprozesses gefolgert werden.

ten Teilaspekte eines Systems erstrecken. Die Fest-legung der Anforderungen bestimmt entscheidendsowohl die Qualität als auch die Kosten eines Systemsund damit auch dessen wirtschaftlichen Erfolg.

In sicherheitskritischen Anwendungen kommtder Anforderungsanalyse noch eine zusätzliche

Bedeutung zu. Nur, wenn alle sicherheitsrelevantenAnforderungen sauber erfasst werden, kann sicher-gestellt werden, dass von diesem System keine Ge-fährdung ausgeht, alle Risiken bedacht sind und überdie Anforderungen entsprechend adressiert werden.

Zahllose Probleme mit Systemen mit hohenSoftwareanteilen haben aus Sicht der Benutzeroft nicht mit der Frage zu tun, ob Anforderungenkorrekt umgesetzt werden, was durch Verifikationnachgewiesen wird, sondern betreffen eher denPunkt, dass die Anforderungen nicht im Sinne derNutzer angemessen festgelegt sind. Die berühmteFrage ,,Is it a bug or a feature?“ hat nur zu oft ihreUrsache in der ungenügenden Festlegung der An-forderungen. Wenn Systeme unerwartet und damitaus Sicht der Nutzer fehlerhaft reagieren, handelt essich eben nicht immer um Implementierungsfehler,bei denen die Spezifikation nicht korrekt umgesetztist, sondern allzu häufig auch um eine Diskrepanzzwischen dem, was der Nutzer erwartet und dem,was die Spezifikation festgelegt hat.

Untersuchungen zeigen, dass der Stand unddie Beherrschung des Requirements-Engineeringin der Praxis unbefriedigend sind. Vor diesem Hin-tergrund sind die Technische Universität München,vertreten durch den Lehrstuhl für Software undSystems Engineering, und die Siemens AG, vertretendurch Siemens Corporate Research Princeton, seiteinigen Jahren eine langfristige strategische Zusam-menarbeit zum Thema Requirements-Engineeringeingegangen. Das Ziel des akademischen Partnersliegt auf der Hand: Fundiertere Methoden und grö-ßere Systematik zum Requirements-Engineering,wie dies in den letzten Jahren in wissenschaftlichenArbeiten entwickelt wurde, stärker in die Praxiszu bringen. Das Ziel des industriellen Partners istandererseits auch klar: Auf Basis einer Vielzahlvon Erfahrungen auf diesem Gebiet und vor demHintergrund von Best-Practice-Ansätzen mithilfevon wissenschaftlichen Beiträgen das Thema zukonsolidieren und in eine langfristige Zusammen-arbeit einzutreten, um industrielle Projekte besserunterstützen zu können.

Requirements-Engineering und seinewirtschaftliche Bedeutung

Waren die Anfänge des Einsatzes von Softwarein Prozessen und Produkten eher von der Auto-matisierung bekannter Funktionen geprägt, sobestimmen die Entwicklung und den Einsatz von

Page 3: Ein Requirements Engineering Referenzmodell

AbstractEngineering supports a systematic collectionof product or system requirements regardingbusiness goals and constraints. The goal is toassure that the developed system optimallymeets the user and market needs. That meansthat all stakeholder expectations have beentaken in consideration. With regards to the highpace of innovation in software and software in-tensive systems and also the rapidly increasingfunctional complexity Requirements Enginee-ring excellence is now a critical success factorin product and system development. In thiscontext the Technical University Munich andSiemens Corporate Research are cooperatingin developing a Engineering Reference Model(REM) that defines the structure and content ofthe results (“artifacts”) of Requirements Engi-neering activities. It includes a tailoring conceptthat allows its adaptation to different applicationdomains and documentation constraints. REMsupports iterative processes and model baseddevelopment.

Software immer stärker auch innovative Funktionen.Diese erfordern zwangsläufig einen Lernprozessin Hinblick auf die wesentlichen funktionalenund nichtfunktionalen Anforderungen. Damitkommt dem Requirements-Engineering eine immertragendere Rolle zu.

Trends in der IndustrieDrei große Trends und die damit verbundenenHerausorderungen bestimmen heute unter anderemdie industrielle Fertigung von Produkten ebenso wiedie Entwicklung komplexer Systeme wie Verkehrs-leitsysteme, Computertomografien, Autoelektronik,Automatisierungssysteme oder Systeme für denEnergiebereich.

Diese aktuellen Trends sind:

· stark wachsende Komplexität der Produkte,· Software als Innovationstreiber, folglich immer kürzere

Innovationszyklen und· voranschreitende Globalisierung mit verteilter Entwicklung.

Im Folgenden zeigen wir kurz die Rolle desRequirements-Engineering für diese Trends

und welchen Beitrag es zur Bewältigung derdamit verbundenen Herausforderungen liefernkann.

Beherrschung der wachsenden KomplexitätProdukte, in denen immer häufiger verteilte Sys-teme mit vielfältigen Einsatzfunktionen eingebettetsind, werden zunehmend umfangreicher, an-spruchsvoller und komplexer. Sie offerieren IhrenNutzern reichhaltige Interaktionen mit Zugriff aufhoch innovative Funktionen (oder Features1). Aberoft kommt es zur sogenannten ,,Software Pollution“und zum ,,Over Engineering“, siehe Abb. 1. Dasheißt, das Produkt umfasst weit mehr Funktionenals der Nutzer und damit der Markt wirklich benö-tigt. Häufig sind auch mehr Features implementiertals tatsächlich ausgeliefert werden: Zum einen, umfür eventuelle zukünftige Benutzeranforderungengerüstet zu sein und zum anderen, weil die aktu-ellen Anforderungen zu vage formuliert sind unddeshalb mit weiteren Funktionen experimentiertwird.

Dies zeigt, dass ein Großteil der zunehmendenKomplexität hausgemacht und damit vermeid-bar ist. Allerdings ist hierzu ein professionellesRequirements-Engineering nötig, insbesondereein wohl definierter Erhebungsprozess und eineMethodik zur Bestimmung des ,,Geschäftswertes“einer Funktion oder Anforderung. Eine Methodik,die die Priorisierung der Anforderungen bezüglichihres Geschäftsnutzens unterstützt, garantiert nurdie Implementierung der wesentlichen Anforde-rungen. Um sicherzustellen, dass auch wirklichnur diese Features implementiert werden, müssendiese Anforderungen über den Entwicklungsprozessverfolgt und entsprechende Testfälle erstellt werden,um die Minimalität der Entwicklung sicherstellen zukönnen.

Neue Funktionalitäten –Software als Innovationstreiber mitimmer kürzeren Innovationszyklen

In den vergangenen Jahren ist der Anteil vonSoftware in Produkten, Dienstleistungen und Sys-temlösungen kontinuierlich gewachsen. Bei Siemensbeträgt der Softwareanteil in der Produkt- undLösungsentwicklung heute schon (schätzungsweise)mehr als 60%.

1 Ein Feature ist eine Gruppe von Produktfunktionen.

Page 4: Ein Requirements Engineering Referenzmodell

{ REQUIREMENTS-ENGINEERING

Abb. 1 Software Pollution [10]

Produktinnovationen werden zu einem starkwachsenden Teil in Softwarekomponenten rea-lisiert. 50% der Produkte, Dienstleistungen undSystemlösungen bei Siemens sind jünger als fünfJahre. In Hochtechnologiebranchen wie etwa der derMedizintechnik sind 90% der Produkte sogar jüngerals drei Jahre.

Bei diesen extrem kurzen Innovationszyklen istein effizientes und systematisches Requirements-Engineering mit einem wohl definierten Übergangvon innovativen Produktideen in den Realisie-rungsprozess unabdingbar. Falls Missverständnisseund Unklarheiten der Produktanforderungen inden frühen Phasen nicht beseitigt werden können,führen diese zu einem stark erhöhtem Aufwand inder Produktrealisierung und im schlimmsten Fallzum Scheitern des Produkts, wenn es am Marktvorbeientwickelt wird.

Voranschreitende GlobalisierungDie Industrie entwickelt heute nicht mehr nur fürlokale Märkte sondern für den Weltmarkt. Doch derWeltmarkt besteht aus vielen lokalen Märkten, dieihre spezifischen Anforderungen haben.

Um auf diesem Weltmarkt bestehen zu können,müssen die Produkte und Lösungen adaptierbarund auf die Anforderungen der lokalen Märkte ab-gestimmt sein. Für die technologische Realisierungleicht adaptierbarer Produkte müssen jedoch dieAnforderungen systematisch analysiert, die Gemein-samkeiten herausgearbeitet und von den variablenAnforderungen separiert werden. Gleiches gilt fürunterschiedliche Nutzergruppen und Zielmärkte.

Hierfür ist eine systematische Methodik zurErfassung und Unterscheidung der Anforderungen

in allgemeine und Zielgruppen oder marktspe-zifische Anforderungen erforderlich, sowie einentsprechender Prozess, der alle Beteiligten vonder Unternehmensführung, über Vertrieb, Marke-ting, Produktmanagement bis zur Entwicklung miteinschließt.

Eine weitere Dimension der Globalisierungist die zunehmende verteilte Entwicklung das Off-shoring in Niedriglohnländer. Beides erhöht dieAnforderungen an das Requirements-Engineeringenorm, da all die informellen Kommunikationswegewegfallen und zusätzlich kulturelle Differenzen dieKommunikation erschweren.

Requirements-Engineering in der PraxisUnter Requirements-Engineering verstehen wir dasErfassen, Analysieren, Entwickeln, Strukturierenund Dokumentieren von Anforderungen und Lö-sungskonzepten. Wesentliche Aufgaben sind hierbeidas Validieren und Abstimmen verschiedener,möglicherweise widersprüchlicher Aspekte derProduktentwicklung und die entsprechende Priori-sierung und Entscheidung über Anforderungen undzu realisierende Produktfunktionen.

Requirements-Engineering umfasst:

· die Identifikation aller Lebenszyklus-Aktivitäten mit demZiel, Geschäfts- und Anwenderanforderungen zu gewinnen,

· die Identifikation von Anforderungen und Randbe-dingungen abgeleitet aus der Zielumgebung undRealisierungstechnologien,

· die Analyse von Anforderungen und Ableitung detaillierterzusätzlicher Anforderungen,

· die Dokumentation und Management von Anforderungenund Spezifikationen,

Page 5: Ein Requirements Engineering Referenzmodell

· die Validierung und Verifikation der dokumentiertenAnforderungen gegen die Nutzerbedürfnisse,

· ein intuitives und eindeutiges Medium zur Kommunikationder Produkt- und Funktionalitätsideen zwischen Anwendernund Entwicklern,

· die Entwicklung innovativer Produktkonzepte, welche oftdurch Software ermöglicht werden und

· die Verwaltung und Instandhaltung der Produktanforde-rungen von der Auslieferung bis zur Abkündigung.

Bedeutung von Requirements-Engineeringim Entwicklungs-Life-Cycle

Industriestudien zum Thema Requirements-Engin-eering (RE) zeigen auf, wie stark der Einfluss vonRE auf den Projekterfolg ist. So weist der StandishReport [9, 30] nach, dass mehr als 50% der ,,Schlüs-selfaktoren“ für einen Projekterfolg im Require-ments-Engineering zu finden sind. Wingrove, Wie-gers und Gottesdiener schätzen, dass 40% bis 60%aller Produktdefekte im Requirements-Engineeringihren Ursprung haben [14, 33, 34].

Schon länger unbestritten ist, dass eine früheFehlerfindung durch eine stärkere Fokussierung aufdie frühen Entwicklungsphasen insgesamt zu einerKostenreduktion führt. Barry Boehm hat bereitsdarauf hingewiesen, dass Fehlerkorrekturen inden frühen Phasen 50 bis 200 mal billiger sind alswenn das Produkt im Feld ist [4]. Steve McConnellermittelte Faktoren zwischen 10 und 100 in seinenArbeiten [23].

Capers Jones untersuchte die Zeitaufwände fürdas überarbeiten der Requirements-Engineering-Defekte mit einem Ergebnis von 40% bis 50% desgesamten Projektaufwandes [19, 20].

Schwächen heutigerRequirements-Engineering-Praxis

Capers Jones stellte in seiner Untersuchung fest, dassdie Requirements-Engineering-Disziplin in mehr als75% aller Unternehmen nur sehr mangelhaft durch-geführt wird [19, 20]. Seine Ergebnisse machendeutlich, dass ein großes Verbesserungspotenzialvorhanden ist. Aufbauend auf seine Kategorisie-rung sehen wir folgende Herausforderungen alsbesonders kritisch:

· Es gibt keine eindeutige Definition, was eine ,,Best Practice“ist, letztendlich fehlen akzeptierte Referenzmodelle.

· Die Anforderungen sind mangelhaft dokumentiert, zulösungsorientiert, unvollständig, inkonsistent, nicht imple-

mentierbar und nicht skalierbar strukturiert. VerfügbareWerkzeuge sind sehr ineffektiv, bieten nur sehr generi-sche Konzepte, sind zu implementierungsnah, fordernhohen Administrationsaufwand und bieten schlechteVisualisierungskonzepte an.

· Zwischen Produktmanagement, Forschung & Ent-wicklung, Marketing und Vertrieb gibt es keine klarabgestimmten Vorgehensweisen und kein einheitlichesKommunikationsmedium.

· Häufige und späte Änderungen der Anforderungen sindnicht vermeidbar und werden insbesondere bei Prozessenmit sequenziellen Vorgehensweisen nicht ausreichendbeherrscht. Änderungsraten von 2–3% pro Monat [13] sindnicht untypisch.

Industrielle ProgrammeUm den genannten Herausforderungen in der Sys-tementwicklung zu begegnen und die identifiziertenSchwachstellen im Requirements-Engineering zubeheben, wurden in betroffenen Unternehmen sys-tematische Verbesserungsmaßnahmen initiiert. DieSiemens AG hat wie auch Alcatel [13] und Intel [25]ein Programm zur Verbesserung des Requirements-Engineering für Projekte aufgesetzt. Innerhalbvon Siemens ist Siemens Corporate Research fürdie Ausgestaltung des Requirements-Engineering-Programms verantwortlich. Es ist organisatorischmit dem unternehmensweiten top+ Programmassoziiert. Das Ziel ist Exzellenz im Requirements-Engineering und soll durch folgende Maßnahmenerreicht werden:

· Zur Verfügung stellen und Entwickeln von ,,state-of-the-art“-Requirements-Prozessen, Methoden, Tools und Metriken –insbesondere für spezifische Geschäftsdomänen.

· Einbettung von Requirements-Engineering in die Siemens-Geschäftsprozesse (Produktmanagement, Marketing,Innovation Management etc.).

· Aufbau von Trainings- und Zertifizierungsangeboten für dieMitarbeiter.

Das Programm ist auf sechs Säulen aufgebaut(s. Abb. 2), um obige Zielsetzung auch umfassendund nachhaltig umzusetzen.

Das Programm ist in die Siemens-Software-Initiative integriert und es wurden bereits dreierfolgreiche internationale Konferenzen mit Gast-rednern aus Industrie und Forschung durchgeführt.Speziell für Projekteiter und Manager wurde eineCheckliste entwickelt, die zehn kritische Erfolgs-

Page 6: Ein Requirements Engineering Referenzmodell

{ REQUIREMENTS-ENGINEERING

Abb. 2 Säulen des Siemens-Corporate-Research-Requirements-Engineering-Programms [1]

Abb. 3 Zehn kritische Erfolgsfaktoren der erfolgreichen Produktdefinition und Anforderungsanalyse [3]

faktoren für eine erfolgreiche Produktdefinitionfestlegt. Sie erhebt keinen Anspruch auf Vollständig-keit, aber wenn mehrere dieser Faktoren in einemProjekt nicht beachtet werden, sind Probleme zuerwarten (s. Abb. 3).

Requirements-Engineeringan 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 eineFülle von Arbeiten, die gerade dem Thema derformalen Spezifikation von Datenstrukturen undProgrammen gewidmet waren. Dazu gehörengrundlegende Arbeiten zum Thema Semantikvon Programmiersprachen, aber auch methodi-sche Arbeiten zur Spezifikation von Programmen

Page 7: Ein Requirements Engineering Referenzmodell

durch Annotationen und letztlich auch Arbeitenin Verbindung mit den Ansätzen der Programm-verifikation. Diese Ansätze im Umfeld sogenannterformaler Methoden waren aber deutlich getrenntvon stärker pragmatischen Überlegungen, die auchmit praktischen Fragestellungen in Verbindung zusehen sind, wie Methoden der strukturierten Ana-lyse, die bereits auch diagrammatische Technikeneinsetzten, um Anforderungsanalyse zu betreiben.In einem umfassenden Sinn wurde das ThemaRequirements-Engineering jedoch auf akademi-scher Seite in diesen frühen Zeiten nicht behandelt.Im Laufe der Jahre entstanden, parallel zu den Ar-beiten der formalen Methoden, schließlich stärkerpragmatische Ansätze zur systematischen Analyseund Erarbeitung von Anforderungen. Die wissen-schaftlichen Gruppierungen zum Thema formalerMethoden und die Forschergruppen, die sich stärkermit Requirements-Engineering als pragmatischeAufgabenstellung beschäftigten, blieben aber imLaufe der Jahre weitgehend disjunkt.

Es zeigt sich, dass für fortgeschrittenes Require-ments-Engineering eine Synthese aus diesen eherformalen Ansätzen und den pragmatischen Vorge-hensweisen, die eine breitere Sicht auf das Require-ments-Engineering haben, erforderlich ist. Hinzukommen die Ideen der modellbasierten Entwick-lung, die eine konsequente Fortsetzung der Ansätzeformaler Methoden sind und heute in der Praxisstärker pragmatisch eingesetzt werden. Ein Ziel fürein stärker werkzeugunterstütztes, besser in die

Abb. 4 Grafische Systembeschreibungstechniken in AutoFocus

späteren Entwurfsphasen integriertes, bewertbares,quantifizierbares und in Teilen automatisierbaresRequirements-Engineering ist das konsequente Ein-führen von Modellen in das Requirements-Engin-eering. Dabei handelt es sich einmal um Modelle,die geeignet sind, funktionale Anforderungen zubeschreiben, zum anderen um Modelle, die stärkerauf Architekturen ausgerichtet sind und in einemZusammenhang zu nichtfunktionalen Anforderun-gen zu sehen sind, aber auch um weiterführendeModellbildungen im Zusammenhang mit Qualitäts-modellen und nichtfunktionalen Anforderungen.

Hier finden sich viele faszinierende Forschungs-fragen, die in vielerlei Hinsicht noch nicht genügendbearbeitet sind.

AusgangspunktDer Lehrstuhl für Software und Systems Engineer-ing der Technischen Universität München (TUM)arbeitet seit langem auf dem Gebiet der formalenModellierung und Systemspezifikation. Ziel istes präzise und adäquate/brauchbare System-beschreibungsmodelle zu entwickeln, die mitentsprechenden Techniken die qualitativ höher-wertige Systemdefinition unterstützen. Dies umfasstmodellbasierte Methoden der Systemspezifikation,Verifikation, Codegenerierung, Qualitätssiche-rung und Testspezifikation. Abbildung 4 zeigtdie Systembeschreibungsmodelle des WerkzeugesAutoFocus [2, 5, 36]. Es ist ein modellbasiertes Ent-wicklungswerkzeug für den Entwurf eingebetteter

Page 8: Ein Requirements Engineering Referenzmodell

{ REQUIREMENTS-ENGINEERING

Systeme. Es verbindet Konzepte der Design-Modellierung, der Simulation sowie der Code- undTestfallgenerierung, und erlaubt die Verifikationvon Software-Komponenten. Die mathematischfundierten2 Systemsichten mit ihren grafischenBeschreibungstechniken sind (s. Abb. 4):

· hierarchische Strukturdiagramme (SSDs),· Zustandsautomaten (STDs),· erweiterte Sequenzdiagramme (EETs) und· Datentypdefinitionen (DTDs).

Nachdem der Schwerpunkt bisher auf derpräzisen und angemessenen Spezifikation des er-forderlichen Systemverhaltens lag, geht man jetztdazu über modellbasierte Methoden auch in derKernphase des Requirements-Engineering anzu-wenden, bis hin zu ihrem systematischen Einsatz zurschrittweisen Konstruktion, Analyse und zielorien-tierten Konsolidierung von Anforderungsmodellen.Entsprechende Grundkonzepte des modellbasiertenRequirements-Engineering, der artefakt-zentriertenProzessdefinition, der Qualitätssicherung und dermessbaren Entscheidungsunterstützung sind in [15]zusammengefasst.

Der Ansatz des Requirements-Engineering-Re-ferenzmodell (REM) [16], wie er im nachfolgendenAbschnitt ausführlich dargestellt wird, ist ein ersterSchritt in Richtung auf eine Synthese zwischenformalen Techniken, insbesondere Modellierungs-techniken und einem breit angelegten methodischenAnsatz zum Requirements-Engineering.

Gemeinsam mit den Erfahrungen der Siemens-Forschung zum Requirements-Engineering undweiteren Vorarbeiten der TUM zu Qualitätsmodel-len [6, 11] und der artefakt-orientierten Prozess-definition im V-Modell XT [35] sind diese Ansätzein REM umgesetzt und im Kontext komplexerindustrieller Anforderungen präzisiert worden.

REM schafft hierbei zunächst ein Referenzmo-dell, das die wesentlichen Artefakte, die als Ergebniseines strukturiert angelegten Requirements-Engin-eering zu erarbeiten sind, festlegen und zueinanderin Beziehung setzt. Für REM existieren erste Ausprä-gungen zum Einsatz formaler Methoden, zumindestfür die konstruktive Erarbeitung und qualitativeÜberprüfung bestimmter Artefakte. In weiterenSchritten ist geplant, hier eine umfassendere Ausar-

2 Der strombasierte Ansatz von FOCUS [7] zur Systemmodellierung.

beitung von modellbasierten Methoden schrittweiseREM hinzuzufügen.

Requirements-Engineering-Referenzmodell (REM)

Ausgangspunkte für die Entwicklung von REMwaren die Forschungsaktivitäten der TUM sowieErfahrungen und Projekte der Siemens CorporateResearch (SCR) in Princeton, USA und SiemensCorporate Research & Technology (CT) in Mün-chen. Die zentralen Forschungseinheiten haben dieAufgabe, die Siemens-Geschäftsbereiche durch Best-Practice-Sharing und Innovation in diesem Bereichzu unterstützen.

ZielsetzungZielsetzung von REM ist die Unterstützung undProzessdefinition des Requirements-Engineering(RE) auf der Basis eines grundlegenden Modellszu erarbeitender Spezifikationsartefakte und ihrerBeziehungen. Hierzu definiert REM

· eine Kernmenge von RE Artefakten und ihren Abhängig-keiten – das RE-Artefaktmodell – und

· ein artefakt-zentriertes Tailoring-Konzept.

In Analogie zum V-Modell XT unterstützt dies eineartefakt-basierte Prozessdefinition und definiertMeilensteine in der Systementwicklung auf derBasis von zu erarbeitenden RE-Artefakten. Für dieAnwendung und Instanziierung des Ansatzes inkonkreten Projekten und Domänen ist ein Tailoring-Konzept definiert.

REM im ProduktlebenszyklusREM geht von folgenden Aufgaben des Require-ments-Engineering im Lebenszyklus eines Pro-duktes aus. Hierzu gibt Abb. 5 einen allgemeinenÜberblick über Entstehung, Einsatz und Wartungeines Produktes und seiner schrittweisen Weiterent-wicklung auf Basis von Kundenerfahrungen, neuenMarktstrategien und Technologien.

Die Aufgaben des Requirements-Engineeringsind hierbei:

· Marketinginformationen und Nutzeranforderungen zuanalysieren, die funktionalen und nichtfunktionalen Anfor-derungen abzuleiten und den entsprechenden funktionalenEntwurf des Systems zu steuern.

· Die Auswirkungen dieser Anforderungen auf das Geschäftund den Erfolg des Produktes im Markt zu verstehen.

Page 9: Ein Requirements Engineering Referenzmodell

Abb. 5 Der Produktentstehungsprozess im Überblick

· Diese Anforderungen abzustimmen, zu konsolidieren undin einer Anforderungs- und Systemspezifikation konsistentund vollständig zu spezifizieren.

Somit hat das Requirements-Engineering einezentrale Rolle in der Produktdefinition und Ent-wicklung. Die erarbeiteten Spezifikationsartefaktesind die Basis für Produktdesignentscheidungund Projektmanagement während des gesamtenProduktlebenszyklus. Die Qualität und Angemes-senheit der Artefakte ist ein Schlüsselfaktor für dieerfolgreiche Systementwicklung.

Das ArtefaktmodellREM strukturiert und gibt Vorgaben für dieAnforderungsanalyse- und Systementwurfsak-tivitäten mittels eines grundlegenden Modells vonRequirements–Engineering-Spezifikationspro-dukten – dem RE-Artefaktmodell. Abbildung 6zeigt einen Überblick über das Modell und seineStruktur. Es unterteilt die zu erarbeitenden An-forderungen (RE-Artefakte) in die GruppenBusiness-Needs, Requirements-Specification undSystem-Specification. Die Artefakte mit ihren defi-nierten Inhalten bestimmen die Struktur und Inhalte

der zu erarbeitenden Spezifikationsdokumente derfachübergreifenden Abstimmungsaktivitäten derProduktentwicklung.

Das Modell ist nach folgenden Paradigmender integrierten Anforderungsanalyse und System-definition gestaltet:

· ziel- und nutzerorientierte Analyse und Verfeinerung vonAnforderungen und funktionalen Entwurfskonzepten,

· Analyse und Verfeinerung von ,,high-level“ funktionalenund nichtfunktionalen Anforderungen mithilfe eines grund-legenden Beschreibungskonzeptes für Systeme und ihresVerhaltens aufbauend auf der Modellierung funktionalerSystemsichten und

· qualitative Überarbeitung erarbeiteter Spezifikationen aufBasis definierter Beziehungen zwischen verschiedenenKlassen von Anforderungen und Systemmodellen (RE-Artefakten) des Artefaktmodells. Diese Abhängigkeitenzwischen Artefakten bilden messbare Konsistenzbe-dingungen und können für die Verifikation undValidierung erstellter Systemanforderungen genutztwerden.

Entsprechend dieser methodischen Konzepte ist dieBeschreibung der einzelnen RE-Artefakte aufgebaut

Page 10: Ein Requirements Engineering Referenzmodell

{ REQUIREMENTS-ENGINEERING

Abb. 6 Überblick über das REM-Requirements-Engineering-Artefaktmodell

und gibt Vorschläge einzusetzender Methoden undBeschreibungstechniken zur Konstruktion, Kommu-nikation und Konsolidierung ihrer erforderlichenInhalte (Content-Items). Die weitere Unterteilungder Artefakte in Content-Items wird in Abb. 7 am Bei-spiel der Requirements-Specification-Artefaktgruppedemonstriert.

Artefaktgruppen

Business-Needs-ArtefakteDie Business-Needs-Artefakte spezifizieren kunden-und produktstrategische Anforderungen, ins-besondere die Geschäfts- und Produktziele derSystementwicklung. Zu der Gruppe gehörenfolgende Artefakte:

· Business-Objectives und Customer-Requirements spe-zifizieren Kundenanforderungen und beschreiben dieMarktpositionierung des zukünftigen Produktes.

· System-Vision listet die geforderten funktionalenAnforderungen/Features auf und legt die Planungsan-nahmen und Projektabhängigkeiten der Produkt- oderProduktlinienentwicklung fest.

· General Conditions und Scope & Limitations spezifizieren,,high-level“-nichtfunktionale Anforderungen und Beschrän-kungen und grenzen den relevanten Ausschnitt der Anwen-dungsdomäne und gegebenenfalls der Produktlinie ab.

· Return of Investment (ROI) und Business-Risk fassen dieErgebnisse mehrfacher Kosten-Nutzen-Analysen, erwarteteVerkaufserlöse, Entwicklungs- und Markteinführungskostenzusammen und stellen die entsprechende Risikoanalyse vonAnforderungen in den Mittelpunkt.

· System-Success-Factors spezifizieren und priorisieren dieKriterien für den finalen Produkterfolg.

Diese Produktziele und Abgrenzung sind das Er-gebnis sorgfältiger Marketing-, Portfolio- undKundenabstimmung. Gemeinsam mit wiederhol-ten Return-of-Investment- und Risikoanalysenlegen sie die Basis für die nachfolgende Ent-wicklungsarbeit und bilden die Grundlage fürProduktdesign-Entscheidungen.

Requirements–Specification-ArtefakteDie Requirements-Specification-Artefakte bein-halten die funktionalen und nichtfunktionalenAnforderungen an das zu entwickelnde System.

Page 11: Ein Requirements Engineering Referenzmodell

Abb. 7 Überblick über die Requirements-Specification-Artefakte

Mithilfe dieser Artefakte werden die Ziele und Vor-gaben der Business-Needs-Artefakte aus Kunden-und Nutzersicht analysiert, strukturiert und detail-lierte Anforderungen und Qualitätsvorgaben an dasNutzungserhalten des Systems abgeleitet. Zu ihnengehören diese Artefakte:

· Functional-Analysis-Models enthalten Analyse- undBeschreibungsmodelle der Geschäfts- und Anwendungs-prozesse. Sie dienen der Kommunikation der Kunden-und Nutzeranforderungen, der Bestimmung erforderlicherSystemdienste/Features und Qualitätseigenschaften undsie bilden die Basis für die Evaluierung und Bewertungerarbeiteter System-Specifications.

· Domain-Models sind eine strukturierte Spezifikation derAnwendungsdomäne und ihrer Charakteristika und wer-den ergänzt durch eine Modellierung der operationellenUmgebung des zukünftigen Systems.

· Nichtfunktionale Anforderungsmodelle verfeinern und struk-turieren Qualitätsanforderungen (Quality Requirements),

Annahmen (Assumptions & Dependencies) und Constraints(Design-Constraints) und bilden diese auf die detailliertenAnforderungen der System-Specification ab.

· Acceptance-Criteria spezifizieren die Abnahme- undTestkriterien des auszuliefernden Systems.

Die wesentliche Rolle der Analysemodelle der Re-quirements-Specification-Artefakte ist die Verfei-nerung und Strukturierung der ,,high-level“-fest-gelegten Business-Needs sowie ihrer Abbildung aufdie detaillierten Systemanforderungen des entspre-chenden Systementwurfskonzeptes. Sie bilden dieEntscheidungsbasis für die Priorisierung von Anfor-derungen und ermöglichen begründete und nach-vollziehbare Produktdesignentscheidungen. Zuge-schnitten auf domän- und projektspezifische Erfor-dernisse können hier passende Methoden und Be-schreibungstechniken für die Erarbeitung und Ab-stimmung der RE-Artefakte eingesetzt werden. Ak-tuelle Ansätze der Prozess- und Szenarioanalyse hier-

Page 12: Ein Requirements Engineering Referenzmodell

{ REQUIREMENTS-ENGINEERING

zu sind Strukturierungsmethoden von [27, 28], derFraunhofer-QUASAR-Ansatz [29], AutoRAID [15, 17],die aufgabenorientierte Szenarioanalyse von [8, 31]und Methoden der szenariobasierten Testfallab-leitung [18]. Ansätze der Ziel- und Qualitätsmodel-lierung sind KAOS [22], ATAM [21], TROPOS [32]sowie die ASPIRE-Methode für die Konstruktionerfahrungsbasierter Qualitätsmodelle [12]. Dasgrundlegende Konzept von REM, Anforderungenmithilfe funktionaler Systemsichten herauszuar-beiten und zu strukturieren (AutoRAID/Auto-Focus [2, 15, 17, 36]) findet sich auch in den Ansätzenvon [26, 27] wieder.

System-Specification-ArtefakteDie System–Specification-Artefakte adressieren dendetaillierten Entwurf des funktionalen Systemkon-zeptes: Es spezifiziert das erforderliche Verhaltendes betrachteten Systems und seine Integration indas technische Gesamtsystem und die Anwendungs-umgebung. Zusätzlich werden die Bedingungen fürden detaillierten Entwurf und die Realisierung desSystems innerhalb der Entwicklungsdisziplinen(Software, Elektrik/Elektronik und Mechanik)festgelegt. Folgende Artefakte bestimmen dieSystem-Specification Artefaktgruppe:

· User–Interface-Specification und User-Documentation be-schreiben die Nutzungsschnittstelle und mögliche Abläufewie die Nutzer das System benutzen können.

· Functional-System-Concept: Detaillierte Systeman-forderungen spezifizieren die erforderlichenSystemdienste/Funktionen, mit entsprechenden Anfor-derungen an Interaktion, Verhalten, Datenstrukturen,das zugrunde liegende Datenmodell und die Nut-zungsbedingungen des Systems. Gemeinsam mit derExternal-Interface-Specification wird die Integration desSystems in das Gesamtsystem definiert.

· External-Interface-Specifications definieren die Schnittstellendes Systems zu kooperierenden Komponenten und Sys-temen der Umgebung und zu genutzten Software- undHardware-Komponenten.

· Design-Constraints begrenzen den detaillierten Sys-tementwurf und die Realisierung innerhalb derEngineering-Disziplinen.

· System-Test-Criteria bilden Akzeptanz- und Testkriterien fürSystemintegration und Evaluierung.

Diese drei Gruppen des RE-Artefaktmodells zielenauf die vorherrschenden Inhalte der wesentlichen

Phasen in der Produktdefinition – weniger auf denkonkreten Aufbau der Dokumente. Spezifikations-dokumente als Basis für Meilensteinentscheidungensetzen sich aus Inhalten quer über das Artefakt-modell zusammen. Die spezifisch erforderlichenDokumentstrukturen eines Entwicklungsprojekteswerden durch das domänenspezifische Tailoringdes Artefaktmodells und der daraus folgendenProzessdefinition bestimmt.

Prozessdefinition und TailoringDas RE-Artefaktmodell bildet den Ausgangspunktfür das domänenspezifische Tailoring und eineartefakt-zentrierte Prozessdefinition. REM definiertMeilensteine und Entscheidungspunkte im Produkt-entstehungsprozess in Form von Vollständigkeits-bzw. Qualitätsstufen auf den RE-Artefakten.

Artefakt-basierte ProzessdefinitionAbbildung 8 zeigt dieses Konzept der artefakt-zentrierten Prozessdefinition: Das Artefaktmodelldefiniert Inhalt und Struktur der gesamtenSpezifikationsdokumente. Ihre festegelegten Voll-ständigkeitsstufen bilden die messbare Grundlagefür Reviews und Entscheidungen in Produktdefini-tion und Realisierung. Für ihre einfache Darstellungsind diese Vollständigkeitsstufen durch Prozent-zahlen der RE-Artefakte zusammengefasst. Sierepräsentieren den gewünschten Grad an Qualitätund Vollständigkeit zu dem erreichten Zeitpunkt desbetreffenden Entscheidungspunktes. ZugehörigeVersionen der Spezifikationsdokumente bilden dieDecision-Base (Entscheidungsbasis) D(i) für Meilen-steine oder Quality Gates im Entwicklungsprozess,und sie sind Input für die artefakt-spezifischePlanung (Plan) und Durchführung iterativerKonstruktions- (Develop) und Abstimmungsaktivi-täten (Verify) der interdisziplinären Anforderungs-und Systemdefinition.

REM geht von einer grundlegenden iterativenErarbeitung der Systemspezifikation aus, in der An-forderungen und Lösungskonzepte in wechselndenPhasen der Entwicklung und Abstimmung (Developund Verify) systematisch mithilfe grundlegendermethoden-abhängiger Modellierungskonzepteanalysiert (Analyze), verfeinert (Refine), struktu-riert/modelliert (Structure & Model), vervollständigtund konsolidiert (Complete) werden.

Anzahl und inhaltliche Gestaltung solchervordefinierten Entscheidungspunkte sind abhängig

Page 13: Ein Requirements Engineering Referenzmodell

Abb. 8 Prozessdefinition mittels Vollständigkeitsstufen von Spezifikationsdokumenten

vom der jeweils gewählten Prozessstrategie, z.B.einer agilen, komponenten-orientierten oder ehertraditionellen Vorgehensweise.

TailoringDie artefakt-orientierte Prozessdefinition erfolgtnach folgenden Tailoringschritten:

· Pruning des Artefaktmodells – Zuschneiden und Anpassender zu erarbeitenden Anforderungsinhalte (RE-Artefakte)und Spezifikationsdokumente. REM definiert mandatory,recommended, optional RE-Artefakte und Inhaltspunkte(Content-Items).

· Auswählen, Zuordnen und Anpassen von Methoden undBeschreibungstechniken für das Herausarbeiten undSpezifizieren der RE-Artefakte und Content-Items.

Abb. 9 Überblick über artefakt-orientiertesProzess-Tailoring in REM

· Prozessstrategie – Entscheiden über die Prozessstrategieund Festlegen der Reihenfolge in der die RE-Artefakte zuerarbeiten und zu vervollständigen sind und entsprechendeDefinition der Entscheidungspunkte, Meilensteine oderQuality-Gates. REM empfiehlt ein iteratives und review-basiertes Vorgehen.

· Zuordnen von Teammitgliedern zu Rollen und von Rollenzu Spezifikationsdokumenten und Inhalten (RE-Artefakte).In Anlehnung an das Microsoft Teammodell [24] definiertdas Rollenkonzept in REM grundlegende Rollen-Clusterund ihre Zuständigkeit für Teile des Artefaktmodells. Fürjedes RE-Artefakt sind in REM Responsible- und Contributing-Rollen definiert.

Abbildung 9 fasst das Tailoring-Konzept von REMzusammen: Aktivitäten (Activities), Meilensteine

Page 14: Ein Requirements Engineering Referenzmodell

{ REQUIREMENTS-ENGINEERING

Abb. 10 Meilensteindefinition in REM am Beispiel des Siemens Product-Life-Cycle-Process (PLM)

(Decision-Gates) und Rollen (Roles) sind nachRE-Artefakten (RE-Artifacts) bzw. Spezifikations-dokumenten (Documents) strukturiert. Durch dasTailoring erfolgt die domänen-/projektspezifischeAnpassung des Artefaktmodells, die Festlegungder Spezifikationsdokumente und die Definitionder Entscheidungspunkte mittels dokumentspezifi-scher Art und Vollständigkeitsstufen. Dies schließtdie Festlegung von Methoden und Tools für dieKonstruktion der Artefakte und Dokumente mit ein.

Das Ergebnis der Prozessinstanziierung istein Arbeitsplan mit Aktivitäten zur Erarbeitungder Dokumente, RE-Artefakte und ihrer Inhalte.Entsprechend der definierten Vollständigkeitsstufenkönnen die zugehörigen Dokumente iterativ inVersionen entwickelt werden.

Durch die Bereitstellung von Templates,Checklisten, Methoden und Tools bietet dasartefakt-basierte Tailoring in REM die Grund-lage für Qualitäts- und Fortschrittsmessung imRequirements-Engineering und damit die Basis für

die zielorientierte und effektive Entwicklung vonAnforderungen und Systemkonzepten.

Abbildung 10 zeigt ein Beispiel des Tailoringin REM anhand des Siemens Product-Life-Cycle-Process (PLM) und der entsprechendenVollständigkeitsstufen der Spezifikationsdokumentean den PLM-Meilensteinen M100, M150, und M200.

Methoden und Werkzeugunterstützungfür REM

Der Ansatz REM liefert ein Referenzmodell fürdie Struktur und Inhalte der Ergebnisse desRequirements-Engineerings. REM ist in seinerjetzigen Form weitgehend methoden-, werkzeug-und prozessunspezifisch. In zukünftigen Schrittenwerden Methoden in REM integriert. In [16] wer-den explizit für alle Artefakte die heute üblichenMethoden zur Beschreibung aufgezählt. Eine spe-zielle Betonung oder Bewertung objektorientierterMethoden wird nicht durchgeführt. Generell sindStrukturierungs- und Modularisierungskonzepte

Page 15: Ein Requirements Engineering Referenzmodell

für alle Methoden insbesondere in Hinblick aufeine zufrieden stellende Skalierbarkeit essenziell.Daher sind entsprechende Methoden für industrielleProjekte vorzuziehen.

Eine besondere Rolle kommt dem Prototypingim Requirements-Engineering zu. Prototyping kanninsbesondere bei vagen Anforderungen und hochinnovativen Produktentwicklungen in den Entwick-lungsprozess systematisch integriert werden, um dieStakeholder in die Anforderungsanalyse intensivereinzubinden. Prototyping kann zur Erarbeitung derArtefakte in das Referenzmodell integriert werden,ist aber letztlich nur eine Methode zur Erfassungund Konsolidierung von Anforderungen und dahernicht im Fokus dieser Arbeit.

Zur Werkzeugunterstützung von REM gibt eseinen ersten Prototyp, der parallel zur Entwicklungvon REM entstanden ist. Es handelt sich dabeium das von der TUM entwickelte Requirements-Management und SystemspezifikationswerkzeugAutoRAID/AutoFocus [17, 36]. Das Werkzeug betontden Ansatz des modellbasierten Requirements-Engineering. Es ist prototypisch umgesetzt undanhand von Fallstudien erfolgreich erprobt.

Fazit und AusblickEs bleibt die Frage, was wir bisher mit REM er-reicht haben. Das entwickelte Referenzmodellfür Requirements-Engineering (REM) ist einerster wichtiger Schritt um sich das Thema desRequirements-Engineering durch Systematisierungstärker zu erschließen. Es dient zum Absteckender Bestandteile eines umfassenden Requirements-Engineering-Ansatzes und wird dazu beitragen, dassein einheitlicheres und strukturiertes Verständnisfür das Thema Requirements-Engineering erreichtwird – und zwar für Forschung und die industri-elle Praxis. Die flexible Prozessdefinition und dasTailoring erlauben es zudem, einen Requirements-Engineering Prozess projektspezifisch anzupassen.Damit werden sowohl das Vorgehen als auch dieKommunikation zwischen Projektbeteiligten (z.B.Produktmanagement, Forschung & Entwicklung,Marketing und Verkauf) abgestimmt.

Viele Fragen sind auch durch REM in seineraktuellen Form naturgemäß nicht beantwortet undviele Forschungsthemen sind noch nicht bearbeitet.Um REM als Referenzmodell zu etablieren, ist esnotwendig, das Modell für die Forschung und Praxisweiter auszuarbeiten und zu verfeinern. Um dies zu

erreichen, ist es unabdingbar, Erfahrungen aus in-dustriellen Softwareprojekten zusammenzuführen.Wesentlich zu klären ist die Frage, welche einzel-nen Methoden für die Erarbeitung der Artefaktesich anbieten und wie diese Methoden ineinandergreifen. Für den praktischen Einsatz von REM sindInstanzen zu bilden, die auch die Wahl speziellerMethoden für die Erarbeitung der Artefakte und ent-sprechender Unterstützungswerkzeuge umfassen.Diese Instanzen bilden dann umfassendere konkrete,praktisch einsetzbare Vorgehensmodelle für dasRequirements-Engineering. Die Bildung spezifischerInstanzen ist aktuelles Thema laufender Forschungs-arbeiten an der Technischen Universität Münchenund bei Siemens Corporate Research Princeton.

Verschiedene Formen der Anwendung bietensich für REM an. REM kann als Methoden-Framework, als Planungswerkzeug für anstehendeRequirements-Engineering-Projekte, als Bewer-tungswerkzeug für laufende oder abgeschlosseneRequirements-Engineering-Projekte, als Bei-spielsammlung (Best Practice) für (ausgewählte)Requirements-Engineering-Projekttypen etc. ein-gesetzt werden. Damit können dann auch bekannteSchwächen im Requirements-Engineering von Soft-wareprojekten (z. B. Dokumentation, Skalierbarkeit,Implementierbarkeit, Änderungsmanagement, undMetriken zur Bewertung der Qualität der Anforde-rungen und der Anforderungsprozesse) aufgedecktund behoben oder sogar frühzeitig vermiedenwerden.

Literatur1. Achatz, R., Berenbach, B., Broy, M., Kazmeier, J., Ros, J., Rudorfer, A., Subrama-

nyan, R.: Requirements Engineering: A Key to Business Success for Siemens.Siemens Corporate Research (SCR) Technical Report, March (2006)

2. AutoFocus: AutoFocus – A CASE tool for Requirements, Design, Code Generationand Simulation: http://www4../∼af2 (2006)

3. Berenbach, B.: Requirements Engineering Checklist. Siemens Corporate Research(SCR) SE, Internal Publication (2005)

4. Boehm, B., Pappaccio, C.: Understanding and Controlling Chaos. IEEE Transactionsof Software Engineering, October (1988)

5. Braun, P., Lötzbeyer, H., Schätz, B., Slotosch, O.: Consistent Integration of FormalMethods. In: Proc. Intl. Conf. On Tools fort he Analysis of Correct Systems(TACAS), LNCS 2280 (2006)

6. Broy, M., Deissenboeck, F., Pizka, M.: Demystifying Maintainability. WoSQ ’06:Proceedings of the 4th Workshop on Software Quality (2006)

7. Broy, M., Stoelen, K.: Specification and Development of Interactive Systems.Springer (2001)

8. Carroll, J.: Scenario-Based Design: Envisioning Work and Technology in SystemDevelopment. Wiley & Sons (1995)

9. Chaos Report 2001: http://www.projectsmart.co.uk/docs/chaos_report.pdf10. Cohen, D., Larson, G., Ware, B.: Improving Software Investment Through Require-

ments Validation. Sente Corporation (2002)11. Deissenboeck, F., Seifert, T.: Kontinuierliche Qualitätsüberwachung mit ConQAT.

Jahrestagung der Gesellschaft für Informatik 2006, Workshop Software-Leitstände(2006)

Page 16: Ein Requirements Engineering Referenzmodell

{ REQUIREMENTS-ENGINEERING

12. Doerr, J., Kerkow, D., Koenig, T., Olsson, T., Suzuki, T.: Non-Functional Require-ments in Industry – Three Case Studies Adopting the ASPIRE NFR Method. IESE-Report No. 025.05/E (2005)

13. Ebert, C.: Requirements Before Requirements: Understanding the Upstream Im-pacts. In: Proceedings RE’05, Paris (2005)

14. Firesmith, D.: A Business Case for Requirements Engineering. Presentation at SEI,September 2003: http://www.sei.cmu.edu/programs/acquisition-support/presentations/firesmith/business-case/case.pdf (2006)

15. Geisberger, E.: Requirements Engineering Eingebetteter Systeme – ein interdiszi-plinärer Modellierungsansatz. Dissertation, Technische Universität München, 2005.Shaker Verlag, ISBN: 3-8322-4619-3, www.shaker-online.com/

16. Geisberger, E., Berenbach, B., Broy, B., Kazmeier, J., Paulish, D., Rudorfer, A.: Re-quirements Engineering Reference Model (REM). Technischer Bericht TUM-I0618,TU München, November (2006)

17. Geisberger, E., Schätz, B.: Modellbasierte Anforderungsanalyse mit AutoRAID.GI Informatik – Forschung und Entwicklung, Springer Verlag (2007)

18. Halmans, G., Kamsties, E., Pohl, K., Reis, S., Reuys, A.: Seamless Transition fromRequirements to Test Cases: How to Test a Software Product Line? In: Proceed-ings of the Conference on Software Testing, ICSTEST-E (Bilbao, Spain, November2004). SQS, Düsseldorf (2004)

19. Jones, C.: Applied Software Measurement – Assuring Productivity & Quality. NewYork, McGraw Hill (1996)

20. Jones, C.: Estimating Software Requirements. In CROSSTALK – The Journal of De-fense Software Engineering, June 2002: http://www.stsc.hill.af.mil/crosstalk/2002/06/jones.pdf (2006)

21. Kazman, R., Klein, M., Clements, P.: ATAM: Method for Archtecture Evaluation.Technical Report, CMU/SEI-2000-TR-004 (2000)

22. Lamsweerde, A., Darimont, R., Letier, E.: Managing Conflicts in Goal-Driven Re-quirements Engineering. IEEE Trans. Software Eng. 24(11), 908–926 (1998)

23. McConnell, S.: Rapid Development: Taming Wild Software Schedules. MicrosoftPress (1996)

24. Microsoft Solution Framework (MSF) Team Model. White Paper. 2002. Homepage:http://www.microsoft.com/msf (2006)

25. Nesland, S.: Initial Lessons Learned from the Definition and Implementation ofa Platform Requirements Engineering Process at Intel Corporation. In: ProceedingsRE’05, Paris (2005)

26. Paech, B., Von Knethen, A., Doerr, J., Bayer, J., Kerkow, D., Kolb, R., Trendowicz,A., Punter, T., Dutoit, A.: An Experience-Based Approach for Integrating Architec-ture and Requirements Engineering, ICSE’03 Workshop “From Software Require-ments to Architectures” (2003)

27. Pohl, K., Brandenburg, M., Gülich, A.: Integrating Requirement and AchitectureInformation – A Scenario and Meta-Model Based Approach. In: Proc. of REFSQ2001 Workshop. Interlaken, Schweiz (2001)

28. Pohl, K., Haumer, P.: Modelling Contextual Information about Scenarios. In: Proc.of the 3rd Intl. Workshop on Requirements Engineering – Foundation of SoftwareQuality (REFSQ ‘97). University Press Namur, Barcelona, Spain (1997)

29. QUASAR-Projekt. Homepage: http://www.first.fraunhofer.de/quasar (2006)30. Standish Group Reports: http://www.standishgroup.com/sample_research/

PDFpages/q3-spotlight.pdf (2006), http://www.standishgroup.com/sample_research/Pdfpages/extreme_chaos.pdf (2006)

31. Sommerville, I.: Software Engineering. 7th Edition. Addison Wesley (2004)32. TROPOS-Projekt. Homepage: www.troposproject.org/ (2006)33. Wiegers, K.: Software Requirements. 2nd Edition, Microsoft Press (2003)34. Wiegers, K., Lawrence, B., Ebert, C.: The Top Risks of Requirements Engineering.

IEEE Software, November/December (2001)35. V-Modell XT. http://www.v-modell-xt.de/ (2006)36. Wild, D.: AutoFocus 2 – Das Bilderbuch. Technische Universität München, Techni-

cal Report: TUM-I0610, May (2006)