• Like
Ein Requirements Engineering Referenzmodell
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Ein Requirements Engineering Referenzmodell

  • 1,242 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,242
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
17
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 BeherrschenSystemen 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, insbesondereSoftware immer stärker auch innovative Funktionen. ein wohl definierter Erhebungsprozess und eineDiese 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üglichkommt dem Requirements-Engineering eine immer ihres Geschäftsnutzens unterstützt, garantiert nurtragendere Rolle zu. die Implementierung der wesentlichen Anforde- rungen. Um sicherzustellen, dass auch wirklich Trends in der Industrie nur diese Features implementiert werden, müssenDrei große Trends und die damit verbundenen diese Anforderungen über den EntwicklungsprozessHerausorderungen 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 zudie 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 desRequirements-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 ausreichendIndustriestudien zum Thema Requirements-Engin- beherrscht. Änderungsraten von 2–3% pro Monat [13] sindeering (RE) zeigen auf, wie stark der Einfluss von nicht untypisch.RE auf den Projekterfolg ist. So weist der StandishReport [9, 30] nach, dass mehr als 50% der ,,Schlüs- Industrielle Programmeselfaktoren“ 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 identifiziertengers und Gottesdiener schätzen, dass 40% bis 60% Schwachstellen im Requirements-Engineering zualler 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. InnerhalbKostenreduktion führt. Barry Boehm hat bereits von Siemens ist Siemens Corporate Research fürdarauf hingewiesen, dass Fehlerkorrekturen in die Ausgestaltung des Requirements-Engineering-den frühen Phasen 50 bis 200 mal billiger sind als Programms verantwortlich. Es ist organisatorischwenn das Produkt im Feld ist [4]. Steve McConnell mit dem unternehmensweiten top+ Programmermittelte 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 die75% aller Unternehmen nur sehr mangelhaft durch- Mitarbeiter.geführt wird [19, 20]. Seine Ergebnisse machendeutlich, dass ein großes Verbesserungspotenzial Das Programm ist auf sechs Säulen aufgebautvorhanden ist. Aufbauend auf seine Kategorisie- (s. Abb. 2), um obige Zielsetzung auch umfassendrung 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 automatisierbaresverifikation. 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 zusehen sind, wie Methoden der strukturierten Ana- beschreiben, zum anderen um Modelle, die stärkerlyse, die bereits auch diagrammatische Techniken auf Architekturen ausgerichtet sind und in einemeinsetzten, um Anforderungsanalyse zu betreiben. Zusammenhang zu nichtfunktionalen Anforderun-In einem umfassenden Sinn wurde das Thema gen zu sehen sind, aber auch um weiterführendeRequirements-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ügendpragmatische Ansätze zur systematischen Analyse bearbeitet sind.und Erarbeitung von Anforderungen. Die wissen-schaftlichen Gruppierungen zum Thema formaler AusgangspunktMethoden 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 formalenLaufe 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 mitformalen 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 umfasstments-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 zeigtformaler Methoden sind und heute in der Praxis die Systembeschreibungsmodelle des Werkzeugesstä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 eingebetteterAbb. 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 ParadigmenSomit hat das Requirements-Engineering eine der integrierten Anforderungsanalyse und System-zentrale Rolle in der Produktdefinition und Ent- definition gestaltet:wicklung. Die erarbeiteten Spezifikationsartefaktesind die Basis für Produktdesignentscheidung · ziel- und nutzerorientierte Analyse und Verfeinerung vonund Projektmanagement während des gesamten Anforderungen und funktionalen Entwurfskonzepten,Produktlebenszyklus. Die Qualität und Angemes- · Analyse und Verfeinerung von ,,high-level“ funktionalensenheit 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 undREM strukturiert und gibt Vorgaben für die · qualitative Überarbeitung erarbeiteter Spezifikationen aufAnforderungsanalyse- und Systementwurfsak- Basis definierter Beziehungen zwischen verschiedenentivitäten mittels eines grundlegenden Modells von Klassen von Anforderungen und Systemmodellen (RE-Requirements–Engineering-Spezifikationspro- Artefakten) des Artefaktmodells. Diese Abhängigkeitendukten – 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 undStruktur. Es unterteilt die zu erarbeitenden An- Validierung erstellter Systemanforderungen genutztforderungen (RE-Artefakte) in die Gruppen werden.Business-Needs, Requirements-Specification undSystem-Specification. Die Artefakte mit ihren defi- Entsprechend dieser methodischen Konzepte ist dienierten 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-ArtefakteMithilfe dieser Artefakte werden die Ziele und Vor- Annahmen (Assumptions & Dependencies) und Constraintsgaben der Business-Needs-Artefakte aus Kunden- (Design-Constraints) und bilden diese auf die detailliertenund Nutzersicht analysiert, strukturiert und detail- Anforderungen der System-Specification ab.lierte Anforderungen und Qualitätsvorgaben an das · Acceptance-Criteria spezifizieren die Abnahme- undNutzungserhalten 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 Spezifikationsdokumentenvom der jeweils gewählten Prozessstrategie, z.B. · Prozessstrategie – Entscheiden über die Prozessstrategieeiner agilen, komponenten-orientierten oder eher und Festlegen der Reihenfolge in der die RE-Artefakte zutraditionellen 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 ineinanderim Requirements-Engineering zu. Prototyping kann greifen. Für den praktischen Einsatz von REM sindinsbesondere bei vagen Anforderungen und hoch Instanzen zu bilden, die auch die Wahl speziellerinnovativen 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 dasArtefakte in das Referenzmodell integriert werden, Requirements-Engineering. Die Bildung spezifischerist 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ünchennicht im Fokus dieser Arbeit. und bei Siemens Corporate Research Princeton. Zur Werkzeugunterstützung von REM gibt es Verschiedene Formen der Anwendung bieteneinen 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 anstehendeum das von der TUM entwickelte Requirements- Requirements-Engineering-Projekte, als Bewer-Management und Systemspezifikationswerkzeug tungswerkzeug für laufende oder abgeschlosseneAutoRAID/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, undreicht haben. Das entwickelte Referenzmodell Metriken zur Bewertung der Qualität der Anforde-für Requirements-Engineering (REM) ist ein rungen und der Anforderungsprozesse) aufgedeckterster wichtiger Schritt um sich das Thema des und behoben oder sogar frühzeitig vermiedenRequirements-Engineering durch Systematisierung werden.stärker zu erschließen. Es dient zum Absteckender Bestandteile eines umfassenden Requirements- LiteraturEngineering-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 Generationwird – und zwar für Forschung und die industri- and Simulation: http://www4../∼af2 (2006) 3. Berenbach, B.: Requirements Engineering Checklist. Siemens Corporate Researchelle 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 FormalDamit 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 Systemaktuellen Form naturgemäß nicht beantwortet und Development. Wiley & Sons (1995) 9. Chaos Report 2001: http://www.projectsmart.co.uk/docs/chaos_report.pdfviele 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ändeweiter 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)