HAUPTBEITRAG / DER BAZAR DER ANFORDERUNGEN

Der Bazar der Anforderungen Open Innovation in emergenten Communities Ralf Klamma · Matthias Jarke Anna Hannemann · Dominik Renzel

Einleitung Traditionelle Informationssysteme sind auf Organisationen ausgelegt. Die Basis für das Anforderungsmanagement ist damit durch die Strukturen und Grenzen der Organisation bestimmt. Organisationsübergreifende Arbeitsteilung und Globalisierung, aber auch technische Entwicklungen wie serviceorientierte oder gar Cloud-orientierte Architekturen verändern diese Situation grundlegend. Informationsdienste werden unternehmensübergreifend, geographisch verteilt und zunehmend auch mobil genutzt. Ihre Basisfunktionalitäten sind daher mit ständig wechselnden Kontexten zu anwendbaren Lösungselementen und Teilprozessen zu verknüpfen. Die Adaption im Systemgebrauch, aber auch die Systemevolution über längere Zeiträume hinweg wird durch die Nutzung in solchen übergreifenden Kontexten bestimmt. Die Entscheidung darüber obliegt nicht mehr fixierten Organisationsstrukturen, sondern ,,Communities“ interessierter und engagierter Nutzer und sonstiger Stakeholder aus oftmals vielen organisatorischen oder privaten Kontexten. Bewusst will man die Innovationsideen der Nutzergemeinde in die Weiterentwicklung einbeziehen. In der Literatur werden derartige Prozesse unter dem Schlagwort ,,Innovation at the Edge“ [1] oder ,,Open Innovation“ diskutiert [2, 3]. Zwei Fallstudien aus den Bereichen der Bioinformatik und des E-Learnings sollen die zum Teil stark differierenden Praktiken heutiger Zusammenarbeit von Entwicklern und Endnutzern in solche Prozessen kurz darlegen. Eine von uns durchgeführte Studie [4] zur Struktur und Entwicklung dreier EntwicklerCommunities im Bereich der Bioinformatik (http://

biojava.org, http://bioperl.org, http://biopython.org) in Anlehnung an [5, 6] bot Einblicke in die Kommunikation und die Arbeitsweise dieser Communities. Die Datenbasis unserer Untersuchungen bildeten dabei Archive von Mailinglisten der jeweiligen Communities über einen Zeitraum von 10 Jahren seit ihrer Entstehung. Mithilfe von speziellen Crawlern konnten über 5000 Kontakte und über 50.000 Nachrichten extrahiert, bereinigt und zu einem dynamischen sozialen Netzwerk zusammengefügt werden. Mithilfe der Kombination von Algorithmen zur Trennung einzelner Communities [7] und der manuellen Untersuchung von Kommunikationsinhalten nach jeweiligen Aktivitäten zur Identifikation konnte gezeigt werden, dass sowohl Entwickler als auch Endnutzer die gleichen Kommunikationskanäle nutzen (in diesem Falle Mailinglisten), aber dass Kommunikation zwischen den Gruppen meist über wenige sog. Boundary Spanner erfolgt, dass eine Zunahme der Anzahl der Boundary Spanner zu verkürzten Zeiträumen zwischen Releases beitrug, dass Endnutzer weitaus weniger dicht miteinander vernetzt sind als Entwickler und dass die KommuDOI 10.1007/s00287-010-0516-5 © Springer-Verlag 2011 Ralf Klamma · Matthias Jarke · Anna Hannemann Dominik Renzel Informationssysteme & Datenbanken, Rheinisch-Westfälische Technische Hochschule Aachen, Ahornstr. 55, 52074 Aachen E-Mail: {klamma, jarke, hannemann, renzel}@ dbis.rwth-aachen.de Matthias Jarke Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V., Fraunhofer Institute for Applied Information Technology FIT, Schloss Birlinghoven, 53754 Sankt Augustin E-Mail: [email protected]

}

{ DER BAZAR DER ANFORDERUNGEN

Zusammenfassung Traditionelles Requirements Engineering ist auf die Ermittlung, Festschreibung und Nachvollziehbarkeit von Anforderungen in den Informationssystemen einer Organisation fokussiert. Die fortschreitende Globalisierung und Vernetzung hat neue Formen der Zusammenarbeit und der informationstechnischen Unterstützung hervorgebracht. Auf Basis von zwei Fallstudien zu offenen Innovationsprozessen haben wir die Anforderungen an ein adaptives Requirements Engineering für emergente Communities ermittelt. Zur informatischen Unterstützung haben wir ein i*-Modell für die Beschreibung der wechselseitigen Abhängigkeiten zwischen den Communities und den von ihnen genutzten Informationssystemen aus der Sichtweise des adaptiven RE entwickelt. Wir unterstützen das adaptive RE durch einen Dienstbaukasten, der in die zu entwickelnden Informationssysteme integriert werden kann. Dadurch entsteht im Sinne der Open-Source-Bewegung ein Bazar von Anforderungen. Diesen Vorgang haben wir prototypisch in einen Store für webbasierte Widgets zur Gestaltung von personalisierten Lernumgebungen umgesetzt.

nikationsweisen von Endnutzern und Entwicklern klar voneinander unterscheidbar sind. Etwas anders haben sich die Communities im Bereich des E-Learning entwickelt. Hier repräsentieren personalisierte Lernumgebungen (engl.: personal learning environments oder PLE) informatisch die zunehmende Unterstützung informeller Lernsituationen, beispielsweise beim lebenslangen Lernen außerhalb spezieller Lerninstitutionen. Entsprechend haben sich schnell um die von Entwicklern zur Verfügung gestellten Technologien Tausende von Communities mit entsprechend heterogenen Lernzielen entwickelt [8, 9]. Alle eint der Anspruch, sich ihre persönlichen Lernumgebung aus gegebenen Diensten – zumeist aus dem Kontext des Web 2.0 [10] und der Open-Source-Bewegung – entsprechend ihren eigenen Vorstellungen zusammenstellen zu wollen. Kommunikation zwischen Lernenden (Endbenutzern) und Entwicklern findet mittels verschiedenster Kommunikationswerkzeuge

des Web 2.0 wie etwa Twitter (http://twitter.com), Facebook (http://facebook.com), verschiedener Instant Messenger wie Skype (http://skype.com) etc. oder mittels direkter Feedback-Mechanismen in den Lernwerkzeugen selbst statt. Diese Beispiele zeigen das Potenzial eines Ansatzes zum Anforderungsmanagement auf, der systematisch in eine emergente Benutzergemeinde integriert ist. Aus Sicht des traditionellen Anforderungsmanagements haben sie jedoch auch deutliche Schwächen, weil eine systematische Struktur zur Erfassung und Priorisierung, welche Anforderungen bevorzugt umgesetzt werden sollten, ebenso fehlt wie eine Nachvollziehbarkeit (Traceability [11]), welche Anforderungen eigentlich umgesetzt worden sind und wie dies geschehen ist. Weiterhin muss die Kommunikation zwischen Entwicklern und Endnutzern gestärkt werden, um einen besseren Abgleich zwischen Bedürfnissen und tatsächlichen Produktentwicklungen zu erreichen. In dieser Arbeit gehen wir entsprechend der Frage nach, wie die Mitglieder der Communities in die Lage versetzt werden können, sich flexibel und strukturiert zur Weiterentwicklung ihrer Systemlandschaft äußern zu können [12]. Schließlich ist es notwendig, dass Communitymitglieder sich nicht nur äußern können, sondern dass geäußerte Anforderungen auch umgesetzt werden. Hier besteht eine wechselseitige Interessenabhängigkeit zwischen Endnutzern und Entwicklern. Endnutzer äußern ihre Anforderungen, tun dies aber nur, wenn sie auch die Chance sehen, dass ihre Stimme von Entwicklern gehört wird. Im anderen Falle droht sogar die Abwanderung aus der entsprechenden Community [13]. Entwickler vertreten wiederum den Anspruch, größtmöglichen Nutzen und Verbreitung ihrer Arbeit zu erwirken, etwa aus monetären oder Image-Interessen. Die Ziele beider Gruppen können nur dann erreicht werden, wenn diese wechselseitigen Abhängigkeiten entsprechend sichtbar gemacht und bedient werden. Weiterhin sollen die so entstandenen Anforderungen gut verständlich und nachhaltig dokumentiert werden, beispielsweise um neuen Benutzern beim Einstieg in die Community zu helfen und der gesamten Community die Nachvollziehbarkeit zu sichern. Nach einem kurzen Literaturüberblick der bisherigen Softwareunterstützung für Open Innovation identifizieren wir anhand von Beobachtungen in den oben genannten Anwendungsbereichen typische

Abstract Traditional Requirements Engineering is focused on the identification, persistence, and traceability of requirements in organizational information systems. Progressing globalization and networking has spawned new forms of collaboration in information technology support. Based on two case studies we identified requirements to an adaptive form of Requirements Engineering for emergent communities. We developed an i* model for the description of mutual dependencies among communities and the information systems they use from the perspective of an adaptive RE. We support adaptive RE by a service toolkit, which can be integrated into arbitrary information systems to be developed. Thus, a bazaar of requirements emerges in the spirit of the open source movement. We have prototypically realized this process in a store for web-based widgets for the creation of personalized learning environments.

Muster von Adaptionsprozessen. Diese werden dann in einer gemeinsamen Grundstruktur mittels der Modellierungssprache i* formalisiert. Zur konkreten Unterstützung im organisationsübergreifenden Kontext schlagen wir das Konzept eines ,,RE Bazars“ vor, einer Sammlung traditioneller und innovativer RE-Dienste zur Unterstützung des adaptiven Community Requirements Engineering. Wir beschreiben eine prototypische Umsetzung und schließen mit einer Anwendungsfallstudie zur Validierung dieses Konzepts.

Open Innovation: State-of-the-Art Die klassischen Ansätze des Anforderungsmanagements (Requirements Engineering, RE) basieren auf strukturierten und formal beschriebenen Anforderungen bestimmter Stakeholder-Gruppen (z. B. Manager, Entwickler, Endbenutzer etc.). Seit langer Zeit betonen Wissenschaftler die Wichtigkeit eines partizipativen Prozesses für die Identifikation von Anforderungen und somit für den Projekterfolg [14]. Von Hippel et al. belegen klar, dass die Miteinbeziehung von Produktnutzern in den Innovationsprozess in Bezug auf Produktverbesserungen oder die Entwicklung neuer Produkte in klaren Wettbewerbsvorteilen resultiert. Während traditionelle

Marktanalysen zufällige Nutzergruppen auswählen, zielt von Hippels Ansatz auf die Gruppe der LeadUser ab, d. h. die Gruppe von Nutzern, deren heutige Anforderungen aufgrund ihrer Expertise in der Nutzung aktueller Produkte in der Zukunft hohes Potential zur Markteinführung neuer Produkte bieten; betont wird, dass die Identifikation von LeadUsern eine Herausforderung darstellt [15]. In einer Vergleichsstudie in Kooperation mit der traditionell innovationsfreudigen Firma 3M konnte gezeigt werden, dass der Lead-User-Ansatz im Vergleich zu traditionellen Projekten zu einem deutlich erhöhten Anteil erfolgreicher neuer Produktlinien und somit im Falle von 3M in einer Verachtfachung der jährlichen Umsätze resultieren kann [16]. Am Beispiel der Entwicklung kontextadaptiver Anwendungen dokumentieren Sitou und Spanfelner, dass adaptives Systemverhalten den Nutzererwartungen oft nicht entspricht, wenn der Nutzer nicht in den Entwicklungsprozess einbezogen ist [17]. Daher ist die Organisation eines RE-Prozesses zur Analyse von Systemverhalten und -adaption beginnend beim Nutzer als Mitglied einer oder mehrerer Communities von enormer Bedeutung. Wird ein System durch eine Community genutzt, so muss auch der RE-Prozess communityorientiert organisiert werden. Weiterhin erkennen Firmen zunehmend, dass Innovationsentwicklung nicht mehr vollständig und isoliert in den eigenen Entwicklungslaboren stattfinden sollte. Vielmehr sollten Erkenntnisse aus externer Forschung in eigene Entwicklung integriert (Outside-In-Prozesse) und eigene Entwicklungsfortschritte veräußert werden. Dadurch wird einerseits die ständige Neuerfindung des Rads vermieden und andererseits werden Entwicklungsfortschritte schon in frühen Stadien für potentiell interessierte Kunden zur Sicherung des eigenen Wissens und somit des Wettbewerbsvorteils sichtbar gemacht. Von Seiten der Wirtschaftswissenschaften beschreibt Chesbrough diese Sichtweise als Open Innovation [2], insbesondere in Verbindung mit von Hippels Lead-User-Ansatz. Viele Unternehmen haben Open Innovation bereits in ihre Firmenkultur integriert und stellen zur Kommunikation Web 2.0-Plattformen bereit (z. B. IBM https://www.collaborationjam.com/ und SAP http://www.sapiens.info/). Ähnliches gilt in der Open-Source-Softwareentwicklung [18]. Allerdings sind die Motivationen der Teilnahme von Mitgliedern aus der Open-Source-Szene durch das Fehlen

{ DER BAZAR DER ANFORDERUNGEN

direkter monetärer Anreize anders als in kommerziellen Umgebungen, aber trotzdem gegeben [19]. Diese Motivation sollte auch von kommerziellen Unternehmen nicht unterschätzt werden [20]. Meist beinhalten die durch Communitymitglieder generierten Beiträge neben Innovationsvorschlägen oder Fehlerberichten auch einen beträchtlichen Anteil an ,,Kommunikationsrauschen“ [21]. Zudem betont Cox, basierend auf seiner Erfahrung in der Open-Source-Entwicklung, im Gegensatz zu von Hippel die Wichtigkeit, gerade auch peripheren Nutzern zuzuhören. Das Informationsmanagementproblem, die Analyse sozio-technischer Strukturen der Community und die Adaption an den aktuellen Communityzustand sind daher zusätzliche Anforderungen an das communityorientierte RE. Michaelides und Kehoe [22] untersuchen Entwicklungsprozesse von Informationssystemen (IS) für wissenschaftliche Onlinecommunities. Um die Communitymitglieder in das Systemdesign und die Evaluierung zu involvieren, wird zunächst ein Systemprototyp erstellt, der anschließend durch Mitglieder der Community getestet und bewertet wird; ähnlich der Idee des ,,perpetual beta“ aus dem Web 2.0. Dabei werden sowohl die Umfragen als auch die Optionen im Bewertungsbogen durch das Entwicklerteam festgelegt. Dieser Ansatz löst das Informationsmanagementproblem, gibt aber den teilnehmenden Mitgliedern keine Möglichkeit, neue Ideen über die vorgesehenen Optionen hinaus in den RE-Prozess einzubringen. Lohmann et al. [23] stellen eine wikibasierte Webplattform für soziales RE vor. Jedes Communitymitglied kann neue Anforderungen anlegen, die existierenden ändern oder diskutieren, und auch Abhängigkeiten zwischen Anforderungen im System vermerken. Das System unterstützt soziales Feedback durch Kommentar, Rating und Stimmabgabe. Um Mehrdeutigkeit und unterschiedliche Interpretationen 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 ähnliche Begriffe und somit auch die Beiträge zusammengeführt. Einen wikibasierten Ansatz schlagen auch Decker et al. [24] für partizipatives RE in verteilten Communities vor. Um die Anforderungen zu formalisieren, werden Anforderungsformulare, Klassifikationstabellen und Gruppierungsregeln angewendet.

Heß et al. [25] berichten über die weitestgehend erfolgreiche Erprobung eines communitygetriebenen Ansatzes für den gesamten Entwicklungsprozess einer TV-Plattform. Durch die Einführung organisatorischer Steuerwerkzeuge wie eines Parlaments und Zentralkomitees jeweils gebildet aus Benutzern, professionellen Entwicklern und Projektleitern sollte die oft vorherrschende Vormacht der Entwickler und Projektleiter zugunsten der Endnutzer künstlich durch geringere Repräsentation in den Gremien abgeschwächt werden. Entscheidungen über Anforderungspriorisierung wurden ausschließlich innerhalb der Gremien getroffen. Kritik an diesem Ansatz kam vornehmlich aus den Reihen der Nichtmitglieder und umfasste die fehlende Nachvollziehbarkeit auf Basis von Zugangsbeschränkungen auf gremieneigene Dokumente und eine daraus resultierende Frustration, ungenügend in Ideen- und Entscheidungsfindungsprozesse eingebunden zu sein (vgl. [13]). Weiterhin war die Nachvollziehbarkeit durch die Nutzung verschiedener nicht miteinander synchronisierter und teilweise unübersichtlicher Medien (Forum und Wiki) negativ beeinträchtigt. Auch textbasierte Diskussionsforen können für die Anforderungserhebung in globalen Entwicklungsumgebungen eingesetzt werden [26]. Die Verwaltung von Anforderungen ist durch eine Kombination von Textmining und Klassifikation von gesammelten Foreneinträgen realisiert. Jedoch benötigt dieser Ansatz 50–100 vordefinierte und bereits klassifizierte Anforderungen, damit das Clustering von neuen Beiträgen stattfinden kann. Aus Sicht der oben beschriebenen Fallstudien bieten all diese Ansätze lediglich einen medialen Rahmen zur Kommunikation und zum Austausch von Informationen. Ihnen fehlen jedoch ein geeignetes konzeptionelles Gesamtverständnis des mediengestützten Adaptions- und Evolutionsprozesses, und damit eine wenigstens grob-granulare prozessorientierte Unterstützung der Anforderungsanalyse und Innovationsabläufe. Zudem sind die eingesetzten Softwarewerkzeuge jeweils vorbestimmt und somit ist das Unterstützungsangebot bezogen auf genutzte Medien, Modalitäten und Erfassungskontexte immer noch wenig flexibel. Der im Folgenden beschriebene Lösungsansatz dient der Beseitigung dieser Defizite. Insbesondere gilt unser Augenmerk hier der Unterstützung beim Aufbau von sich selbst tragenden und nachhaltig existie-

Abb. 1 Adaptionsmodell

renden Communities rund um die Nutzung und Entwicklung von Informationssystemen. Nach unserer Auffassung ist die strukturiert nachvollziehbare und nachhaltige Kommunikation zwischen Endnutzern und Entwicklern ein zentraler Faktor bzgl. der kontinuierlichen Verbesserung und des Wachstums der Systeme.

Adaptive-Requirements-EngineeringModelle für Communities Unsere einleitend skizzierten Beobachtungen von Communities u. a. in Bioinformatik und E-Learning ergaben bei aller Unterschiedlichkeit folgende Gemeinsamkeiten in den Unterstützungsanforderungen, die von den bisherigen Lösungsansätzen noch kaum erfüllt werden: Zum einen entstehen typischerweise rasch klar unterscheidbare Subcommunities aus verschiedenen Endbenutzerklassen (Lead User, Power User, Early Adopter, Boundary Spanner usw.) und Entwicklern (Open-Source-Entwickler, kommerzielle Entwickler usw.). Daher ist es möglich und sinnvoll, durch strukturanalytische Methoden die emergenten sozialen Strukturen zu erfassen und zu verstehen. Communities identifizieren sich selbst vielmehr durch ihren sozialen als durch ihren organisational-institutionellen Kontext. Zur Analyse dieser sozialen Kontexte und Strukturen können die persistenten kommunikativen Akte der Communities herangezogen werden. Zum anderen äußern sich die Communities auf verschiedene Weisen über ihre Bedürfnisse an die Informationstechnologie und brauchen damit eine fortlaufende Anforderungsanalyse. Durch die inhaltliche Analyse der Kommunikationsakte der Communities können eine Unzahl von implizit und explizit geäußerten Anforderungen an das zukünftige Verhalten der Communityinformationssysteme ermittelt (vgl. [27–29]) und mittels der strukturellen Analyse gewichtet werden. Noch mehr Information kann

mittels der Analyse der aktuellen Systembenutzung hinzugefügt werden. Zusammengenommen ergeben sich daraus neue Möglichkeiten, Communityinformationssysteme auf Anforderungsebene zu adaptieren. Diese Adaptionen können teilweise einen erheblichen zeitlichen Horizont haben, sind aber aufgrund der oft erstaunlich breiten Diskussion in der Community weitaus nachhaltiger als Adaptionen des Systemverhaltens, die auf der Nutzungs- oder Entwurfsebene durchgeführt werden. Wegen der Bedeutsamkeit dieser Adaptionen sind für die Communities Werkzeuge von Vorteil, die es ihnen erlauben, ihre Anforderungen besser zu äußern, zu dokumentieren und mit den Entwicklern zu kommunizieren. Die Qualität dieser Prozesse bestimmt in letzter Konsequenz die Qualität der Communityinformationssysteme. Unser Ansatz geht von einem kontinuierlichen Wechselspiel zwischen der Community – insbesondere Endnutzern und Entwicklern – und ihren Systemen einerseits, sowie zwischen ihrem jeweiligen Gesamtkontext und den Systemanforderungen andererseits aus, wie in Abb. 1 zusammengefasst. Kollaboration in Communities hat eine kontinuierliche Veränderung der Community selbst (Struktur, Rollenverteilung, etc.) und der Systemanforderungen zur Folge. Aus diesem Grund wird eine ständige Adaption und Koevolution von Wissensmodellen, Kollaborationsprozessen, Medien und Unterstützungsmechanismen an die sich weiterentwickelnden Bedürfnisse von Communitymitgliedern erforderlich. Da der RE-Prozess selbst Teil der Kollaboration ist, muss auch hier die Adaption an die aktuelle Situation stattfinden. Die Community als Kontext erfährt eine kontinuierliche Weiterentwicklung. Die Anforderungen der Mitglieder definieren die Gestaltung des Kollaborationsprozesses. Außerdem ist der Verlauf des Kollaborationsprozesses auch vom aktuellen Zustand der Community abhängig.

{ DER BAZAR DER ANFORDERUNGEN

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

Somit erfolgt Adaption der Kollaborationsdienste entsprechend der Communityanforderungen. Dieses Adaptionsmodell, das den RE-Prozess definiert, soll auch an die aktuelle Situation angepasst werden. Dabei ergibt sich der Kontext aus einer Kombination der Änderungen in Community, Kollaborationsprozess und RE-Aktivitäten. Basierend auf diesen drei Dimensionen kann ebenfalls der gesamte Adaptionsprozess verändert werden. Dieser Anpassungsschritt ist durch die äußere Schleife in Abb. 1 dargestellt. Um die beiden Adaptionsschritte zu realisieren wird ein Prozessansatz benötigt, der das communityorientierte RE, aber auch Analyse, Messungen und Monitoring von Communityaktivitäten und Artefakten ermöglicht. Als Vorbereitung einer informatischen Unterstützung eines solchen Prozessansatzes erscheint es sinnvoll, diesen in einem geeigneten Modellierungsansatz zumindest semiformal zu erfassen. Die Modellierungssprache i* [30] ist dafür besonders geeignet, denn sie ermöglicht die Beschreibung strategischer Ziele und Abhängigkeiten zwischen Akteuren eines soziotechnischen Systems [31], die in Form von (menschlichen oder technischen) Agenten dargestellt werden. Hierbei sei erwähnt, dass

der primäre Einsatzzweck von i* nicht die Prozessmodellierung ist, auch wenn die Modellierung von Abhängigkeiten oft Teile eines Prozesses andeutet. i* modelliert Agenten als benannte Kreise, die mit Darstellungen der Zielhierarchie der Agenten gefüllt sind. Zwischen den Agenten bestehen Abhängigkeiten verschiedenen Typs, die im Modell durch Rechtecke (Abhängigkeit bzgl. Erfüllung einer Aufgabe) bzw. sechseckige Rauten (Abhängigkeit bzgl. Verfügbarkeit einer Ressource) dargestellt sind. Dabei wird die Richtung der Abhängigkeit durch halbrunde Pfeilspitzen auf den Kanten dargestellt, die zu Abhängigkeitsobjekten bzw. von ihnen weg auf andere Objekte zeigen. Die Ausarbeitung des in Abb. 1 gezeigten Grundmodells erfolgte auf Basis von Erfahrungen in den oben skizzierten Fallstudien sowie in zahlreichen eigenen Softwareprojekten zur Communityunterstützung [32, 33]. Das in Abb. 2 gezeigte Modell [34] beinhaltet zwei Haupt-Agententypen: eine Community of Practice (CoP) [35] und das von ihren Mitgliedern verwendete Soziale Softwaresystem. Letzteres stellt eine Sammlung verschiedener CoP-Dienste zur Verfügung, wobei hier nur die für den RE-Prozess relevanten Dienste gezeigt sind.

Die soziale Software wird durch die Community als Kommunikations- und Kollaborationsmedium verwendet, was zum Entstehen eines Repository führt. Dessen Artefakte spiegeln das Verhalten der Communitymitglieder wider. Durch das Zusammenspiel aller Mitglieder in ihren Rollen entsteht auf Dauer eine CoP. Die Grundidee des RE-Prozesses ist eine Kombination von impliziten und expliziten Anforderungen. Hinreichender Einblick in die impliziten Anforderungen einer Community (Konflikte, Probleme, Veränderungen etc.) wird durch Analysetechniken gewährleistet, die durch entsprechende Dienste zur CoP-Anforderungsanalyse realisiert werden. Diese Techniken arbeiten auf Basis von CoP-produzierten Artefakten sowie der Nutzung des Systems, die durch entsprechende CoPMonitoringdienste aufgezeichnet werden. Außer ihrem direkten Anwendungszweck für das RE erzeugen Visualisierungen der Resultate dieser Analysetechniken ein erhöhtes Bewusstsein für Vorgänge innerhalb einzelner oder mehrerer Communities. Beispielsweise bieten die Resultate der CoP-SozialenNetzwerkanalyse die unverzichtbare Unterstützung von Newcomern, auf einfache Weise in bereits etablierte CoPs einsteigen zu können. Durch die Visualisierung der Netzwerkstruktur sowie der Positionen seiner Mitglieder erhält ein Neuankömmling bereits wertvolle Informationen über die Community, um nach [36] schneller aus der Peripherie dieser Community tiefer in deren Kern zu gelangen und im Zuge dessen die Bedürfnisse und Praktiken besser kennenzulernen und später selbst innovative Anforderungen zu generieren oder gar umzusetzen. Weiterhin sollten die SNA-Resultate in die Ermittlung einer Anforderungspriorisierung einfließen, die ein zentrales Hilfsmittel für Entwickler zur Entscheidung über die Anforderungsrealisierung darstellt. Die darunterliegende Intuition ist die folgende: Anforderungen, die eine große Zahl von Unterstützern – insbesondere Lead-Usern und Entwicklern – in reger Kommunikation um sich scharen werden in der Regel den Anforderungen vorgezogen, die unter Umständen nur von einer weitestgehend unbekannten und wenig vernetzten Person geäußert, aber nicht weiter von anderen unterstützt wurden. Communitymitglieder erhalten zudem die Möglichkeit zur expliziten Äußerung von Anforderungen. Hierzu wird der Community ein RE-Medium mittels Diensten zur Anforderungserhebung angeboten. Dabei kann eine große und unübersichtliche Menge von

Anforderungen entstehen. Um diese Anforderungen weiter zu bewerten und einzuordnen, wird ein zusätzlicher Service zur Unterstützung der Entscheidung über Anforderungsrealisierungen angeboten, der eine CoP-spezifische Ermittlung einer Anforderungspriorisierung auf Basis der Analyseergebnisse umfasst. Die Analyseergebnisse werden für die Communitymitglieder visualisiert. So werden die Anforderungen von der Community inklusive ihrer Peripherie für alle Mitglieder sichtbar und bewertbar und somit Entscheidungsfindungsprozesse in der Community unterstützt. Die Akzeptanz von Anpassungen wird somit erhöht. Das i*-Modell des RE für emergente Communities verbindet also Dienste für den Wissensaustausch mit Diensten zur Analyse von sozialer Struktur und Systemnutzung, erweitert durch Dienste zur Bewertung, Visualisierung und Priorisierung von Anforderungen.

Ein Dienstebaukasten für das RE Die wesentliche Idee des Dienstebaukastens für das RE besteht darin, eine Sammlung von Unterstützungsdiensten für die in Abb. 2 genannten Prozesse innerhalb der Community anzubieten. Da der Gedanke der Dienstorientierung und des RE verbunden werden, werden im Laufe der Zeit bestehende serviceorientierte Architekturen mit diesen existierenden oder gar standardisierten Diensten zur Ermittlung, Analyse und Beobachtung von RE-Prozessen integriert. Der RE-Prozess wird – da er verteilt und emergent stattfindet – mit dem Informationssystem verwoben. Dies verschafft dem Paradigma einer reflektiven Informationssystemarchitektur [37] Geltung. Für unseren Dienstebaukasten haben wir den Lightweight Application Server (LAS) unserer ATLAS-Umgebung gewählt [38]. Damit können wir die leicht erweiterbare Sammlung von RE-Unterstützungsdiensten im Kontext eines leichtgewichtigen Anwendungsservers anbieten, der über communitygeeignete Sicherheitskonzepte verfügt. Für verschiedene RE-Aktivitäten werden im Folgenden Beispiele realisierter Dienste in aller Kürze vorgestellt. Dienste zur COP-Anforderungserhebung. In unserem Ansatz ist das Erzählen von Geschichten ein wesentliches Mittel für die Erhebung von Anforderungen, da es ein natürliches Medium für den schnellen Austausch von Erfahrungen mit existierenden Informationssystemen darstellt, z. B. das gemeinsam

{ DER BAZAR DER ANFORDERUNGEN

erlebte Ärgernis einer benutzerunfreundlich konstruierten Anfragemaske. Die erzeugten Geschichten eignen sich zudem ausgezeichnet als Grundlage für Trainingsmaterialien für Neueinsteiger in die Communities, z. B. warum eine bestimmte Funktionalität für eine Aufgabe benutzt werden soll. YouTell [39] stellt eine multimediale Umgebung zum gemeinsamen Erzählen solcher Geschichten zur Verfügung. Die Geschichten werden im Sinne des Web 2.0 kommentiert, bewertet und diskutiert. Das gewählte Strukturparadigma [40] von Geschichten ermöglicht die Validierung von Geschichten gegen von Nutzern ausgewählte Vorlagen. So kann auch ungeübten Erzählern ein rascher Einstieg in die narrativen Strukturen des RE ermöglicht werden. Die Geschichten können entsprechend der Community, der Domänen, aber auch mittels willkürlich gewählter struktureller (z. B. Pfade, Orts- und Zeitkontexte, Autoren) [41] oder inhaltlicher (z. B. Schlüsselwörter, Beschreibungen) Kriterien für die Analyse (s. u.) aufbereitet werden. Dienste wie youTell können für das RE einfach variiert werden, um den Spaß am RE zu erhöhen. So haben wir einen Annotationsdienst für Bilder, hier Bildschirmabzüge, entwickelt, der es Benutzern erlaubt, gemeinsam Sprechblasen mit eigenen Texten (Kommentare und Anforderungen) in das Bild einzufügen. Diese einfachen, an Comics orientierten Methoden des Erzählens von Geschichten haben Benutzer stark motiviert, sich aktiv in RE Prozesse einzubringen [32]. Dienste zum CoP-Anforderungsmonitoring. Die Beobachtung von RE-Aktivitäten wird mittels des MobSOS Dienstes realisiert [42]. Dieser Dienst erlaubt die Beobachtung von Interaktionen der Benutzer mit den Diensten, aber auch die Interaktion von Benutzern untereinander auf der Ebene der in der Kommunikation eingesetzten Protokolle. HTTP erlaubt z. B. die einfache Beobachtung von Anfragen an einen Webserver, während XMPP weitere Kommunikationsakte zwischen Benutzern beobachtbar macht. Dienste zur CoP-Anforderungsanalyse. Hier können Analysemethoden wie die Statistische Nutzungsanalyse oder die Soziale Netzwerk Analyse (SNA) eingesetzt werden. Während die Benutzung von Diensten statistische Evidenzen über die Popularität und weiterführend über die Struktur von Dienstaufrufen schafft, kann die SNA mittels Zentralitätsmaßen [43] die Bedeutung des einzelnen

Nutzers in der Community bemessen und so Statistiken verstärken oder entkräften. Als Beispiel sei die Statistik eines Benutzeraccounts des CIOs gegeben, der von den Entwicklern seiner Firma als gemeinsamer Testaccount verwendet wurde. Auf den ersten Blick war man erstaunt, wie häufig dieser CIO das System genutzt hatte. Erst durch die qualitative Analyse konnte eindeutig belegt werden, dass der entsprechende Nutzer das System niemals zu Kommunikationszwecken verwendet hatte. Ein Umstand, den sich die Entwickler zu Nutze gemacht hatten, aber der durch das simple Erheben von Benutzungsstatistiken nur schwer zu ermitteln ist. Schon an dieser kleinen Anekdote wird klar, dass jede Analysetechnik für sich selbst nicht aussagekräftig genug ist. Nur die Kombination verschiedener Techniken liefert ein umfassendes Bild. Weitere ernsthafte Anwendungen der Kombination der Analysemethoden sind das Ermitteln von Lead- oder Powerusern mittels SNA (vgl. [44, 45]), deren Anforderungen aufgrund ihrer Domänenkenntnisse eine besondere Wichtigkeit beigemessen werden kann. Zusammengenommen mit den Feedbackmethoden, die schon in youTell eingefügt wurden, können diese Daten zu mächtigen Analysewerkzeugen kombiniert werden, die das RE insgesamt erfolgreicher machen. Dienste zur Entscheidungsunterstützung. Für den einzelnen Benutzer stellt die Benutzung dieser Dienste natürlich eine weitere kognitiv herausfordernde Tätigkeit dar, so dass wir alle diese Dienste im Rahmen einer communitybewussten Weboberfläche integriert haben [33], die möglichst viele der Aufgaben der Teilhabe und der Beobachtung von RE Aktivitäten in einer Community mittels grafischer Webelemente miteinander in Beziehung setzt, ohne dass der Benutzer wesentliche Aufgaben der Konfiguration und Verwaltung dieser Bildschirmelemente übernehmen muss. Das aus dieser Vorarbeit resultierende communitybewusste Dashboard wurde in der folgenden Designstudie dem Gedanken folgend weiterentwickelt, dass das eigentliche dienstleistungsorientierte System (personalisierte Lernumgebung) schon eng mit dem adaptiven RE-Prozess integriert wurde.

Designstudie: Ein RE-Bazar für personalisierte Lernsoftware Mit der Entstehung von Web-basierten personalisierten Lernumgebungen (PLE) im Zuge der

Etablierung von Web-2.0-Technologien haben sich Tausende von heterogenen Lerngemeinschaften gebildet [8], deren individuelle Bedürfnisse nicht mehr traditionell über Anbieter von LearningManagement-Systemen (LMS), sondern durch eine Art Geschäft (engl.: Store) für einzelne Lerndienste oder gar ganze Dienstbündel abgedeckt werden, 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 Web2.0-Dienste dar, deren Funktionalität von ihren Anbietern heutzutage meist über sogenannte WebAPIs (Application Programming Interfaces) zur Verfügung gestellt werden. Beispiele für Widgets allgemeiner Natur sind webbasierte Kalender, Uhren und Mailklienten. Daneben finden sich speziell auf das Erlernen bestimmter Kompetenzen oder Metakompetenzen zugeschnittene Widgets. Ein Beispiel für eine Kompetenz ist die Beherrschung einer Fremdsprache. Ein Vokabeltrainer Widget unterstützt die Erlangung dieser Kompetenz. Ein Beispiel für ein Metakompetenz ist die Reflektion des eigenen Lernprozesses. Ein entsprechendes Widget zur Visualisierung des Lernfortschritts unterstützt die Reflektion. Da auch das informelle Lernen gerade im Angesicht der zunehmenden Verbreitung von Informations- und Kommunikationstechnologien nicht mehr von einzelnen Lernern allein, sondern zusammen mit anderen Lernern praktiziert wird, gehören zu webbasierten PLE auch Technologien, die das Verwalten einer Lerngemeinschaft realisieren, z. B. die informelle Selbstorganisation, die direkte Kommunikation unter Lernern, aber auch die entsprechenden Zugriffskontrollen in Bezug auf Authentifizierung und Autorisierung mittels Mechanismen wie OpenID [48] oder OAuth [49]. Dazu kommt ein Interoperabilitäts- und Kommunikationsrahmenwerk, welches den Austausch von Daten und Diensten zwischen verschieden webbasierten PLE möglichst in Echtzeit erlaubt, da in PLE genau wie in anderen fortgeschrittenen Web-2.0Systemen mittlerweile alle bekannten synchronen Kommunikationsformen erwartet werden [50]. Wegen des informellen Charakters des Lernens werden im Kontext von PLE zunehmend auch die Bedürfnisse nach Anleitung und Empfehlungen von Lernmaterialien, Lerndiensten und anderen Lernenden durch das zugrundeliegende System geäußert.

Ausgehend vom großen Erfolg des Apple Stores für iPhone Apps und seiner Akzeptanz bei den Nutzern liegt der Schritt zu einem WidgetStore nicht fern. Im Rahmen des EU-Projekts ROLE (Responsive Open Learning Environments; http://role-project.eu) wird auf Basis der im vorhergehenden Abschnitt beschriebenen Umgebung und ihrer Dienste ein ROLE-Store zur Unterstützung der Bedürfnisse verschiedenster Lerngemeinschaften entwickelt. In erster Linie dient der Store der Bereitstellung und Bündelung von Diensten und Widgets, sodass PLEs im Gegensatz zu der heutigen Situation für bestimmte Lernkonstellationen, z. B. den Erwerb einer Fremdsprache in einer Kleingruppe, einfach durch die Auswahl eines solchen Bündels erzeugt werden können. Zum anderen dient der Store aber auch der Kommunikation zwischen Entwickler- und Nutzercommunities. Das ROLE-Projekt setzt einen besonderen Akzent auf die Zusammenbringung und gegenseitige Bedienung von Anforderungen der Endnutzer und Entwickler von Lerntechnologien, insbesondere Widget-basierter PLE. In unserem Ansatz wenden wir das Storekonzept nicht nur auf Produkte nach ihrer Fertigstellung, sondern bereits in frühen Stadien der Ideenfindung auf Produktanforderungen an. Dazu vereinen wir das Storekonzept und unseren RE-Dienstebaukasten zu einem Bazar für das RE. Communities bestehend aus Endnutzern und Entwicklern entscheiden im Sinne einer darwinistischen Auslese selbst über ihre Feedback-, Verhandlungs- und Preisbildungsmechanismen, welche Inhalte verfügbar sind und welche nicht. So entsteht im Sinne der Open-SourceTradition [18] ein RE-Bazar, in dessen Rahmen Anforderungen als immaterielle Güter behandelt werden. Güter aller Art werden zwar nach Kategorien geordnet, aber am gleichen Platz angeboten. Der Preis der Güter wird üblicherweise in Verhandlungen ermittelt. Es herrscht eine hohe Konkurrenz zwischen Anbietern ähnlicher Produkte. Oftmals darf der Kunde am Produktentstehungsprozess teilhaben: „Neben den Läden, wo nur verkauft wird, gibt es viele, vor denen man zusehen kann, wie die Gegenstände erzeugt werden. So ist man von Anfang an dabei, und das stimmt den Betrachter heiter.“ (vgl. [51], Die Suks). Die Rollen der Teilnehmer unseres RE-Bazars sind jedoch durch die teils noch nicht gegebene Verfügbarkeit eines Produktes vorerst nicht durch die klassischen Rollen der Anbieter und Kunden gegeben. Vielmehr

{ DER BAZAR DER ANFORDERUNGEN

stellen alle Teilnehmer vorerst Interessenten dar, die den Bazar aus verschiedenen Motivationen (Produktfindung, Arbeitsfindung) besuchen und analysieren, um später für Produkte oder Produktverbesserungen mit guter Aussicht auf Markterfolg auf die Seite der Mitentwickler und Anbieter von Anforderungsumsetzungen zu wechseln. Die einzelnen Prozessbausteine des in Abb. 2 illustrierten i*-Modells können durch vielfältige und unterschiedliche Dienstbausteine aus unterschiedlichsten Quellen unterstützt werden. Diese Bausteine müssen jedoch im Sinne eines kohärenten und nachvollziehbaren RE-Prozesses nicht nur rein technisch, sondern auch praktisch im Verständnis der Communitymitglieder interoperabel sein. Wir haben die Anforderungsanalyse an das Community Requirements Engineering aus unserem i*-Modell genutzt, um Benutzerschnittstellen des RE Bazars unter Nutzung und Kombination verschiedener für das RE einsetzbarer Dienste (vgl. vorheriger Abschnitt) zu realisieren. Im Folgenden stellen wir kurz einige Designstudien für Benutzerschnittstellen der Komponenten des RE-Bazars vor, zeigen deren Verbindung zu den Modellelementen des in Abb. 2 skizzierten sozialen Softwaresystems auf und illustrieren anhand eines

Szenarios die Interaktionen von Endnutzern und Entwicklern mit dem Bazar. Um die aktuellen Anforderungen an bestehende oder an neue Lernwerkzeuge auf einen Blick sichtbar zu machen, bedienen wir uns der Konzepte des Dashboards und der Prioritätenliste angewandt auf Anforderungen. Das in Abb. 3 gezeigte RE-Dashboard verschafft den Mitgliedern einer bestimmten Community einen kompakten Überblick über die aktuellen Anforderungen in Form einer einfachen Prioritätsliste. Hierbei sei erwähnt, dass diese Listen nicht nur für bestimmte Communities, sondern beispielsweise auch für bestimmte Werkzeuge, Mitglieder oder auch komplett entkoppelt von jeglichen anderen Entitäten gebildet werden können. Für Endnutzer bietet diese Liste einen schnellen Überblick über die Beliebtheit aktuell diskutierter Anforderungen und insbesondere über die Beteiligung von Entwicklern, die ihre neuen Anforderungen auch realisieren könnten. Für Entwickler bietet die Liste wertvolle Informationen darüber, an welchen Anforderungsrealisierungen sie am ehesten mitarbeiten sollten, um die größte Wirkung zu erzielen, sei es in Form von nichtmateriellen Anreizen wie Imagegewinn, sich eröffnenden Jobchancen etc. [19] oder gar Verkaufszahlen im Falle von kommerziellen

Abb. 3 Communitybewusstes AnforderungsDashboard des ROLE-Store

Entwicklungen. Getreu dem Matthäus-Effekt [52] können diese Informationen bei aktiven Anforderungen zum Engagement weiterer Entwickler führen bzw. in Extremfällen bei geringer Aktivität bereits engagierte Entwickler zur Niederlegung ihres Arbeitsbeitrags zur Realisierung der Anforderung bewegen. In diesem Sinne stellt diese Liste durch ihre Prioritätsordnung ein wichtiges Hilfsmittel zur Entscheidung über Anforderungsrealisierungen dar. Über den Knopf Add new in der linken oberen Ecke können Nutzer des RE-Stores explizit neue Anforderungen in das System einstellen. Über das ebenfalls links oben angedeutete Suchfeld können Nutzer gezielt nach bestimmten schon existierenden Anforderungen suchen (z. B. Volltext-Suche, Tag-basierte Suche, etc.). Die Suche dient u. a. der Vorbeugung unnötiger Doppeleinträge und der Bestätigung der Nutzer im Sinne dass andere bereits gleiche oder ähnliche Anforderungen artikuliert haben. Jedes Element einer solchen Liste repräsentiert eine bestimmte Anforderung. Für jede Anforderung werden folgende Zusatzinformationen visualisiert (s. Abb. 3 von links nach rechts). Der Titel ist mit

einer Unterseite verlinkt, die einen detaillierten Überblick über die jeweilige Anforderung bietet. Eine solche Seite wird in Abb. 4 unten weiter beschrieben. Zur Kategorisierung wird die in Web2.0-Systemen gängige Verschlagwortung (engl.: Tagging) genutzt. Ein Aktivitätsindikator ähnlich einem Batteriefüllstandanzeiger zeigt ein Aggregat der aktuellen Aktivität um eine Anforderung, z. B. Kommunikationsaktivität, Entwicklungsaktivität, etc. an. Ein Graph zeigt für bereits teilweise umgesetzte Anforderungen deren aktuelle Benutzung in aggregierter Form über die Zeit. Diese Information wird aus Aufzeichnungen der Systemnutzung gespeist, die durch Monitoringdienste erhoben werden. Des Weiteren werden die Anzahl von Unterstützern und beteiligten Entwicklern der jeweiligen Anforderung gelistet. Neben den aus dem Systembetrieb beobachtbaren Maßen bietet der REStore auch die Möglichkeit der expliziten Bewertung einer Anforderung durch Communitymitglieder. Hierbei bedienen wir uns der im Web 2.0 gängigen Techniken des Collaborative Filtering, wobei wir neben typischen auf Durchschnitt oder Me-

Abb. 4 Detaillierte Übersichtseite über Anforderung im ROLE-Store

{ DER BAZAR DER ANFORDERUNGEN

dian vieler Einzelwertungen basierenden Maßen auch Preisbildungsmechanismen [53] als kumulative Maße integrieren, um somit eine zusätzliche Dimension der Priorisierung zu geben. Alle Informationen über Nutzung, Aktivität, Teilnahme am Diskussions- und Entwicklungsprozess, Bewertungen etc. geben sowohl implizit als auch explizit Auskunft über bereits getroffene Entscheidungen bzgl. der Anforderungsrealisierung. Unter der Liste wird mit drei verschiedenen Schiebereglern angedeutet, dass der Einfluss der verschiedenen Analysetechniken individuell gewichtet werden kann. Eine neue Gewichtung kann dabei Einfluss auf die Sortierung der Liste nehmen. Alle Analysetechniken werden ebenfalls durch entsprechende Dienste getrieben und basieren auf communitygenerierten Inhalten, Monitoringdaten und explizit abgegebenen Bewertungen. Wählt ein Communitymitglied ein Element aus der in Abb. 3 gezeigten Liste, so gelangt er auf eine Übersichtsseite, die umfassende Informationen zu einer bestimmten Anforderung bietet. Abbildung 4 zeigt eine solche Seite für eine Anforderung eines bereits existierenden Werkzeugs. Neben detaillierter Visualisierungen der bereits in der Liste in Kompaktform genutzten Elemente beinhaltet diese Seite den Zugang zu aktuellen Nutzungsstatistiken bei existierenden Werkzeugen, einen Überblick über die soziale Struktur der sich um die Anforderung gebildeten Gruppe von Nutzern und Entwicklern sowie die Möglichkeit des Beitritts zur Entwicklergruppe. Weiterhin sind im unteren Bereich der Seite Möglichkeiten der anforderungszentrierten Kommunikation mithilfe integrierter Kommunikationsdienste gegeben. Das wohlbekannte Konzept eines Multiuserchatraums mit persistiertem Konversationslog ist hierfür bestens geeignet, da sowohl asynchrone als auch synchrone Kommunikation in Echtzeit nachvollziehbar umgesetzt sind. Das folgende Szenario im Kontext Widgetbasierter PLE soll die Interaktion von Endnutzern und Entwicklern mit dem RE Bazar näher illustrieren. Ein Firmenmitarbeiter in der Rolle des Endnutzers stellt bei der häufigen Nutzung seines PLE zum Erlernen der spanischen Sprache fest, dass ein bisher von ihm und vielen anderen Kollegen oft genutztes Vokabeltrainer Widget keine Möglichkeit bietet, die fremdsprachigen Begriffe zum Zwecke der Verbesserung der eigenen Aussprache

von Muttersprachlern vorlesen zu lassen. Im ROLEWidget-Store sucht er daraufhin nach alternativen Vokabeltrainer-Widgets, die aber alle keine Vorlesefunktion bieten. Es existiert also für ihn eine neue Anforderung einer Produktverbesserung, die er nun im RE-Bazar artikulieren möchte. Unter der Annahme, dass seine Anforderung bereits von anderen geäußert wurde, sucht er mithilfe einer Tag-basierten Anfrage nach ähnlichen Anforderungen und wird fündig. Auf den ersten Blick erkennt er, dass bereits viele andere Nutzer ihr Interesse an der Umsetzung seiner Anforderung in Form einer direkten hohen Bewertung (z. B. 5-Sterne-Skala, fiktives Preisgebot) bekundet haben. Weiterhin stellt er die rege Beteiligung einer Gruppe von Entwicklern fest, die sich zur Umsetzung der Anforderung entschlossen haben. Eine Visualisierung der Nutzungsstatistiken des Vokabeltrainer-Widgets stellt eine hohe Anfragefrequenz vieler Nutzer dar und demonstriert so u. a. die Beliebtheit des Werkzeugs. Eine SNA-Visualisierung der Kommunikation zwischen Unterstützern und Entwicklern der Anforderung zeigt ein dichtes Netz zwischen den Entwicklern, ein weniger dichtes Netz zwischen den Endnutzern sowie zahlreiche Verbindungen zwischen beiden Gruppen. Weiterhin sind in beiden Gruppen einige extrem stark vernetzte Mitglieder als potentiell wichtige Ansprechpartner erkennbar. Die Kommunikation der Community um diese Anforderung scheint also vielversprechend. Der Endnutzer möchte die Umsetzung der Anforderung weiter unterstützen, gibt dazu seine Bewertung ab und steigt in die Kommunikation mit anderen Unterstützern und Entwicklern ein. Ein ambitionierter Open-Source-Entwickler auf dem Gebiet der Anwendungsentwicklung für Sprachtraining interessiert sich für neue Aufgaben, die sich an aktuellen Bedürfnissen der Community der Sprachlerner orientieren sollen. Auf Anhieb entdeckt er in der Prioritätenliste die Anforderung nach Sprachunterstützung im Vokabeltrainer-Widget mit hohem Stellenwert. Nach Betrachtung der Nutzungsstatistiken, Bewertungen und der Communitystruktur um die Anforderung entschließt er sich, dem Entwicklerteam beizutreten. Zusätzlich kommt ihm die Idee, die Sprachunterstützung auf genereller Basis als Text-To-Speech-(TTS)-Widget für verschiedene Sprachen zu realisieren. Er fügt dem RE-Bazar eine entsprechende neue Anforderung eines neuen Produktes hinzu und diskutiert diese mit den anderen Entwicklern und Endnutzern der ursprünglichen

Anforderung einer Produkterweiterung. Im Endeffekt resultiert die vergleichende Diskussion beider Ansätze in einer Präferenz für ein separates TTSWidget, dessen Funktionalität der Sprachsynthese von anderen Widgets extern angestoßen werden kann. Der RE-Store soll nach seiner erfolgreichen Evaluierung in Workshops und Vorstudien zur Implementierung von PLE als Grundlage dienen, den bisherigen von vorhandener öffentlicher Förderung abhängigen Entwicklungsprozess von PLEs in einen nachhaltigen communitygestützten Open-Source-Entwicklungsprozess zu überführen.

Schlussbemerkungen Traditionelles RE ist auf die Ermittlung, Festschreibung und Nachvollziehbarkeit von Anforderungen in den Informationssystemen einer Organisation fokussiert. Die auch durch die fortschreitende Globalisierung vorangetriebene Vernetzung hat neue Formen der Zusammenarbeit und der informationstechnischen Lösungen zu deren Unterstützung hervorgebracht. In zwei Fallstudien, offenen Innovationsprozessen in der Bioinformatik und personalisierten Lernumgebungen haben wir die neuen Anforderungen an ein adaptives RE für emergente Communities in einem Prozessablauf verdeutlicht. Zur informatischen Unterstützung haben wir ein i*-Modell entwickelt für die Beschreibung der wechselseitigen Abhängigkeiten zwischen den Communities und den von ihnen genutzten Informationssystemen aus der Sichtweise des adaptiven RE. Unsere Idee ist es, das adaptive RE durch einen Dienstbaukasten zu unterstützen, der in solche Informationssysteme integriert werden kann. Dadurch entsteht im Sinne der Open-Source-Bewegung ein Bazar von Anforderungen. Diesen Vorgang haben wir prototypisch als RE-Bazar in einen Store für webbasierte Widgets zur Gestaltung von personalisierten Lernumgebungen umgesetzt. Bisherigen Ansätzen, die auf Ideen des Web 2.0 beruhen, wird damit ein Mechanismus zur Verfügung gestellt, der durch erfolgreiche Stores bewiesen hat, eine Vielzahl von Entwicklern und Anwendern zusammenbringen zu können. Damit ist eine Übertragung in den Kontext interorganisationaler Informationssystementwicklung wahrscheinlicher geworden. Ähnlich wie in anderen Wirtschaftszweigen, in denen Zertifikate für Luftverschmutzung oder Energieüberschüsse gehandelt werden, können Unternehmen Anfor-

derungen an ihre Informationssysteme ermitteln, bewerten und sogar realisieren lassen. Damit entstehen ganz neue Geschäftsmodelle für die Entwicklung von Informationssystemen die einer globalisierten und vernetzten Welt gerecht werden. Ein Beispiel hierfür sind junge Unternehmen am Markt, die noch keine Ressourcen für den Aufbau einer Entwicklungsabteilung haben und am Markt wegen ihres hohen Innovationstempos nur schwer traditionelle IT-Dienstleister für komplexe und mit hohem Änderungsbedarf versehene Projekte finden können. In der zukünftigen Forschung wird neben der informatischen Unterstützung natürlich auch die interdisziplinäre Erforschung dieser Prozesse eine große Rolle spielen. Insbesondere sind neben den schon erwähnten Geschäftsmodellen auch die Fragen nach Barrieren im Innovationsprozess wichtig. Oft wird gerade in Open-Source-Communities Stagnation und Innovationsfeindlichkeit beobachtet. Die Gründe dafür liegen in den emergenten sozialen Strukturen, in denen eine Clique von etablierten Mitgliedern auf Kosten der Innovation ihre Macht ausbaut. Das Establishment solcher innovationsfeindlicher Kulturen kann durch interdisziplinäre Grundlagenforschung unter Ausnutzung neuerer Methoden der ,,Computational Socioeconomics“ analysiert und verstanden werden.

Danksagungen Diese Arbeit wurde von der DFG in den Forschungsprojekten CONTICI und UMIC sowie von der EU im Forschungsprojekt ROLE unterstützt. Die Autoren bedanken sich bei allen Kollegen in diesen Projekten für die zahlreichen Diskussionen und Beiträge.

Literatur 1. Hagel J, Brown JS (2005) The Only Sustainable Edge: Why Business Strategy Depends on Productive Friction and Dynamic Specialization. Harvard Business School Press, Boston 2. Chesbrough HW (2003) Open Innovation. The New Imperative for Creating and Profiting from Technology. Harvard Business School Press, Boston 3. Bächle M (2008) Ökonomische Perspektiven des Web 2.0 – Open Innovation, Social Commerce und Enterprise 2.0. Wirtschaftsinformatik 50(2):129–132 4. Muraschko I (2009) Cross-Community Communication Analysis and its Implications for Requirements Engineering and Project Management. Masterarbeit. RWTH Aachen 5. Barcellini F, Détienne F, Burkhardt JM (2007) Cross-Participants: Fostering DesignUse Mediation in an Open Source Software Community. In: Proceedings of the ECCE 2007 Conference, London, 28–31 Aug 2007 6. Bird C, Pattison D, D’Souza R, Filkov V, Devanbu P (2008) Latent Structure in Open Source Projects. In: Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of Software Engineering, Georgia, pp 24–35 7. Girvan M, Newman MEJ (2002) Community Structure in Social and Biological Networks. 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, and Learning 2.0. EDUCAUSE Rev 43(1):16–32

{ DER BAZAR DER ANFORDERUNGEN

9. Anderson C (2006) The Long Tail: Why the Future of Business Is Selling Less of More. Hyperion, New York 10. O’Reilly T (2005) What Is Web 2.0 – Design Patterns and Business Models for the Next Generation of Software. http://www.oreillynet.com/lpt/a/6228, letzter Zugriff 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 change of 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, Organizations and States. Cambridge, MA 14. Sutcliffe AG (1995) Requirements Rationales: Integrating Approaches to Requirement Analysis. Symposium on Designing Interactive Systems, pp 33–42 15. von Hippel E (1986) Lead Users: A Source of Novel Product Concepts. Manag Sci 32(7): 791–805 16. Lilien GL, Morrison PD, Searls K, Sonnack M, von Hippel E (2003) Performance Assessment 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 Adaptive Systems. In: Proceedings 31st Annual International Computer Software and Applications 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“ userto-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-Source Software. 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: an Information System Design Methodology. In: 6th IEEE/ACIS International Conference 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 requirements engineering. In: Münch J, Liggesmeyer P (Eds) Software Engineering 2009 – Workshopband, 20–24 Sep 2009, Kaiserslautern, pp 309–315 24. Decker B, Ras E, Rech J, Jaubert P, Rieth M (2007) Wikibased stakeholder participation in requirements engineering. IEEE Softw 24:28–35 25. Heß J, Offenberg S, Pipek V (2008) Community-Driven Development as participation? – Involving User Communities in a Software Design Process. In: Participatory Design Conference, Bloomington 26. Castro-Herrera C, Cleland-Huang J, Mobasher B (2009) Enhancing stakeholder profiles to improve recommendations in online requirements elicitation. In: IEEE International Conference on Requirements Engineering, Atlanta, pp 37–46 27. Baeza-Yates R, Calderón-Benavides L, González-Caro C (2006) The intention behind web queries. In: Crestani F, Ferragina P, Sanderson M (Eds) Proceedings of String 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 Query Logs Capture Knowledge about Common Human Goals? In: The Fifth International Conference on Knowledge Capture, Redondo Beach, 1–4 Sep 2009 29. Kroell M, Strohmaier M (2009) Analyzing Human Intentions in Natural Language Text. In: The Fifth International Conference on Knowledge Capture, Redondo Beach, 1–4 Sep 2009 30. Yu E (1997) Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering. In: Proceedings 3rd IEEE Int. Symp. on Requirements Engineering, Washington D.C., 6–8 Jan 1997, pp 226–235

31. Bryl V, Giorgini P, Mylopoulos J (2009) Designing socio-technical systems: from stakeholder goals to social networks. Requirem Engin 14(1):47–70 32. Hannemann A, Hocken C, Klamma R (2009) Community Driven Elicitation of Requirements 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 Engineering. Diplomarbeit. RWTH Aachen 34. Chatterjee A, Law E, Verbert K (2009) EU FP7 IP ROLE (Responsive Open Learning Environments) Deliverable 1.3/4: Functional and non-functional requirements analysis and specification. Fraunhofer-Institut für Angewandte Informationstechnik FIT, Sankt Augustin 35. Wenger E (1998) Communities of Practice: Learning, Meaning, and Identity. Cambridge 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: Manolopoulos Y et al (eds) Proceedings of the International Conference on Enterprise Information Systems, ICEIS 2006, Paphos 38. Spaniol M, Klamma R, Janssen H, Renzel D (2006) LAS: A Lightweight Application Server for MPEG-7 Services in Community Engines. In: Tochtermann K, Maurer H (eds) Proceedings of I-KNOW ’06, 6th International Conference on Knowledge Management, 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 Games at EC-TEL 08, Maastricht 40. Sharda N (2005) Movement Oriented Design: A New Paradigm for Multimedia Design. Intern J Lat Comp 1:7–14 41. Dey A (2001) Understanding and Using Context. Pers Ubiquitous Comp 5(1):4–7 42. Renzel D, Klamma R, Spaniol M (2008) MobSOS – A Testbed for Mobile Multimedia Community Services. In: 9th International Workshop on Image Analysis for Multimedia 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 the Eclipse Open Source Community with Performance and Creativity. Comp Math Organ Theory 13(1):17–27 45. Roger EM (1983) Diffusion of Innovations. Free Press, New York 46. Google Inc.: OpenSocial Specification 1.1 DRAFT. http://opensocial-resources. googlecode.com/svn/spec/1.1/OpenSocial-Specification.xml, letzter Zugriff 16.10.2010 47. Cáceres M (2009) Widget Packaging and Configuration. W3C Candidate Recommendation. http://www.w3.org/TR/2009/CR-widgets-20091201/, letzter Zugriff 16.10.2010 48. Recordon D, Hoyt J, Bufu J, Fitzpatrick B, Hardt D, et al (2007) OpenID Authentication 2.0 – Final Specification. http://openid.net/specs/openid-authentication2_0.html, letzter Zugriff 16.10.2010 49. Hammer-Lahav E, Recordon D, Hardt D (2010) The OAuth 2.0 Protocol. IETF Draft Standard. http://tools.ietf.org/html/draft-ietf-oauth-v2-10, letzter Zugriff 16.10.2010 50. O’Reilly T, Batelle J (2009) Web Squared: Web 2.0 Five Years On. Web 2.0 Summit Special Report. http://assets.en.oreilly.com/1/event/28/web2009_websquaredwhitepaper.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–63 53. Keen PGW (1981) Value Analysis: Justifying Decision Support Systems. MIS Quart 5(1):1–16