{ HAUPTBEITRAG / DER BAZAR DER ANFORDERUNGEN

Der Bazar der AnforderungenOpen Innovation in emergenten Communities

Ralf Klamma · Matthias JarkeAnna Hannemann · Dominik Renzel

EinleitungTraditionelle Informationssysteme sind aufOrganisationen ausgelegt. Die Basis für das An-forderungsmanagement ist damit durch dieStrukturen und Grenzen der Organisation bestimmt.Organisationsübergreifende Arbeitsteilung und Glo-balisierung, aber auch technische Entwicklungenwie serviceorientierte oder gar Cloud-orientierte Ar-chitekturen verändern diese Situation grundlegend.Informationsdienste werden unternehmensüber-greifend, geographisch verteilt und zunehmendauch mobil genutzt. Ihre Basisfunktionalitäten sinddaher mit ständig wechselnden Kontexten zu an-wendbaren Lösungselementen und Teilprozessen zuverknüpfen. Die Adaption im Systemgebrauch, aberauch die Systemevolution über längere Zeiträumehinweg wird durch die Nutzung in solchen über-greifenden Kontexten bestimmt. Die Entscheidungdarüber obliegt nicht mehr fixierten Organisations-strukturen, sondern ,,Communities“ interessierterund engagierter Nutzer und sonstiger Stakeholderaus oftmals vielen organisatorischen oder privatenKontexten. Bewusst will man die Innovationsideender Nutzergemeinde in die Weiterentwicklung ein-beziehen. In der Literatur werden derartige Prozesseunter dem Schlagwort ,,Innovation at the Edge“ [1]oder ,,Open Innovation“ diskutiert [2, 3].

Zwei Fallstudien aus den Bereichen der Bioin-formatik und des E-Learnings sollen die zum Teilstark differierenden Praktiken heutiger Zusammen-arbeit von Entwicklern und Endnutzern in solcheProzessen kurz darlegen.

Eine von uns durchgeführte Studie [4] zurStruktur und Entwicklung dreier Entwickler-Communities im Bereich der Bioinformatik (http://

biojava.org, http://bioperl.org, http://biopython.org)in Anlehnung an [5, 6] bot Einblicke in die Kommu-nikation und die Arbeitsweise dieser Communities.Die Datenbasis unserer Untersuchungen bildetendabei Archive von Mailinglisten der jeweiligen Com-munities über einen Zeitraum von 10 Jahren seitihrer Entstehung. Mithilfe von speziellen Craw-lern konnten über 5000 Kontakte und über 50.000Nachrichten extrahiert, bereinigt und zu einemdynamischen sozialen Netzwerk zusammengefügtwerden. Mithilfe der Kombination von Algorithmenzur Trennung einzelner Communities [7] und dermanuellen Untersuchung von Kommunikationsin-halten nach jeweiligen Aktivitäten zur Identifikationkonnte gezeigt werden, dass sowohl Entwickler alsauch Endnutzer die gleichen Kommunikations-kanäle nutzen (in diesem Falle Mailinglisten), aberdass Kommunikation zwischen den Gruppen meistüber wenige sog. Boundary Spanner erfolgt, dasseine Zunahme der Anzahl der Boundary Spanner zuverkürzten Zeiträumen zwischen Releases beitrug,dass Endnutzer weitaus weniger dicht miteinandervernetzt sind als Entwickler und dass die Kommu-

DOI 10.1007/s00287-010-0516-5© Springer-Verlag 2011

Ralf Klamma · Matthias Jarke · Anna HannemannDominik RenzelInformationssysteme & Datenbanken,Rheinisch-Westfälische Technische Hochschule Aachen,Ahornstr. 55, 52074 AachenE-Mail: {klamma, jarke, hannemann, renzel}@dbis.rwth-aachen.de

Matthias JarkeFraunhofer-Gesellschaft zur Förderungder angewandten Forschung e.V.,Fraunhofer Institute for Applied Information Technology FIT,Schloss Birlinghoven, 53754 Sankt AugustinE-Mail: jarke@fit.fraunhofer.de

178 Informatik_Spektrum_34_2_2011

ZusammenfassungTraditionelles Requirements Engineering istauf die Ermittlung, Festschreibung und Nach-vollziehbarkeit von Anforderungen in denInformationssystemen einer Organisationfokussiert. Die fortschreitende Globalisie-rung und Vernetzung hat neue Formen derZusammenarbeit und der informationstech-nischen Unterstützung hervorgebracht. AufBasis von zwei Fallstudien zu offenen Innova-tionsprozessen haben wir die Anforderungenan ein adaptives Requirements Engineeringfür emergente Communities ermittelt. Zurinformatischen Unterstützung haben wir eini*-Modell für die Beschreibung der wechselseiti-gen Abhängigkeiten zwischen den Communitiesund den von ihnen genutzten Informations-systemen aus der Sichtweise des adaptiven REentwickelt. Wir unterstützen das adaptive REdurch einen Dienstbaukasten, der in die zuentwickelnden Informationssysteme integriertwerden kann. Dadurch entsteht im Sinne derOpen-Source-Bewegung ein Bazar von Anforde-rungen. Diesen Vorgang haben wir prototypischin einen Store für webbasierte Widgets zur Ge-staltung von personalisierten Lernumgebungenumgesetzt.

nikationsweisen von Endnutzern und Entwicklernklar voneinander unterscheidbar sind.

Etwas anders haben sich die Communities imBereich des E-Learning entwickelt. Hier repräsen-tieren personalisierte Lernumgebungen (engl.: per-sonal learning environments oder PLE) informatischdie zunehmende Unterstützung informeller Lernsi-tuationen, beispielsweise beim lebenslangen Lernenaußerhalb spezieller Lerninstitutionen. Entspre-chend haben sich schnell um die von Entwicklernzur Verfügung gestellten Technologien Tausendevon Communities mit entsprechend heterogenenLernzielen entwickelt [8, 9]. Alle eint der Anspruch,sich ihre persönlichen Lernumgebung aus gege-benen Diensten – zumeist aus dem Kontext desWeb 2.0 [10] und der Open-Source-Bewegung –entsprechend ihren eigenen Vorstellungen zusam-menstellen zu wollen. Kommunikation zwischenLernenden (Endbenutzern) und Entwicklern findetmittels verschiedenster Kommunikationswerkzeuge

des Web 2.0 wie etwa Twitter (http://twitter.com),Facebook (http://facebook.com), verschiedener In-stant Messenger wie Skype (http://skype.com) etc.oder mittels direkter Feedback-Mechanismen in denLernwerkzeugen selbst statt.

Diese Beispiele zeigen das Potenzial eines An-satzes zum Anforderungsmanagement auf, dersystematisch in eine emergente Benutzergemeindeintegriert ist. Aus Sicht des traditionellen Anforde-rungsmanagements haben sie jedoch auch deutlicheSchwächen, weil eine systematische Struktur zurErfassung und Priorisierung, welche Anforderun-gen bevorzugt umgesetzt werden sollten, ebensofehlt wie eine Nachvollziehbarkeit (Traceability [11]),welche Anforderungen eigentlich umgesetzt wordensind und wie dies geschehen ist. Weiterhin mussdie Kommunikation zwischen Entwicklern undEndnutzern gestärkt werden, um einen besserenAbgleich zwischen Bedürfnissen und tatsächlichenProduktentwicklungen zu erreichen.

In dieser Arbeit gehen wir entsprechend derFrage nach, wie die Mitglieder der Communitiesin die Lage versetzt werden können, sich flexibelund strukturiert zur Weiterentwicklung ihrer Sys-temlandschaft äußern zu können [12]. Schließlichist es notwendig, dass Communitymitglieder sichnicht nur äußern können, sondern dass geäußerteAnforderungen auch umgesetzt werden. Hier be-steht eine wechselseitige Interessenabhängigkeitzwischen Endnutzern und Entwicklern. Endnutzeräußern ihre Anforderungen, tun dies aber nur, wennsie auch die Chance sehen, dass ihre Stimme vonEntwicklern gehört wird. Im anderen Falle drohtsogar die Abwanderung aus der entsprechendenCommunity [13]. Entwickler vertreten wiederumden Anspruch, größtmöglichen Nutzen und Verbrei-tung ihrer Arbeit zu erwirken, etwa aus monetärenoder Image-Interessen. Die Ziele beider Gruppenkönnen nur dann erreicht werden, wenn diese wech-selseitigen Abhängigkeiten entsprechend sichtbargemacht und bedient werden. Weiterhin sollen dieso entstandenen Anforderungen gut verständlichund nachhaltig dokumentiert werden, beispiels-weise um neuen Benutzern beim Einstieg in dieCommunity zu helfen und der gesamten Communitydie Nachvollziehbarkeit zu sichern.

Nach einem kurzen Literaturüberblick der bis-herigen Softwareunterstützung für Open Innovationidentifizieren wir anhand von Beobachtungen in denoben genannten Anwendungsbereichen typische

Informatik_Spektrum_34_2_2011 179

{ DER BAZAR DER ANFORDERUNGEN

AbstractTraditional Requirements Engineering is fo-

cused on the identification, persistence, andtraceability of requirements in organizationalinformation systems. Progressing globaliza-tion and networking has spawned new formsof collaboration in information technology sup-port. Based on two case studies we identifiedrequirements to an adaptive form of Require-ments Engineering for emergent communities.We developed an i* model for the descriptionof mutual dependencies among communitiesand the information systems they use fromthe perspective of an adaptive RE. We supportadaptive RE by a service toolkit, which can beintegrated into arbitrary information systemsto be developed. Thus, a bazaar of require-ments emerges in the spirit of the open sourcemovement. We have prototypically realized thisprocess in a store for web-based widgets for thecreation of personalized learning environments.

Muster von Adaptionsprozessen. Diese werden dannin einer gemeinsamen Grundstruktur mittels derModellierungssprache i* formalisiert. Zur konkre-ten Unterstützung im organisationsübergreifendenKontext schlagen wir das Konzept eines ,,RE Bazars“vor, einer Sammlung traditioneller und innovativerRE-Dienste zur Unterstützung des adaptiven Com-munity Requirements Engineering. Wir beschreibeneine prototypische Umsetzung und schließen miteiner Anwendungsfallstudie zur Validierung diesesKonzepts.

Open Innovation: State-of-the-ArtDie klassischen Ansätze des Anforderungsmanage-ments (Requirements Engineering, RE) basieren aufstrukturierten und formal beschriebenen Anfor-derungen bestimmter Stakeholder-Gruppen (z. B.Manager, Entwickler, Endbenutzer etc.). Seit langerZeit betonen Wissenschaftler die Wichtigkeit ei-nes partizipativen Prozesses für die Identifikationvon Anforderungen und somit für den Projekt-erfolg [14]. Von Hippel et al. belegen klar, dass dieMiteinbeziehung von Produktnutzern in den Inno-vationsprozess in Bezug auf Produktverbesserungenoder die Entwicklung neuer Produkte in klaren Wett-bewerbsvorteilen resultiert. Während traditionelle

Marktanalysen zufällige Nutzergruppen auswählen,zielt von Hippels Ansatz auf die Gruppe der Lead-User ab, d. h. die Gruppe von Nutzern, deren heutigeAnforderungen aufgrund ihrer Expertise in derNutzung aktueller Produkte in der Zukunft ho-hes Potential zur Markteinführung neuer Produktebieten; betont wird, dass die Identifikation von Lead-Usern eine Herausforderung darstellt [15]. In einerVergleichsstudie in Kooperation mit der traditio-nell innovationsfreudigen Firma 3M konnte gezeigtwerden, dass der Lead-User-Ansatz im Vergleichzu traditionellen Projekten zu einem deutlich er-höhten Anteil erfolgreicher neuer Produktlinienund somit im Falle von 3M in einer Verachtfachungder jährlichen Umsätze resultieren kann [16]. AmBeispiel der Entwicklung kontextadaptiver Anwen-dungen dokumentieren Sitou und Spanfelner, dassadaptives Systemverhalten den Nutzererwartungenoft nicht entspricht, wenn der Nutzer nicht in denEntwicklungsprozess einbezogen ist [17]. Daher istdie Organisation eines RE-Prozesses zur Analysevon Systemverhalten und -adaption beginnend beimNutzer als Mitglied einer oder mehrerer Communi-ties von enormer Bedeutung. Wird ein System durcheine Community genutzt, so muss auch der RE-Pro-zess communityorientiert organisiert werden.

Weiterhin erkennen Firmen zunehmend, dassInnovationsentwicklung nicht mehr vollständigund isoliert in den eigenen Entwicklungslaborenstattfinden sollte. Vielmehr sollten Erkenntnisseaus externer Forschung in eigene Entwicklungintegriert (Outside-In-Prozesse) und eigene Ent-wicklungsfortschritte veräußert werden. Dadurchwird einerseits die ständige Neuerfindung desRads vermieden und andererseits werden Ent-wicklungsfortschritte schon in frühen Stadien fürpotentiell interessierte Kunden zur Sicherung deseigenen Wissens und somit des Wettbewerbsvorteilssichtbar gemacht. Von Seiten der Wirtschaftswis-senschaften beschreibt Chesbrough diese Sichtweiseals Open Innovation [2], insbesondere in Verbin-dung mit von Hippels Lead-User-Ansatz. VieleUnternehmen haben Open Innovation bereitsin ihre Firmenkultur integriert und stellen zurKommunikation Web 2.0-Plattformen bereit (z. B.IBM https://www.collaborationjam.com/ und SAPhttp://www.sapiens.info/). Ähnliches gilt in derOpen-Source-Softwareentwicklung [18]. Allerdingssind die Motivationen der Teilnahme von Mitglie-dern aus der Open-Source-Szene durch das Fehlen

180 Informatik_Spektrum_34_2_2011

direkter monetärer Anreize anders als in kommer-ziellen Umgebungen, aber trotzdem gegeben [19].Diese Motivation sollte auch von kommerziellenUnternehmen nicht unterschätzt werden [20].

Meist beinhalten die durch Communitymit-glieder generierten Beiträge neben Innovationsvor-schlägen oder Fehlerberichten auch einen beträcht-lichen Anteil an ,,Kommunikationsrauschen“ [21].Zudem betont Cox, basierend auf seiner Erfahrungin der Open-Source-Entwicklung, im Gegensatz zuvon Hippel die Wichtigkeit, gerade auch peripherenNutzern zuzuhören. Das Informationsmanagement-problem, die Analyse sozio-technischer Strukturender Community und die Adaption an den aktu-ellen Communityzustand sind daher zusätzlicheAnforderungen an das communityorientierte RE.

Michaelides und Kehoe [22] untersuchen Ent-wicklungsprozesse von Informationssystemen (IS)für wissenschaftliche Onlinecommunities. Um dieCommunitymitglieder in das Systemdesign unddie Evaluierung zu involvieren, wird zunächst einSystemprototyp erstellt, der anschließend durchMitglieder der Community getestet und bewertetwird; ähnlich der Idee des ,,perpetual beta“ aus demWeb 2.0. Dabei werden sowohl die Umfragen alsauch die Optionen im Bewertungsbogen durch dasEntwicklerteam festgelegt. Dieser Ansatz löst dasInformationsmanagementproblem, gibt aber denteilnehmenden Mitgliedern keine Möglichkeit, neueIdeen über die vorgesehenen Optionen hinaus in denRE-Prozess einzubringen.

Lohmann et al. [23] stellen eine wikibasierteWebplattform für soziales RE vor. Jedes Commu-nitymitglied kann neue Anforderungen anlegen, dieexistierenden ändern oder diskutieren, und auchAbhängigkeiten zwischen Anforderungen im Sys-tem vermerken. Das System unterstützt sozialesFeedback durch Kommentar, Rating und Stimm-abgabe. Um Mehrdeutigkeit und unterschiedlicheInterpretationen der Annotationen zu vermeiden,bietet das System den Nutzern die Möglichkeit an,eine Beschreibung für jeden XML-Tag zu erfassen.Durch automatischen Vergleich werden ähnlicheBegriffe und somit auch die Beiträge zusammen-geführt. Einen wikibasierten Ansatz schlagen auchDecker et al. [24] für partizipatives RE in verteil-ten Communities vor. Um die Anforderungen zuformalisieren, werden Anforderungsformulare,Klassifikationstabellen und Gruppierungsregelnangewendet.

Heß et al. [25] berichten über die weitestgehenderfolgreiche Erprobung eines communitygetrie-benen Ansatzes für den gesamten Entwicklungs-prozess einer TV-Plattform. Durch die Einführungorganisatorischer Steuerwerkzeuge wie eines Par-laments und Zentralkomitees jeweils gebildet ausBenutzern, professionellen Entwicklern und Pro-jektleitern sollte die oft vorherrschende Vormachtder Entwickler und Projektleiter zugunsten der End-nutzer künstlich durch geringere Repräsentationin den Gremien abgeschwächt werden. Entschei-dungen über Anforderungspriorisierung wurdenausschließlich innerhalb der Gremien getroffen.Kritik an diesem Ansatz kam vornehmlich ausden Reihen der Nichtmitglieder und umfasste diefehlende Nachvollziehbarkeit auf Basis von Zugangs-beschränkungen auf gremieneigene Dokumenteund eine daraus resultierende Frustration, ungenü-gend in Ideen- und Entscheidungsfindungsprozesseeingebunden zu sein (vgl. [13]). Weiterhin war dieNachvollziehbarkeit durch die Nutzung verschiede-ner nicht miteinander synchronisierter und teilweiseunübersichtlicher Medien (Forum und Wiki) negativbeeinträchtigt.

Auch textbasierte Diskussionsforen könnenfür die Anforderungserhebung in globalen Ent-wicklungsumgebungen eingesetzt werden [26]. DieVerwaltung von Anforderungen ist durch eine Kom-bination von Textmining und Klassifikation vongesammelten Foreneinträgen realisiert. Jedoch be-nötigt dieser Ansatz 50–100 vordefinierte und bereitsklassifizierte Anforderungen, damit das Clusteringvon neuen Beiträgen stattfinden kann.

Aus Sicht der oben beschriebenen Fallstudienbieten all diese Ansätze lediglich einen medialenRahmen zur Kommunikation und zum Austauschvon Informationen. Ihnen fehlen jedoch ein ge-eignetes konzeptionelles Gesamtverständnis desmediengestützten Adaptions- und Evolutionspro-zesses, und damit eine wenigstens grob-granulareprozessorientierte Unterstützung der Anforde-rungsanalyse und Innovationsabläufe. Zudem sinddie eingesetzten Softwarewerkzeuge jeweils vorbe-stimmt und somit ist das Unterstützungsangebotbezogen auf genutzte Medien, Modalitäten und Er-fassungskontexte immer noch wenig flexibel. Derim Folgenden beschriebene Lösungsansatz dient derBeseitigung dieser Defizite. Insbesondere gilt unserAugenmerk hier der Unterstützung beim Aufbauvon sich selbst tragenden und nachhaltig existie-

Informatik_Spektrum_34_2_2011 181

{ DER BAZAR DER ANFORDERUNGEN

Abb. 1 Adaptionsmodell

renden Communities rund um die Nutzung undEntwicklung von Informationssystemen. Nach unse-rer Auffassung ist die strukturiert nachvollziehbareund nachhaltige Kommunikation zwischen Endnut-zern und Entwicklern ein zentraler Faktor bzgl. derkontinuierlichen Verbesserung und des Wachstumsder Systeme.

Adaptive-Requirements-Engineering-Modelle für Communities

Unsere einleitend skizzierten Beobachtungen vonCommunities u. a. in Bioinformatik und E-Learningergaben bei aller Unterschiedlichkeit folgendeGemeinsamkeiten in den Unterstützungsanforde-rungen, die von den bisherigen Lösungsansätzennoch kaum erfüllt werden:

Zum einen entstehen typischerweise raschklar unterscheidbare Subcommunities aus ver-schiedenen Endbenutzerklassen (Lead User, PowerUser, Early Adopter, Boundary Spanner usw.) undEntwicklern (Open-Source-Entwickler, kommer-zielle Entwickler usw.). Daher ist es möglich undsinnvoll, durch strukturanalytische Methoden dieemergenten sozialen Strukturen zu erfassen undzu verstehen. Communities identifizieren sichselbst vielmehr durch ihren sozialen als durch ih-ren organisational-institutionellen Kontext. ZurAnalyse dieser sozialen Kontexte und Strukturenkönnen die persistenten kommunikativen Akte derCommunities herangezogen werden. Zum ande-ren äußern sich die Communities auf verschiedeneWeisen über ihre Bedürfnisse an die Informations-technologie und brauchen damit eine fortlaufendeAnforderungsanalyse. Durch die inhaltliche Ana-lyse der Kommunikationsakte der Communitieskönnen eine Unzahl von implizit und explizit geäu-ßerten Anforderungen an das zukünftige Verhaltender Communityinformationssysteme ermittelt(vgl. [27–29]) und mittels der strukturellen Ana-lyse gewichtet werden. Noch mehr Information kann

mittels der Analyse der aktuellen Systembenutzunghinzugefügt werden.

Zusammengenommen ergeben sich daraus neueMöglichkeiten, Communityinformationssystemeauf Anforderungsebene zu adaptieren. Diese Adap-tionen können teilweise einen erheblichen zeitlichenHorizont haben, sind aber aufgrund der oft erstaun-lich breiten Diskussion in der Community weitausnachhaltiger als Adaptionen des Systemverhaltens,die auf der Nutzungs- oder Entwurfsebene durch-geführt werden. Wegen der Bedeutsamkeit dieserAdaptionen sind für die Communities Werkzeugevon Vorteil, die es ihnen erlauben, ihre Anfor-derungen besser zu äußern, zu dokumentierenund mit den Entwicklern zu kommunizieren. DieQualität dieser Prozesse bestimmt in letzter Kon-sequenz die Qualität der Communityinformations-systeme.

Unser Ansatz geht von einem kontinuierlichenWechselspiel zwischen der Community – insbe-sondere Endnutzern und Entwicklern – und ihrenSystemen einerseits, sowie zwischen ihrem jeweili-gen Gesamtkontext und den Systemanforderungenandererseits aus, wie in Abb. 1 zusammengefasst.Kollaboration in Communities hat eine kontinuier-liche Veränderung der Community selbst (Struktur,Rollenverteilung, etc.) und der Systemanforderun-gen zur Folge. Aus diesem Grund wird eine ständigeAdaption und Koevolution von Wissensmodellen,Kollaborationsprozessen, Medien und Unterstüt-zungsmechanismen an die sich weiterentwickelndenBedürfnisse von Communitymitgliedern erforder-lich. Da der RE-Prozess selbst Teil der Kollaborationist, muss auch hier die Adaption an die aktuelleSituation stattfinden. Die Community als Kontexterfährt eine kontinuierliche Weiterentwicklung. DieAnforderungen der Mitglieder definieren die Ge-staltung des Kollaborationsprozesses. Außerdemist der Verlauf des Kollaborationsprozesses auchvom aktuellen Zustand der Community abhängig.

182 Informatik_Spektrum_34_2_2011

Abb. 2 i*-Modell für Community-orientiertes RE

Somit erfolgt Adaption der Kollaborationsdiensteentsprechend der Communityanforderungen.

Dieses Adaptionsmodell, das den RE-Prozessdefiniert, soll auch an die aktuelle Situation ange-passt werden. Dabei ergibt sich der Kontext aus einerKombination der Änderungen in Community, Kolla-borationsprozess und RE-Aktivitäten. Basierend aufdiesen drei Dimensionen kann ebenfalls der gesamteAdaptionsprozess verändert werden. Dieser Anpas-sungsschritt ist durch die äußere Schleife in Abb. 1dargestellt. Um die beiden Adaptionsschritte zu rea-lisieren wird ein Prozessansatz benötigt, der dascommunityorientierte RE, aber auch Analyse, Mes-sungen und Monitoring von Communityaktivitätenund Artefakten ermöglicht.

Als Vorbereitung einer informatischen Unter-stützung eines solchen Prozessansatzes erscheintes sinnvoll, diesen in einem geeigneten Modellie-rungsansatz zumindest semiformal zu erfassen. DieModellierungssprache i* [30] ist dafür besondersgeeignet, denn sie ermöglicht die Beschreibungstrategischer Ziele und Abhängigkeiten zwischenAkteuren eines soziotechnischen Systems [31], die inForm von (menschlichen oder technischen) Agen-ten dargestellt werden. Hierbei sei erwähnt, dass

der primäre Einsatzzweck von i* nicht die Prozess-modellierung ist, auch wenn die Modellierung vonAbhängigkeiten oft Teile eines Prozesses andeu-tet. i* modelliert Agenten als benannte Kreise, diemit Darstellungen der Zielhierarchie der Agentengefüllt sind. Zwischen den Agenten bestehen Ab-hängigkeiten verschiedenen Typs, die im Modelldurch Rechtecke (Abhängigkeit bzgl. Erfüllung einerAufgabe) bzw. sechseckige Rauten (Abhängigkeitbzgl. Verfügbarkeit einer Ressource) dargestellt sind.Dabei wird die Richtung der Abhängigkeit durchhalbrunde Pfeilspitzen auf den Kanten dargestellt,die zu Abhängigkeitsobjekten bzw. von ihnen wegauf andere Objekte zeigen.

Die Ausarbeitung des in Abb. 1 gezeigten Grund-modells erfolgte auf Basis von Erfahrungen in denoben skizzierten Fallstudien sowie in zahlreicheneigenen Softwareprojekten zur Community-unterstützung [32, 33]. Das in Abb. 2 gezeigteModell [34] beinhaltet zwei Haupt-Agententypen:eine Community of Practice (CoP) [35] und das vonihren Mitgliedern verwendete Soziale Softwaresys-tem. Letzteres stellt eine Sammlung verschiedenerCoP-Dienste zur Verfügung, wobei hier nur die fürden RE-Prozess relevanten Dienste gezeigt sind.

Informatik_Spektrum_34_2_2011 183

{ DER BAZAR DER ANFORDERUNGEN

Die soziale Software wird durch die Communityals Kommunikations- und Kollaborationsmediumverwendet, was zum Entstehen eines Repositoryführt. Dessen Artefakte spiegeln das Verhalten derCommunitymitglieder wider. Durch das Zusam-menspiel aller Mitglieder in ihren Rollen entstehtauf Dauer eine CoP. Die Grundidee des RE-Prozessesist eine Kombination von impliziten und explizi-ten Anforderungen. Hinreichender Einblick in dieimpliziten Anforderungen einer Community (Kon-flikte, Probleme, Veränderungen etc.) wird durchAnalysetechniken gewährleistet, die durch ent-sprechende Dienste zur CoP-Anforderungsanalyserealisiert werden. Diese Techniken arbeiten aufBasis von CoP-produzierten Artefakten sowie derNutzung des Systems, die durch entsprechende CoP-Monitoringdienste aufgezeichnet werden. Außerihrem direkten Anwendungszweck für das REerzeugen Visualisierungen der Resultate dieser Ana-lysetechniken ein erhöhtes Bewusstsein für Vorgängeinnerhalb einzelner oder mehrerer Communities.Beispielsweise bieten die Resultate der CoP-Sozialen-Netzwerkanalyse die unverzichtbare Unterstützungvon Newcomern, auf einfache Weise in bereitsetablierte CoPs einsteigen zu können. Durch dieVisualisierung der Netzwerkstruktur sowie der Posi-tionen seiner Mitglieder erhält ein Neuankömmlingbereits wertvolle Informationen über die Commu-nity, um nach [36] schneller aus der Peripherie dieserCommunity tiefer in deren Kern zu gelangen und imZuge dessen die Bedürfnisse und Praktiken besserkennenzulernen und später selbst innovative An-forderungen zu generieren oder gar umzusetzen.Weiterhin sollten die SNA-Resultate in die Ermitt-lung einer Anforderungspriorisierung einfließen, dieein zentrales Hilfsmittel für Entwickler zur Entschei-dung über die Anforderungsrealisierung darstellt.Die darunterliegende Intuition ist die folgende: An-forderungen, die eine große Zahl von Unterstützern –insbesondere Lead-Usern und Entwicklern – in regerKommunikation um sich scharen werden in der Regelden Anforderungen vorgezogen, die unter Umstän-den nur von einer weitestgehend unbekannten undwenig vernetzten Person geäußert, aber nicht weitervon anderen unterstützt wurden.

Communitymitglieder erhalten zudem die Mög-lichkeit zur expliziten Äußerung von Anforderungen.Hierzu wird der Community ein RE-Medium mittelsDiensten zur Anforderungserhebung angeboten. Da-bei kann eine große und unübersichtliche Menge von

Anforderungen entstehen. Um diese Anforderun-gen weiter zu bewerten und einzuordnen, wird einzusätzlicher Service zur Unterstützung der Entschei-dung über Anforderungsrealisierungen angeboten,der eine CoP-spezifische Ermittlung einer Anforde-rungspriorisierung auf Basis der Analyseergebnisseumfasst. Die Analyseergebnisse werden für dieCommunitymitglieder visualisiert. So werden dieAnforderungen von der Community inklusive ihrerPeripherie für alle Mitglieder sichtbar und bewert-bar und somit Entscheidungsfindungsprozesse inder Community unterstützt. Die Akzeptanz von An-passungen wird somit erhöht. Das i*-Modell des REfür emergente Communities verbindet also Dienstefür den Wissensaustausch mit Diensten zur Analysevon sozialer Struktur und Systemnutzung, erweitertdurch Dienste zur Bewertung, Visualisierung undPriorisierung von Anforderungen.

Ein Dienstebaukasten für das REDie wesentliche Idee des Dienstebaukastens fürdas RE besteht darin, eine Sammlung von Un-terstützungsdiensten für die in Abb. 2 genanntenProzesse innerhalb der Community anzubieten.Da der Gedanke der Dienstorientierung und desRE verbunden werden, werden im Laufe der Zeitbestehende serviceorientierte Architekturen mitdiesen existierenden oder gar standardisiertenDiensten zur Ermittlung, Analyse und Beobach-tung von RE-Prozessen integriert. Der RE-Prozesswird – da er verteilt und emergent stattfindet –mit dem Informationssystem verwoben. Diesverschafft dem Paradigma einer reflektiven Infor-mationssystemarchitektur [37] Geltung. Für unserenDienstebaukasten haben wir den Lightweight Ap-plication Server (LAS) unserer ATLAS-Umgebunggewählt [38]. Damit können wir die leicht erweiter-bare Sammlung von RE-Unterstützungsdiensten imKontext eines leichtgewichtigen Anwendungsserversanbieten, der über communitygeeignete Sicherheits-konzepte verfügt. Für verschiedene RE-Aktivitätenwerden im Folgenden Beispiele realisierter Dienstein aller Kürze vorgestellt.

Dienste zur COP-Anforderungserhebung. In un-serem Ansatz ist das Erzählen von Geschichten einwesentliches Mittel für die Erhebung von Anforde-rungen, da es ein natürliches Medium für den schnel-len Austausch von Erfahrungen mit existierendenInformationssystemen darstellt, z. B. das gemeinsam

184 Informatik_Spektrum_34_2_2011

erlebte Ärgernis einer benutzerunfreundlich kon-struierten Anfragemaske. Die erzeugten Geschichteneignen sich zudem ausgezeichnet als Grundlagefür Trainingsmaterialien für Neueinsteiger in dieCommunities, z. B. warum eine bestimmte Funk-tionalität für eine Aufgabe benutzt werden soll.YouTell [39] stellt eine multimediale Umgebung zumgemeinsamen Erzählen solcher Geschichten zur Ver-fügung. Die Geschichten werden im Sinne des Web2.0 kommentiert, bewertet und diskutiert. Das ge-wählte Strukturparadigma [40] von Geschichtenermöglicht die Validierung von Geschichten gegenvon Nutzern ausgewählte Vorlagen. So kann auchungeübten Erzählern ein rascher Einstieg in die nar-rativen Strukturen des RE ermöglicht werden. DieGeschichten können entsprechend der Community,der Domänen, aber auch mittels willkürlich gewähl-ter struktureller (z. B. Pfade, Orts- und Zeitkontexte,Autoren) [41] oder inhaltlicher (z. B. Schlüsselwör-ter, Beschreibungen) Kriterien für die Analyse (s. u.)aufbereitet werden. Dienste wie youTell können fürdas RE einfach variiert werden, um den Spaß am REzu erhöhen. So haben wir einen Annotationsdienstfür Bilder, hier Bildschirmabzüge, entwickelt, deres Benutzern erlaubt, gemeinsam Sprechblasen miteigenen Texten (Kommentare und Anforderungen)in das Bild einzufügen. Diese einfachen, an Comicsorientierten Methoden des Erzählens von Geschich-ten haben Benutzer stark motiviert, sich aktiv in REProzesse einzubringen [32].

Dienste zum CoP-Anforderungsmonitoring. Die Be-obachtung von RE-Aktivitäten wird mittels des Mob-SOS Dienstes realisiert [42]. Dieser Dienst erlaubtdie Beobachtung von Interaktionen der Benutzermit den Diensten, aber auch die Interaktion von Be-nutzern untereinander auf der Ebene der in der Kom-munikation eingesetzten Protokolle. HTTP erlaubtz. B. die einfache Beobachtung von Anfragen an ei-nen Webserver, während XMPP weitere Kommuni-kationsakte zwischen Benutzern beobachtbar macht.

Dienste zur CoP-Anforderungsanalyse. Hierkönnen Analysemethoden wie die Statistische Nut-zungsanalyse oder die Soziale Netzwerk Analyse(SNA) eingesetzt werden. Während die Benutzungvon Diensten statistische Evidenzen über die Po-pularität und weiterführend über die Struktur vonDienstaufrufen schafft, kann die SNA mittels Zen-tralitätsmaßen [43] die Bedeutung des einzelnen

Nutzers in der Community bemessen und so Sta-tistiken verstärken oder entkräften. Als Beispielsei die Statistik eines Benutzeraccounts des CIOsgegeben, der von den Entwicklern seiner Firma alsgemeinsamer Testaccount verwendet wurde. Auf denersten Blick war man erstaunt, wie häufig dieser CIOdas System genutzt hatte. Erst durch die qualitativeAnalyse konnte eindeutig belegt werden, dass derentsprechende Nutzer das System niemals zu Kom-munikationszwecken verwendet hatte. Ein Umstand,den sich die Entwickler zu Nutze gemacht hatten,aber der durch das simple Erheben von Benutzungs-statistiken nur schwer zu ermitteln ist. Schon andieser kleinen Anekdote wird klar, dass jede Analy-setechnik für sich selbst nicht aussagekräftig genugist. Nur die Kombination verschiedener Techni-ken liefert ein umfassendes Bild. Weitere ernsthafteAnwendungen der Kombination der Analysemetho-den sind das Ermitteln von Lead- oder Powerusernmittels SNA (vgl. [44, 45]), deren Anforderungenaufgrund ihrer Domänenkenntnisse eine besondereWichtigkeit beigemessen werden kann. Zusammen-genommen mit den Feedbackmethoden, die schonin youTell eingefügt wurden, können diese Daten zumächtigen Analysewerkzeugen kombiniert werden,die das RE insgesamt erfolgreicher machen.

Dienste zur Entscheidungsunterstützung. Für deneinzelnen Benutzer stellt die Benutzung dieserDienste natürlich eine weitere kognitiv herausfor-dernde Tätigkeit dar, so dass wir alle diese Diensteim Rahmen einer communitybewussten Webober-fläche integriert haben [33], die möglichst viele derAufgaben der Teilhabe und der Beobachtung vonRE Aktivitäten in einer Community mittels gra-fischer Webelemente miteinander in Beziehungsetzt, ohne dass der Benutzer wesentliche Auf-gaben der Konfiguration und Verwaltung dieserBildschirmelemente übernehmen muss. Das ausdieser Vorarbeit resultierende communitybewussteDashboard wurde in der folgenden Designstudiedem Gedanken folgend weiterentwickelt, dass daseigentliche dienstleistungsorientierte System (per-sonalisierte Lernumgebung) schon eng mit demadaptiven RE-Prozess integriert wurde.

Designstudie: Ein RE-Bazarfür personalisierte Lernsoftware

Mit der Entstehung von Web-basierten perso-nalisierten Lernumgebungen (PLE) im Zuge der

Informatik_Spektrum_34_2_2011 185

{ DER BAZAR DER ANFORDERUNGEN

Etablierung von Web-2.0-Technologien haben sichTausende von heterogenen Lerngemeinschaftengebildet [8], deren individuelle Bedürfnisse nichtmehr traditionell über Anbieter von Learning-Management-Systemen (LMS), sondern durcheine Art Geschäft (engl.: Store) für einzelne Lern-dienste oder gar ganze Dienstbündel abgedecktwerden, die modular in Widget-basierte [46, 47] PLEá la iGoogle (http://google.com/ig) oder netvibes(http://netvibes.com) eingesetzt werden können.Widgets stellen dabei Bedienelemente für Web-2.0-Dienste dar, deren Funktionalität von ihrenAnbietern heutzutage meist über sogenannte Web-APIs (Application Programming Interfaces) zurVerfügung gestellt werden. Beispiele für Widgetsallgemeiner Natur sind webbasierte Kalender, Uh-ren und Mailklienten. Daneben finden sich speziellauf das Erlernen bestimmter Kompetenzen oderMetakompetenzen zugeschnittene Widgets. Ein Bei-spiel für eine Kompetenz ist die Beherrschung einerFremdsprache. Ein Vokabeltrainer Widget unter-stützt die Erlangung dieser Kompetenz. Ein Beispielfür ein Metakompetenz ist die Reflektion des eige-nen Lernprozesses. Ein entsprechendes Widget zurVisualisierung des Lernfortschritts unterstützt dieReflektion. Da auch das informelle Lernen geradeim Angesicht der zunehmenden Verbreitung vonInformations- und Kommunikationstechnologiennicht mehr von einzelnen Lernern allein, sondernzusammen mit anderen Lernern praktiziert wird,gehören zu webbasierten PLE auch Technologien,die das Verwalten einer Lerngemeinschaft reali-sieren, z. B. die informelle Selbstorganisation, diedirekte Kommunikation unter Lernern, aber auchdie entsprechenden Zugriffskontrollen in Bezugauf Authentifizierung und Autorisierung mittelsMechanismen wie OpenID [48] oder OAuth [49].Dazu kommt ein Interoperabilitäts- und Kommu-nikationsrahmenwerk, welches den Austausch vonDaten und Diensten zwischen verschieden webba-sierten PLE möglichst in Echtzeit erlaubt, da in PLEgenau wie in anderen fortgeschrittenen Web-2.0-Systemen mittlerweile alle bekannten synchronenKommunikationsformen erwartet werden [50].Wegen des informellen Charakters des Lernenswerden im Kontext von PLE zunehmend auch dieBedürfnisse nach Anleitung und Empfehlungenvon Lernmaterialien, Lerndiensten und anderenLernenden durch das zugrundeliegende Systemgeäußert.

Ausgehend vom großen Erfolg des AppleStores für iPhone Apps und seiner Akzeptanz beiden Nutzern liegt der Schritt zu einem Widget-Store nicht fern. Im Rahmen des EU-ProjektsROLE (Responsive Open Learning Environments;http://role-project.eu) wird auf Basis der im vorher-gehenden Abschnitt beschriebenen Umgebung undihrer Dienste ein ROLE-Store zur Unterstützung derBedürfnisse verschiedenster Lerngemeinschaftenentwickelt. In erster Linie dient der Store der Bereit-stellung und Bündelung von Diensten und Widgets,sodass PLEs im Gegensatz zu der heutigen Situationfür bestimmte Lernkonstellationen, z. B. den Erwerbeiner Fremdsprache in einer Kleingruppe, einfachdurch die Auswahl eines solchen Bündels erzeugtwerden können. Zum anderen dient der Store aberauch der Kommunikation zwischen Entwickler- undNutzercommunities. Das ROLE-Projekt setzt einenbesonderen Akzent auf die Zusammenbringung undgegenseitige Bedienung von Anforderungen derEndnutzer und Entwickler von Lerntechnologien,insbesondere Widget-basierter PLE.

In unserem Ansatz wenden wir das Storekonzeptnicht nur auf Produkte nach ihrer Fertigstellung,sondern bereits in frühen Stadien der Ideenfindungauf Produktanforderungen an. Dazu vereinen wirdas Storekonzept und unseren RE-Dienstebaukastenzu einem Bazar für das RE. Communities bestehendaus Endnutzern und Entwicklern entscheiden imSinne einer darwinistischen Auslese selbst überihre Feedback-, Verhandlungs- und Preisbildungs-mechanismen, welche Inhalte verfügbar sind undwelche nicht. So entsteht im Sinne der Open-Source-Tradition [18] ein RE-Bazar, in dessen RahmenAnforderungen als immaterielle Güter behandeltwerden. Güter aller Art werden zwar nach Katego-rien geordnet, aber am gleichen Platz angeboten.Der Preis der Güter wird üblicherweise in Verhand-lungen ermittelt. Es herrscht eine hohe Konkurrenzzwischen Anbietern ähnlicher Produkte. Oftmalsdarf der Kunde am Produktentstehungsprozess teil-haben: „Neben den Läden, wo nur verkauft wird,gibt es viele, vor denen man zusehen kann, wiedie Gegenstände erzeugt werden. So ist man vonAnfang an dabei, und das stimmt den Betrach-ter heiter.“ (vgl. [51], Die Suks). Die Rollen derTeilnehmer unseres RE-Bazars sind jedoch durchdie teils noch nicht gegebene Verfügbarkeit einesProduktes vorerst nicht durch die klassischen Rol-len der Anbieter und Kunden gegeben. Vielmehr

186 Informatik_Spektrum_34_2_2011

stellen alle Teilnehmer vorerst Interessenten dar,die den Bazar aus verschiedenen Motivationen(Produktfindung, Arbeitsfindung) besuchen undanalysieren, um später für Produkte oder Produkt-verbesserungen mit guter Aussicht auf Markterfolgauf die Seite der Mitentwickler und Anbieter vonAnforderungsumsetzungen zu wechseln.

Die einzelnen Prozessbausteine des in Abb. 2illustrierten i*-Modells können durch vielfältige undunterschiedliche Dienstbausteine aus unterschied-lichsten Quellen unterstützt werden. Diese Bausteinemüssen jedoch im Sinne eines kohärenten und nach-vollziehbaren RE-Prozesses nicht nur rein technisch,sondern auch praktisch im Verständnis der Com-munitymitglieder interoperabel sein. Wir haben dieAnforderungsanalyse an das Community Require-ments Engineering aus unserem i*-Modell genutzt,um Benutzerschnittstellen des RE Bazars unter Nut-zung und Kombination verschiedener für das REeinsetzbarer Dienste (vgl. vorheriger Abschnitt) zurealisieren.

Im Folgenden stellen wir kurz einige Designstu-dien für Benutzerschnittstellen der Komponentendes RE-Bazars vor, zeigen deren Verbindung zu denModellelementen des in Abb. 2 skizzierten sozialenSoftwaresystems auf und illustrieren anhand eines

Abb. 3 Community-bewusstes Anforderungs-Dashboard des ROLE-Store

Szenarios die Interaktionen von Endnutzern undEntwicklern mit dem Bazar.

Um die aktuellen Anforderungen an bestehendeoder an neue Lernwerkzeuge auf einen Blick sicht-bar zu machen, bedienen wir uns der Konzeptedes Dashboards und der Prioritätenliste ange-wandt auf Anforderungen. Das in Abb. 3 gezeigteRE-Dashboard verschafft den Mitgliedern einer be-stimmten Community einen kompakten Überblicküber die aktuellen Anforderungen in Form einereinfachen Prioritätsliste. Hierbei sei erwähnt, dassdiese Listen nicht nur für bestimmte Communities,sondern beispielsweise auch für bestimmte Werk-zeuge, Mitglieder oder auch komplett entkoppeltvon jeglichen anderen Entitäten gebildet werdenkönnen. Für Endnutzer bietet diese Liste einenschnellen Überblick über die Beliebtheit aktuell dis-kutierter Anforderungen und insbesondere über dieBeteiligung von Entwicklern, die ihre neuen Anfor-derungen auch realisieren könnten. Für Entwicklerbietet die Liste wertvolle Informationen darüber, anwelchen Anforderungsrealisierungen sie am ehestenmitarbeiten sollten, um die größte Wirkung zu erzie-len, sei es in Form von nichtmateriellen Anreizen wieImagegewinn, sich eröffnenden Jobchancen etc. [19]oder gar Verkaufszahlen im Falle von kommerziellen

Informatik_Spektrum_34_2_2011 187

{ DER BAZAR DER ANFORDERUNGEN

Entwicklungen. Getreu dem Matthäus-Effekt [52]können diese Informationen bei aktiven Anforde-rungen zum Engagement weiterer Entwickler führenbzw. in Extremfällen bei geringer Aktivität bereitsengagierte Entwickler zur Niederlegung ihres Ar-beitsbeitrags zur Realisierung der Anforderungbewegen. In diesem Sinne stellt diese Liste durchihre Prioritätsordnung ein wichtiges Hilfsmittel zurEntscheidung über Anforderungsrealisierungen dar.Über den Knopf Add new in der linken oberen Eckekönnen Nutzer des RE-Stores explizit neue Anforde-rungen in das System einstellen. Über das ebenfallslinks oben angedeutete Suchfeld können Nutzergezielt nach bestimmten schon existierenden Anfor-derungen suchen (z. B. Volltext-Suche, Tag-basierteSuche, etc.). Die Suche dient u. a. der Vorbeugungunnötiger Doppeleinträge und der Bestätigung derNutzer im Sinne dass andere bereits gleiche oderähnliche Anforderungen artikuliert haben.

Jedes Element einer solchen Liste repräsentierteine bestimmte Anforderung. Für jede Anforderungwerden folgende Zusatzinformationen visualisiert(s. Abb. 3 von links nach rechts). Der Titel ist mit

Abb. 4 DetaillierteÜbersichtseite überAnforderung im ROLE-Store

einer Unterseite verlinkt, die einen detailliertenÜberblick über die jeweilige Anforderung bie-tet. Eine solche Seite wird in Abb. 4 unten weiterbeschrieben. Zur Kategorisierung wird die in Web-2.0-Systemen gängige Verschlagwortung (engl.:Tagging) genutzt. Ein Aktivitätsindikator ähnlicheinem Batteriefüllstandanzeiger zeigt ein Aggre-gat der aktuellen Aktivität um eine Anforderung,z. B. Kommunikationsaktivität, Entwicklungsakti-vität, etc. an. Ein Graph zeigt für bereits teilweiseumgesetzte Anforderungen deren aktuelle Benut-zung in aggregierter Form über die Zeit. DieseInformation wird aus Aufzeichnungen der Sys-temnutzung gespeist, die durch Monitoringdiensteerhoben werden. Des Weiteren werden die Anzahlvon Unterstützern und beteiligten Entwicklern derjeweiligen Anforderung gelistet. Neben den aus demSystembetrieb beobachtbaren Maßen bietet der RE-Store auch die Möglichkeit der expliziten Bewertungeiner Anforderung durch Communitymitglieder.Hierbei bedienen wir uns der im Web 2.0 gängi-gen Techniken des Collaborative Filtering, wobeiwir neben typischen auf Durchschnitt oder Me-

188 Informatik_Spektrum_34_2_2011

dian vieler Einzelwertungen basierenden Maßenauch Preisbildungsmechanismen [53] als kumula-tive Maße integrieren, um somit eine zusätzlicheDimension der Priorisierung zu geben. Alle In-formationen über Nutzung, Aktivität, Teilnahmeam Diskussions- und Entwicklungsprozess, Bewer-tungen etc. geben sowohl implizit als auch explizitAuskunft über bereits getroffene Entscheidungenbzgl. der Anforderungsrealisierung.

Unter der Liste wird mit drei verschiedenenSchiebereglern angedeutet, dass der Einfluss derverschiedenen Analysetechniken individuell ge-wichtet werden kann. Eine neue Gewichtung kanndabei Einfluss auf die Sortierung der Liste neh-men. Alle Analysetechniken werden ebenfalls durchentsprechende Dienste getrieben und basieren aufcommunitygenerierten Inhalten, Monitoringdatenund explizit abgegebenen Bewertungen.

Wählt ein Communitymitglied ein Element ausder in Abb. 3 gezeigten Liste, so gelangt er auf eineÜbersichtsseite, die umfassende Informationen zueiner bestimmten Anforderung bietet. Abbildung 4zeigt eine solche Seite für eine Anforderung einesbereits existierenden Werkzeugs.

Neben detaillierter Visualisierungen der bereitsin der Liste in Kompaktform genutzten Elementebeinhaltet diese Seite den Zugang zu aktuellen Nut-zungsstatistiken bei existierenden Werkzeugen,einen Überblick über die soziale Struktur der sichum die Anforderung gebildeten Gruppe von Nutzernund Entwicklern sowie die Möglichkeit des Beitrittszur Entwicklergruppe. Weiterhin sind im unterenBereich der Seite Möglichkeiten der anforderungs-zentrierten Kommunikation mithilfe integrierterKommunikationsdienste gegeben. Das wohlbe-kannte Konzept eines Multiuserchatraums mitpersistiertem Konversationslog ist hierfür bestensgeeignet, da sowohl asynchrone als auch syn-chrone Kommunikation in Echtzeit nachvollziehbarumgesetzt sind.

Das folgende Szenario im Kontext Widget-basierter PLE soll die Interaktion von Endnutzernund Entwicklern mit dem RE Bazar näher illus-trieren. Ein Firmenmitarbeiter in der Rolle desEndnutzers stellt bei der häufigen Nutzung seinesPLE zum Erlernen der spanischen Sprache fest, dassein bisher von ihm und vielen anderen Kollegenoft genutztes Vokabeltrainer Widget keine Mög-lichkeit bietet, die fremdsprachigen Begriffe zumZwecke der Verbesserung der eigenen Aussprache

von Muttersprachlern vorlesen zu lassen. Im ROLE-Widget-Store sucht er daraufhin nach alternativenVokabeltrainer-Widgets, die aber alle keine Vorlese-funktion bieten. Es existiert also für ihn eine neueAnforderung einer Produktverbesserung, die er nunim RE-Bazar artikulieren möchte. Unter der An-nahme, dass seine Anforderung bereits von anderengeäußert wurde, sucht er mithilfe einer Tag-basiertenAnfrage nach ähnlichen Anforderungen und wirdfündig. Auf den ersten Blick erkennt er, dass bereitsviele andere Nutzer ihr Interesse an der Umsetzungseiner Anforderung in Form einer direkten hohenBewertung (z. B. 5-Sterne-Skala, fiktives Preisgebot)bekundet haben. Weiterhin stellt er die rege Betei-ligung einer Gruppe von Entwicklern fest, die sichzur Umsetzung der Anforderung entschlossen ha-ben. Eine Visualisierung der Nutzungsstatistiken desVokabeltrainer-Widgets stellt eine hohe Anfragefre-quenz vieler Nutzer dar und demonstriert so u. a. dieBeliebtheit des Werkzeugs. Eine SNA-Visualisierungder Kommunikation zwischen Unterstützern undEntwicklern der Anforderung zeigt ein dichtes Netzzwischen den Entwicklern, ein weniger dichtes Netzzwischen den Endnutzern sowie zahlreiche Verbin-dungen zwischen beiden Gruppen. Weiterhin sindin beiden Gruppen einige extrem stark vernetzteMitglieder als potentiell wichtige Ansprechpartnererkennbar. Die Kommunikation der Community umdiese Anforderung scheint also vielversprechend.Der Endnutzer möchte die Umsetzung der Anforde-rung weiter unterstützen, gibt dazu seine Bewertungab und steigt in die Kommunikation mit anderenUnterstützern und Entwicklern ein. Ein ambitio-nierter Open-Source-Entwickler auf dem Gebietder Anwendungsentwicklung für Sprachtraininginteressiert sich für neue Aufgaben, die sich an aktu-ellen Bedürfnissen der Community der Sprachlernerorientieren sollen. Auf Anhieb entdeckt er in derPrioritätenliste die Anforderung nach Sprachun-terstützung im Vokabeltrainer-Widget mit hohemStellenwert. Nach Betrachtung der Nutzungsstatis-tiken, Bewertungen und der Communitystrukturum die Anforderung entschließt er sich, dem Ent-wicklerteam beizutreten. Zusätzlich kommt ihm dieIdee, die Sprachunterstützung auf genereller Basisals Text-To-Speech-(TTS)-Widget für verschiedeneSprachen zu realisieren. Er fügt dem RE-Bazar eineentsprechende neue Anforderung eines neuen Pro-duktes hinzu und diskutiert diese mit den anderenEntwicklern und Endnutzern der ursprünglichen

Informatik_Spektrum_34_2_2011 189

{ DER BAZAR DER ANFORDERUNGEN

Anforderung einer Produkterweiterung. Im Endef-fekt resultiert die vergleichende Diskussion beiderAnsätze in einer Präferenz für ein separates TTS-Widget, dessen Funktionalität der Sprachsynthesevon anderen Widgets extern angestoßen werdenkann.

Der RE-Store soll nach seiner erfolgreichenEvaluierung in Workshops und Vorstudien zurImplementierung von PLE als Grundlage die-nen, den bisherigen von vorhandener öffentlicherFörderung abhängigen Entwicklungsprozess vonPLEs in einen nachhaltigen communitygestütztenOpen-Source-Entwicklungsprozess zu überführen.

SchlussbemerkungenTraditionelles RE ist auf die Ermittlung, Festschrei-bung und Nachvollziehbarkeit von Anforderungenin den Informationssystemen einer Organisationfokussiert. Die auch durch die fortschreitende Glo-balisierung vorangetriebene Vernetzung hat neueFormen der Zusammenarbeit und der informati-onstechnischen Lösungen zu deren Unterstützunghervorgebracht. In zwei Fallstudien, offenen In-novationsprozessen in der Bioinformatik undpersonalisierten Lernumgebungen haben wir dieneuen Anforderungen an ein adaptives RE füremergente Communities in einem Prozessablauf ver-deutlicht. Zur informatischen Unterstützung habenwir ein i*-Modell entwickelt für die Beschreibungder wechselseitigen Abhängigkeiten zwischen denCommunities und den von ihnen genutzten Infor-mationssystemen aus der Sichtweise des adaptivenRE. Unsere Idee ist es, das adaptive RE durch einenDienstbaukasten zu unterstützen, der in solche In-formationssysteme integriert werden kann. Dadurchentsteht im Sinne der Open-Source-Bewegung einBazar von Anforderungen. Diesen Vorgang habenwir prototypisch als RE-Bazar in einen Store für web-basierte Widgets zur Gestaltung von personalisiertenLernumgebungen umgesetzt. Bisherigen Ansätzen,die auf Ideen des Web 2.0 beruhen, wird damit einMechanismus zur Verfügung gestellt, der durch er-folgreiche Stores bewiesen hat, eine Vielzahl vonEntwicklern und Anwendern zusammenbringen zukönnen. Damit ist eine Übertragung in den Kontextinterorganisationaler Informationssystementwick-lung wahrscheinlicher geworden. Ähnlich wie inanderen Wirtschaftszweigen, in denen Zertifikatefür Luftverschmutzung oder Energieüberschüssegehandelt werden, können Unternehmen Anfor-

derungen an ihre Informationssysteme ermitteln,bewerten und sogar realisieren lassen. Damit entste-hen ganz neue Geschäftsmodelle für die Entwicklungvon Informationssystemen die einer globalisiertenund vernetzten Welt gerecht werden. Ein Beispielhierfür sind junge Unternehmen am Markt, dienoch keine Ressourcen für den Aufbau einer Ent-wicklungsabteilung haben und am Markt wegenihres hohen Innovationstempos nur schwer traditio-nelle IT-Dienstleister für komplexe und mit hohemÄnderungsbedarf versehene Projekte finden können.

In der zukünftigen Forschung wird neben derinformatischen Unterstützung natürlich auch dieinterdisziplinäre Erforschung dieser Prozesse einegroße Rolle spielen. Insbesondere sind neben denschon erwähnten Geschäftsmodellen auch die Fra-gen nach Barrieren im Innovationsprozess wichtig.Oft wird gerade in Open-Source-Communities Sta-gnation und Innovationsfeindlichkeit beobachtet.Die Gründe dafür liegen in den emergenten sozialenStrukturen, in denen eine Clique von etabliertenMitgliedern auf Kosten der Innovation ihre Machtausbaut. Das Establishment solcher innovations-feindlicher Kulturen kann durch interdisziplinäreGrundlagenforschung unter Ausnutzung neuererMethoden der ,,Computational Socioeconomics“analysiert und verstanden werden.

DanksagungenDiese Arbeit wurde von der DFG in den Forschungs-projekten CONTICI und UMIC sowie von der EU imForschungsprojekt ROLE unterstützt. Die Autorenbedanken sich bei allen Kollegen in diesen Projektenfür die zahlreichen Diskussionen und Beiträge.

Literatur1. Hagel J, Brown JS (2005) The Only Sustainable Edge: Why Business Strategy De-

pends on Productive Friction and Dynamic Specialization. Harvard Business SchoolPress, Boston

2. Chesbrough HW (2003) Open Innovation. The New Imperative for Creating andProfiting from Technology. Harvard Business School Press, Boston

3. Bächle M (2008) Ökonomische Perspektiven des Web 2.0 – Open Innovation, So-cial Commerce und Enterprise 2.0. Wirtschaftsinformatik 50(2):129–132

4. Muraschko I (2009) Cross-Community Communication Analysis and its Implicati-ons for Requirements Engineering and Project Management. Masterarbeit. RWTHAachen

5. Barcellini F, Détienne F, Burkhardt JM (2007) Cross-Participants: Fostering Design-Use Mediation in an Open Source Software Community. In: Proceedings of theECCE 2007 Conference, London, 28–31 Aug 2007

6. Bird C, Pattison D, D’Souza R, Filkov V, Devanbu P (2008) Latent Structure in OpenSource Projects. In: Proceedings of the 16th ACM SIGSOFT International Sympo-sium on Foundations of Software Engineering, Georgia, pp 24–35

7. Girvan M, Newman MEJ (2002) Community Structure in Social and Biological Net-works. Proc Natl Acad Sci USA 99(12):7821–7826

8. Brown J S, Adler R P (2008) Minds on Fire: Open Education, the Long Tail, andLearning 2.0. EDUCAUSE Rev 43(1):16–32

190 Informatik_Spektrum_34_2_2011

9. Anderson C (2006) The Long Tail: Why the Future of Business Is Selling Less ofMore. Hyperion, New York

10. O’Reilly T (2005) What Is Web 2.0 – Design Patterns and Business Models for theNext Generation of Software. http://www.oreillynet.com/lpt/a/6228, letzter Zu-griff 16.10.2010

11. Ramesh B, Jarke M (2001) Toward reference models for requirements traceability.IEEE Trans Softw Engin 27(1):58–93

12. Jung G, Lee B (2010) Analysis on social network adoption according to the changeof network topology – the impact of „Open API“ on the adoption of Facebook.Proc. 12th Intl. Conf. Electronic Commerce. Honolulu, pp 22–31

13. Hirschman A (1970) Exit, Voice and Loyalty – Responses to Decline in Firms, Or-ganizations and States. Cambridge, MA

14. Sutcliffe AG (1995) Requirements Rationales: Integrating Approaches to Require-ment Analysis. Symposium on Designing Interactive Systems, pp 33–42

15. von Hippel E (1986) Lead Users: A Source of Novel Product Concepts. Manag Sci32(7): 791–805

16. Lilien GL, Morrison PD, Searls K, Sonnack M, von Hippel E (2003) Performance As-sessment of the Lead User Idea-Generation Process for New Product Development.Manag Sci 48(8):1042–1059

17. Sitou W, Spanfelner B (2007) Towards Requirements Engineering for Context Ad-aptive Systems. In: Proceedings 31st Annual International Computer Software andApplications Conference, Washington, DC, pp 593–600

18. Raymond ES (2005) The Cathedral and the Bazaar. http://www.catb.org/∼esr/writings/cathedral bazaar/cathedral-bazaar/, letzter Zugriff 16.10.2010

19. Lakhani KR, von Hippel E (2003) How open source software works: „Free“ user-to-user assistance. Res Policy 32(6):923–943, doi:10.1016/S0048-7333(02)00095-1

20. von Hippel E (2001) Innovation by User Communities: Learning from Open-SourceSoftware. MIT Sloan Manag Rev 42(4):82

21. Cox A (1998) Cathedrals, Bazaars and the Town Council. http://slashdot.org/features/98/10/13/1423253.shtml, letzter Zugriff 16.10.2010

22. Michaelides R, Kehoe D (2007) Internet Communities and Open innovation: anInformation System Design Methodology. In: 6th IEEE/ACIS International Confe-rence on Computer and Information Science, Melbourne, Qld., pp 769–775

23. Lohmann S, Dietzold S, Heim P, Heino N (2009) A web platform for social requi-rements engineering. In: Münch J, Liggesmeyer P (Eds) Software Engineering2009 – Workshopband, 20–24 Sep 2009, Kaiserslautern, pp 309–315

24. Decker B, Ras E, Rech J, Jaubert P, Rieth M (2007) Wikibased stakeholder partici-pation in requirements engineering. IEEE Softw 24:28–35

25. Heß J, Offenberg S, Pipek V (2008) Community-Driven Development as participa-tion? – Involving User Communities in a Software Design Process. In: Participa-tory Design Conference, Bloomington

26. Castro-Herrera C, Cleland-Huang J, Mobasher B (2009) Enhancing stakeholder pro-files to improve recommendations in online requirements elicitation. In: IEEE In-ternational Conference on Requirements Engineering, Atlanta, pp 37–46

27. Baeza-Yates R, Calderón-Benavides L, González-Caro C (2006) The intention be-hind web queries. In: Crestani F, Ferragina P, Sanderson M (Eds) Proceedings ofString Processing and Information Retrieval, Lecture Notes in Computer Science,vol 4209, Springer, Berlin Heidelberg, pp 98–109

28. Strohmaier M, Kroell M (2009) Studying Databases of Intentions: Do Search QueryLogs Capture Knowledge about Common Human Goals? In: The Fifth Internatio-nal Conference on Knowledge Capture, Redondo Beach, 1–4 Sep 2009

29. Kroell M, Strohmaier M (2009) Analyzing Human Intentions in Natural LanguageText. In: The Fifth International Conference on Knowledge Capture, RedondoBeach, 1–4 Sep 2009

30. Yu E (1997) Towards Modelling and Reasoning Support for Early-Phase Require-ments Engineering. In: Proceedings 3rd IEEE Int. Symp. on Requirements Engi-neering, Washington D.C., 6–8 Jan 1997, pp 226–235

31. Bryl V, Giorgini P, Mylopoulos J (2009) Designing socio-technical systems: fromstakeholder goals to social networks. Requirem Engin 14(1):47–70

32. Hannemann A, Hocken C, Klamma R (2009) Community Driven Elicitation of Re-quirements with Entertaining Social Software. In: Münch J, Liggesmeyer P (eds)Software Engineering 2009 Workshop-Band, Kaiserslautern, pp 317–328

33. Wang Y (2009) The CONTici Dashboard for Community-Aware Requirements En-gineering. Diplomarbeit. RWTH Aachen

34. Chatterjee A, Law E, Verbert K (2009) EU FP7 IP ROLE (Responsive Open LearningEnvironments) Deliverable 1.3/4: Functional and non-functional requirements ana-lysis and specification. Fraunhofer-Institut für Angewandte InformationstechnikFIT, Sankt Augustin

35. Wenger E (1998) Communities of Practice: Learning, Meaning, and Identity. Cam-bridge University Press, Cambridge

36. Lave J, Wenger E (2001) Situated learning: Legitimate peripheral participation.Cambridge University Press, New York

37. Jarke M, Klamma R (2006) Reflective community information systems. In: Mano-lopoulos Y et al (eds) Proceedings of the International Conference on EnterpriseInformation Systems, ICEIS 2006, Paphos

38. Spaniol M, Klamma R, Janssen H, Renzel D (2006) LAS: A Lightweight ApplicationServer for MPEG-7 Services in Community Engines. In: Tochtermann K, Maurer H(eds) Proceedings of I-KNOW ’06, 6th International Conference on Knowledge Ma-nagement, Austria, J.UCS Proceedings, Springer, pp 592–599

39. Cao Y, Klamma R, Martini A (2008) Collaborative Storytelling in the Web 2.0. In:Proceedings First International Workshop on Story-Telling and Educational Gamesat EC-TEL 08, Maastricht

40. Sharda N (2005) Movement Oriented Design: A New Paradigm for Multimedia De-sign. Intern J Lat Comp 1:7–14

41. Dey A (2001) Understanding and Using Context. Pers Ubiquitous Comp 5(1):4–742. Renzel D, Klamma R, Spaniol M (2008) MobSOS – A Testbed for Mobile Multime-

dia Community Services. In: 9th International Workshop on Image Analysis for Mul-timedia Interactive Services, Klagenfurt, Mai 2008

43. Wasserman S, Faust K (1994) Social Network Analysis: Methods and Applications,Cambridge University Press, Cambridge

44. Kidane Y, Gloor P (2007) Correlating Temporal Communication Patterns of theEclipse Open Source Community with Performance and Creativity. Comp Math Or-gan Theory 13(1):17–27

45. Roger EM (1983) Diffusion of Innovations. Free Press, New York46. Google Inc.: OpenSocial Specification 1.1 DRAFT. http://opensocial-resources.

googlecode.com/svn/spec/1.1/OpenSocial-Specification.xml, letzter Zugriff16.10.2010

47. Cáceres M (2009) Widget Packaging and Configuration. W3C Candidate Recom-mendation. http://www.w3.org/TR/2009/CR-widgets-20091201/, letzter Zugriff16.10.2010

48. Recordon D, Hoyt J, Bufu J, Fitzpatrick B, Hardt D, et al (2007) OpenID Authen-tication 2.0 – Final Specification. http://openid.net/specs/openid-authentication-2_0.html, letzter Zugriff 16.10.2010

49. Hammer-Lahav E, Recordon D, Hardt D (2010) The OAuth 2.0 Protocol. IETF DraftStandard. http://tools.ietf.org/html/draft-ietf-oauth-v2-10, letzter Zugriff16.10.2010

50. O’Reilly T, Batelle J (2009) Web Squared: Web 2.0 Five Years On. Web 2.0 Sum-mit Special Report. http://assets.en.oreilly.com/1/event/28/web2009_websquared-whitepaper.pdf, letzter Zugriff 16.10.2010

51. Canetti E (1968) Die Stimmen von Marrakesch: Aufzeichnungen nach einer Reise.Fischer, Frankfurt

52. Merton R (1968) The Matthew Effect in Science. Science 159(3810):56–6353. Keen PGW (1981) Value Analysis: Justifying Decision Support Systems. MIS Quart

5(1):1–16

Informatik_Spektrum_34_2_2011 191