Wiki im Requirements-Engineering
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Daniel Taudien Wiki im Requirements-Engineering Hausarbeit – Software-Engineering D. Taudien, D.Taudien@gmx.de, Matrikel-Nr. 268783 25.06.2011
Inhaltsverzeichnis
Inhaltsverzeichnis ................................................................................................................................ I
Abkürzungsverzeichnis ..................................................................................................................... II
Abbildungsverzeichnis .................................................................................................................... III
Wiki im Requirements-Engineering ............................................................................................. 1
1. Einleitung ........................................................................................................................................... 1
1.1. Problemstellung und Zielsetzung ..................................................................................... 1
1.2. Vorgehensweise ...................................................................................................................... 3
2. Requirements-Engineering ........................................................................................................ 3
2.1. Anforderungserhebung und -anlyse ............................................................................... 4
2.2. Requirements-Management ............................................................................................... 6
3. Wiki Wiki Web.................................................................................................................................. 8
3.1. Standardfunktionen aller Typen von Wikis ................................................................. 9
3.2. Semantische Wikis ...............................................................................................................11
4. Wiki im Requirements-Engineering ......................................................................................13
4.1. Anforderungserhebung und –analyse mit einem Wiki ..........................................13
4.2. Requirements-Engineering mit einem semantischen Wiki..................................15
5. Fazit ....................................................................................................................................................16
Literaturverzeichnis .........................................................................................................................18
IAbkürzungsverzeichnis
Abb. Abbildung
d.h. das heißt
et al. et alii
f. folgende (Seite)
ff. fortfolgende
Hrsg. Herausgeber
i.d.R. in der Regel
i.e.S. im engeren Sinn
i.w.S. im weiteren Sinn
o.g. oben genannten
RE Requirements-Engineering
RM Requirements-Management
S. Seite
Vgl. Vergleiche
IIAbbildungsverzeichnis
Abbildung 1: Projekterfolgsquoten .............................................................................................. 2
Abbildung 2: Requirements-Management ................................................................................. 6
III-
1. Einleitung
1.1. Problemstellung und Zielsetzung
Software gestützte Systeme machen nicht immer das, was sie sollen. Hierbei kann
es sich um vergleichsweise harmlose Fälle handeln wie beispielsweise die Ober-
bürgermeister Wahl in Neu-Ulm 1994, bei der die Wahlbeteiligung mit 104% aus-
gewiesen wurde um danach festzustellen, dass es sich um eine Verdopplung auf-
grund eines Software-Fehlers gehandelt hat. Es können aber auch wirtschaftliche
Schäden entstehen, wie zum Beispiel bei dem Projekt „Fiscus“ der deutschen Fi-
nanzverwaltung mit ca. 900 Millionen Euro Lehrgeld.1 Schwerwiegender sind je-
doch die Fälle, bei denen es um das Leben von Menschen geht. Zu nennen ist hier
unter anderem ein Fehler in der Software bei Passagierflugzeugen.2
Diese Fehlverhalten sind keine neuen Probleme, sondern sie sind bereits in den
60er Jahren aufgetreten. Der Versuch einer Lösung ist die ingenieurmäßige Vorge-
hensweise in Software-Projekten und somit die Geburtsstunde des Software-
Engineering. Schon in dieser Zeit wurde erkannt, dass es sich bei einem Software-
Projekt um i.d.R. komplexe Projekte handelt.3 Aus diesem Grund wird der Fokus
der Arbeit auf komplexe Projekte gerichtet, bei der Nutzung in kleinen Projekten
können einzelne Bausteine herausgenommen werden, so dass eine Anwendung
erfolgen kann.
Trotz der Entwicklung von Methoden und Modellen in den letzten Jahren im Soft-
ware-Engineering sind Software-Projekte immer noch mit großen wirtschaftlichen
und technischen Risiken behaftet, welche ihre Ursache häufig in einem mangeln-
den Requirements-Engineering haben.4
1 Vgl. Partsch 2010 /Requirements-Engineering/ S. 1.
2 Vgl. Partsch 2010 /Requirements-Engineering/ S. 2.
3 Vgl. Partsch 2010 /Requirements-Engineering/ S. 2.
4 Vgl. Pohl 2010 /Requirements-Engineering/ S. 6; Kittlaus, Rau, Schulz 2004 /Software-Produkt-
Management/ S. 96.
1Abbildung 1: Projekterfolgsquoten5
Somit können Verbesserungen in diesem Bereich eine signifikante6 Verbesserung
der gesamten Erfolgsquote herbeiführen.
Auch die Entwicklung des ersten Wiki ist im Rahmen eines Software-Projektes ent-
standen und hatte zum Ziel die Abstimmung zwischen Programmierern zu erleich-
tern. Es sollte Software-Code direkt ins Wiki geschrieben und dieser durch andere
Programmierer geprüft und ergänzt werden. Dabei lag der Fokus auf einer einfa-
chen Bedienung. Aufgrund von Wikipedia und der Entdeckung der Anwendbarkeit
in den verschiedensten Bereichen ist das Wiki-Konzept mittlerweile einem breiten
Publikum bekannt geworden.7 Somit kann davon ausgegangen werden, dass für
die Anwender8 ein Wiki ein gut zu nutzendes Werkzeug ist.
Auf Basis dieser Grundlage ist somit die Erweiterung der Nutzung für das Requi-
rements-Engineering zu prüfen und das Wiki aus dem Bereich der Programmierer
auch den Anwendern in einem Software-Projekt zur Verfügung zu stellen. Die Ziel-
setzung dieser Arbeit liegt somit in der Prüfung, ob ein Wiki im Bereich des Requi-
rements-Engineering Möglichkeiten bietet, eine Verbesserung zu erreichen und
einen Beitrag zum Erfolg von Software-Projekten zu leisten.
5 Quelle: Partsch 2010 /Requirements-Engineering/ S. 5.
6 Signifikant, da bei der Behebung von Problemen in diesem Bereich ein Großteil der Probleme in
Software-Projekten behoben ist. Vgl. zur Häufigkeit der Probleme Pohl 2010 /Requirements-
Engineering/ S. 6; Kittlaus, Rau, Schulz 2004 /Software-Produkt-Management/ S. 96.
7 Vgl. Ebersbach et al. 2008 /Wiki/ S. 15 f.
8 Unter Anwender soll im Folgenden ein Nutzer eines IT-Systems verstanden werden der keine
Programmier- oder IT-spezifische Ausbildung hat.
21.2. Vorgehensweise
Für diese Prüfung werden im folgenden Kapitel 2 die Aufgaben und Probleme des
Requirements-Engineering beschrieben. Kapitel 3 beschäftigt sich mit dem Wiki
und den Möglichkeiten dieses Werkzeugs. Hierbei erfolgt eine Beschränkung auf
die im Requirements-Engineering relevanten Bestandteile. In Kapitel 4 wird die
Zusammenführung erfolgen, so dass klar wird, an welcher Stelle eine Verbesserung
möglich ist und an welcher Stelle es noch Probleme gibt.
2. Requirements-Engineering
Das Requirements-Engineering (RE) umfasst die systematische Erhebung, Analyse,
Spezifikation, Validierung und Verwaltung von Anforderungen an eine Software.9
Naturgemäß sind die Anforderungen zunächst unscharf, mehrdeutig, unvollständig
und teilweise widersprüchlich definiert. Die Aufgabe des RE ist es diese aufzube-
reiten und präzise, eindeutig, konsistent und vollständig zu erfassen.10
Hierbei ist es sinnvoll RE zum Entwurf im Software-Engineering abzugrenzen, wo-
bei dies durchaus umstritten ist. Dies ist nach Ansicht des Verfassers jedoch not-
wendig, da nur so eine klare Vorstellung der Aufgaben und Tätigkeiten möglich ist.
Im Folgenden soll die Unterscheidung wie folgt verstanden werden: Das Require-
ments-Engineering beschreibt das „Was“, also die Anforderung an die Software.
Der Entwurf beschreibt das „Wie“, somit die Umsetzung im System.11 Demzufolge
ist das RE eher am Anwender ausgerichtet.
Die Ermittlung der Anforderungen erfolgt grundsätzlich iterativ, in einem Prozess
mit Rückkopplungsschleifen.12 Die dabei entstehenden Dokumente und andere
Informationsträger, sind innerhalb des Projektverlaufs nachzuverfolgen. D.h. es ist
eine Verwaltung der Anforderungen notwendig. Diese Tätigkeit kann zusammen-
9 Vgl. Geisser et al. 2007 /Wikis/ S. 3.; Sommerville 2001 /Software-Engineering/ S. 122.
10 Vgl. Partsch 2010 /Requirements-Engineering/ S. 20.
11 Vgl. Partsch 2010 /Requirements-Engineering/ S. 21 f.
12 Vgl. Zuser, Grechenig, Köhle 2004 /Software Engineering/ S. 225.
3gefasst werden zum Requirements-Management.13 Dabei ist zu berücksichtigen,
dass die Überprüfung der Einhaltung der Anforderungen nach der Programmie-
rung, nicht mehr in dem Bereich des Requirements-Managements und somit auch
nicht in den Bereich des RE fällt.14
Die o.g. Tätigkeiten Anforderungserhebung und –analyse, sowie die Verwaltung
derselben sind bei der Überprüfung der Nutzung eines Wiki zur Unterstützung zu
berücksichtigen.15 Hierzu werden im Folgenden diese Tätigkeiten näher betrachtet
und stellen somit die Rahmenbedingungen16 dar.
2.1. Anforderungserhebung und -anlyse
Der erste Schritt im RE-Prozess ist i.d.R.17 die initiale Erhebung der Anforderung.18
Es kann durch den iterativen Verlauf des RE jedoch vorkommen, dass aus einer
späteren Phase die Erhebung der Anforderung erneut durchlaufen wird. 19 Der RE-
Prozess wird gestartet durch ein initiales Treffen des Projektteams. Dies ist im
kleineren Projekten an einem Standort relativ einfach, bei großen Projekten und
heterogenen Standorten kommt diesem Prozess eine große Bedeutung zu, da si-
cher gestellt werden muss, dass alle Beteiligten den notwendigen Informations-
stand haben.20 Nach Erfahrungen des Verfassers ist die Notwendigkeit der Sicher-
stellung eines einheitlichen Informationsstandes jedoch auch an einem Standort
nicht zu vernachlässigen.
Ab dem Start der Ermittlung der Anforderungen ist es möglich, dass sich die An-
wender nicht im Klaren sind, wie die Anforderung und der Bedarf tatsächlich aus-
sehen. Ein Grund hierfür kann sein, dass sie nicht in der Lage sind ihr implizites
13 Vgl. Partsch 2010 /Requirements-Engineering/ S. 22 f.
14 Vgl. Partsch 2010 /Requirements-Engineering/ S. 23.
15 Vgl. grundsätzlich zu Werkzeugen im Requirements-Engineering Partsch 2010 /Requirements-
Engineering/ S. 61 ff.
16 Rahmenbedingungen können an dieser Stelle synonym zu einer Eingrenzung verstanden werden.
17 Aufgrund der verschiedenen Vorgehensmodelle im Software-Engineering kann es Ausnahmen
geben, diese haben jedoch keinen Einfluss auf die Konzeption. Vgl. zu den verschiedenen Vorge-
hensmodellen Sommerville 2001 /Software-Engineering/ S. 44 ff.
18 Vgl. Geisser et al. 2007 /Wikis/ S. 4 f.
19 Vgl. zum iterativen Verlauf Partsch 2010 /Requirements-Engineering/ S. 39.
20 Vgl. Geisser et al. 2007 /Wikis/ S. 4 f.
4Wissen zu explizieren. Die Folge daraus ist, dass die Anwender zwar instinktiv
richtig arbeiten, es jedoch schwierig ist dies verbal zu beschreiben.21
Ein weiteres Hindernis kann sein, dass innerhalb der Anwender nicht klar ist, was
gewollt ist. D.h. es gibt unterschiedliche Meinungen und somit keine einheitliche
Anforderung. Dies zu priorisieren und eine Schnittmenge zu bilden stellt sich als
eine schwierige Aufgabe dar.22
Um somit die Anforderungen verständlich und umfassend zu beschreiben sollten
sich die Entwickler und Anwender zusammensetzen und so die Anforderung ge-
meinsam definieren. Hierbei kann jeder Bereich seine spezifischen Fragen stellen
und mit seinem spezifischen Wissen die Anforderung erweitern. So wächst der
Detaillierungsgrad der Anforderung sukzessive an.23 Des Weiteren ist zu berück-
sichtigen, dass im Allgemeinen durch die Diskussion neue Erkenntnisse entstehen,
die weiter verarbeitet werden können. Am Ende kann sodann entschieden werden,
ob die Anforderung gültig und der Erstellungsprozess abgeschlossen ist.24
Demgegenüber gibt es auch Probleme, wenn der Entwickler und der Anwender
eine unterschiedliche Sprache sprechen.25 D.h. es gibt eine unterschiedliche Ver-
wendung von Fachtermini. Dies entsteht oft in Software-Projekten, da von Seiten
der Entwickler oft künstliche Sprachen verwendet werden, wohingegen die An-
wender die natürliche Sprache verwenden.26 Den Fachtermini kommt aus diesem
Grund eine besondere Bedeutung zu. Im Zuge der Kommunikation zwischen den
Anwendern und Entwicklern und der späteren Dokumentation ist eine einheitliche
Begrifflichkeit anzustreben. Um dies zu erreichen ist es somit erforderlich ver-
wendete Termini, die nicht dem regulären Sprachgebrauch entsprechen, zu defi-
21 Vgl. Goeken 2006 /Data-Warehouse-Systeme/ S. 115.
22 Vgl. Goeken 2006 /Data-Warehouse-Systeme/ S. 115.
23 Vgl. Koschek 2011 /Anforderungsermittlung/ S. 81.
24 Vgl. Koschek 2011 /Anforderungsermittlung/ S. 85.
25 Vgl. Koschek 2011 /Anforderungsermittlung/ S. 80.
26 Vgl. Goeken 2006 /Data-Warehouse-Systeme/ S. 115.
5nieren.27 Der Verfasser sieht an dieser Stelle jedoch auch die Notwendigkeit regu-
läre Termini zu beschreiben, soweit dies der Verständlichkeit nützlich ist.
2.2. Requirements-Management
Das Requirements-Management (RM) sorgt dafür, dass die Anforderungen auf dem
aktuellen Stand sind und alle am Projekt beteiligten Personen die für sie notwen-
digen Informationen verfügbar haben. Dabei fokussiert sich das RM auf die Infor-
mation, nicht auf das Dokument. Das bedeutet, dass alle relevanten Informationen
an einer zentralen Stelle verfügbar sein müssen.28 Dies erfüllt sodann die Verfüg-
barkeitsbedingung notwendiger Informationen für die im Projekt tätigen Perso-
nen.29 Eine Übersicht der Bereiche des RM ist in Abb. 2 dargestellt.
Abbildung 2: Requirements-Management30
Das RM hat die Aufgabe sicherzustellen, dass die Identifizierbarkeit gewährleistet
ist. Dies bedeutet, dass Zuordnungen zu einzelnen Detailinformationen stimmig
sind und Nummerierungen nicht redundant sind. Sollte eine Anforderung nicht
weiter verfolgt werden, so ist die Nummer zu löschen und die anderen Nummern
27 Vgl. zur Notwendigkeit klarer Terminologien Goeken 2006 /Data-Warehouse-Systeme/ S. 270 ff.,
der diese Tätigkeit dem Terminologiemanagement zuordnet.
28 Vgl. Hood et al. 2008 /Requirements Management/ S. 35 f.
29 Vgl. hierzu Kapitel 2.1.
30 Quelle: Partsch 2010 /Requirements-Engineering/ S. 22.
6sind anzupassen. Hierbei ist darauf zu achten, dass dies durchgängig erfolgt. 31 Dies
ist erforderlich, da auch in Software-Projekten nichts so beständig ist, wie der
Wandel. Dieser kann ausgelöst werden durch äußere Ereignisse, wie die Finanz-
krise oder durch innere Ereignisse, wie personelle Veränderungen, neue Erkennt-
nisse oder eine Neuausrichtung des Unternehmens.32
Zusätzlich zur Identifizierbarkeit ist die Filtrierbarkeit wichtig, aufgrund der Not-
wendigkeit, dass jede Person nur die für sie relevanten Informationen erhält, ist es
erforderlich, dass Informationen gefiltert werden können. Beispielsweise möchte
ein Test Manager andere Informationen haben als ein Projekt Manager. Die Filt-
rierbarkeit bezieht sich aber auch auf die möglichen verschiedenen Versionen der
Spezifikation33 einer Anforderung und des hiermit zusammenhängenden Ent-
scheidungsprozesses34 im Projektverlauf. Auch hier ist eine Filtrierung notwendig.
Dabei ist zu berücksichtigen, dass Berechtigungskonzepte abzubilden sind. Bei kri-
tischen Informationen muss es möglich sein, diese nur für bestimmte Personen
freizugeben.
Wie bereits beschrieben ist die Nachverfolgbarkeit eine Basisvoraussetzung für
das RE.35 Die Nachverfolgbarkeit kann mindestens in zwei Bereiche eingeteilt wer-
den. Zum einen in eine Nachverfolgung von einer spezifischen Anforderung im
Zeithorizont und zum anderen in die Nachverfolgung einer spezifischen Anforde-
rung von unterschiedlichen Personen. Beispielsweise in die Beschreibung der An-
forderung eines Anwenders und die Anforderungsbearbeitung eines Entwicklers.
Dies erfordert somit eine bidirektionale Verknüpfung der Daten.36 Die gesamte
Nachverfolgbarkeit dient im Projekt der Vollständigkeitskontrolle, der Statusver-
folgung und der Ermittlung der Auswirkungen von Änderungen.37
31 Vgl. Hood et al. 2008 /Requirements Management/ S. 36.
32 Vgl. Koschek 2011 /Anforderungsermittlung/ S. 80.
33 Vgl. Hood et al. 2008 /Requirements Management/ S. 36.
34 Vgl. Geisser et al. 2007 /Wikis/ S. 8.
35 Vgl. Goeken 2006 /Data-Warehouse-Systeme/ S. 272 f.; speziell zum Change Management vgl.
Balzert 2008 /Softwaremanagement/ S. 429 f.
36 Vgl. Hood et al. 2008 /Requirements Management/ S. 36 f.
37 Vgl. Goeken 2006 /Data-Warehouse-Systeme/ S. 272 f.
73. Wiki Wiki Web
Der Name Wiki38 stammt von dem hawaiischen Wiki Wiki ab, dies bedeutet
schnell.39 Es geht somit um das schnelle unkomplizierte zur Verfügung stellen von
Informationen. Der Name Wiki wird im Folgenden verstanden als die Software
selbst im Zusammenhang mit dem Wiki-Konzept der kooperativen Sammlung, Or-
ganisation und Bereitstellung von Informationen.
Grundsätzlich kann man Wikis für geschlossene Arbeitsgruppen oder für beliebige
Anwender über das Web nutzen. Darüber hinaus dienen Wikis als Wissensma-
nagement-Werkzeug bei Planung, Dokumentation und als Content Management
System40.41 Hierbei ist zu berücksichtigen, dass es Anforderungen geben kann, die
ein reines Content Management System erfordern. Dies ist auf Basis der im Unter-
nehmen vorhandenen Rahmenbedingungen zu entscheiden.42 Es sei jedoch ange-
merkt, dass es für die Anwendung als Content Management System bereits Erwei-
terungen einzelner Wikis gibt.43
Innerhalb einer Organisation ist es wichtig, das Wissen der Mitarbeiter zu externa-
lisieren. D.h. es sollen Möglichkeiten geschaffen werden das persönliche Wissen
niederzuschreiben und so Anderen zugänglich zu machen. Diese können dann pro-
zessuales Wissen und Erfahrungen in der für sie relevanten Art und Weise weiter
verarbeiten.44 Gerade hier können Vorteile ggü. anderen Werkzeugen bei einem
Wiki gesehen werden.
38 Das erste Wiki wurde 1995 von Ward Cunningham entwickelt. Vgl. Ebersbach et al. 2008 /Wiki/
S. 14.
39 Vgl. Komus, Wauch 2008 /Wikimanagement/ S. 5.
40 Ein Content Management System bildet die Organisationsstruktur in Zusammenhang mit einem
Verzeichnis ab. Es geht somit um die Unterstützung des Verwaltungsaufwandes eines Archives für
Informationen. Vgl. Gallenbacher 2007 /CMS/ S. 30 ff.
41 Vgl. Ebersbach et al. 2008 /Wiki/ S. 15.
42 Vgl. Vgl. Gallenbacher 2007 /CMS/ S. 37. In Bezug auf einen Abgleich eines Wiki zu einem Content
Management System Vgl. Gallenbacher 2007 /CMS/ S. 32 ff.
43 Vgl. zu spezifischen Ausprägungen in den einzelnen Wikis www.wikimatrix.org, Abruf am
15.06.2011.
44 Vgl. Komus, Wauch 2008 /Wikimanagement/ S. 162.
8Die Genres in denen ein Wiki eingesetzt wird sind beispielsweise Offene-Punkte-
Listen, Referenzen in der Software-Entwicklung oder Ideensammlung, Sitzungs-
protokolle und Statusreports im Projektmanagement.45
3.1. Standardfunktionen aller Typen von Wikis
Es gibt mittlerweile nicht mehr das Wiki, sondern mehrere Abwandlungen 46 für
spezifische Anforderungen.47 Aus diesem Grund werden im Folgenden die Stan-
dardfunktionen vorgestellt.
Ein Wiki ist ein einfach und leicht zu bedienendes Werkzeug für kooperatives Ar-
beiten an Texten und Hypertexten.48 Diese Hypertexte bewirken, dass auf den Sei-
ten Begrifflichkeiten mit den dafür zugehörigen Seiten verknüpft werden können.
So kann der Anwender entscheiden, ob er diese Information lesen möchte, bspw.
zum besseren Verständnis oder ob er den aktuellen Text weiter folgt. Die in regu-
lären Ausarbeitungen vorhandenen Strukturen mit klaren Zuordnungen von Tex-
ten zu einzelnen Themen können so übergangen werden und erleichtern dem Le-
ser die Bearbeitung und das Verständnis.49
Bei der Bearbeitung können die einzelnen Seiten nicht nur neu erstellt, verändert
oder erweitert werden, sondern es können auch Kommentare zu den Seiten ver-
fasst werden.50 Dies ist sinnvoll, wenn ein Meinungsaustausch erreicht werden
soll. Dabei kann für Abstimmungsprozesse einzelner Themen eine eigene Diskus-
sionsseite erstellt werden. Auf dieser Seite können die Inhalte eines Artikels be-
sprochen werden umso zu einem Konsens zu finden. Eine mögliche Diskussion
kann darüber hinaus genauso nachvollzogen51 werden, wie dies bei den regulären
Seiten möglich ist.52
45 Vgl. Blaschke 2008 /Wikis in Organisationen/ S. 185.
46 Vgl. zu den verschiedenen Typen von Wikis und den Funktionen www.wikimatrix.org, Abruf am
15.06.2011, dort werden die einzelnen Typen und Funktionen derselben vorgestellt.
47 Vgl. Ebersbach et al. 2008 /Wiki/ S. 24.
48 Vgl. Parson 2011 /Dokumentation/ S. 41.
49 Vgl. Ebersbach et al. 2008 /Wiki/ S. 17 f.; Ebersbach et al. 2008 /Wiki/ S. 22 f.
50 Vgl. Parson 2011 /Dokumentation/ S. 41.
51 Vgl. zur Nachvollziehbarkeit die folgenden Ausführungen.
52 Vgl. Ebersbach et al. 2008 /Wiki/ S. 69 f.
9Die Seiten können von allen Anwendern erstellt und geändert werden, jedoch ist es
auch möglich einzelne Seiten zu sperren.53 Dies ist notwendig bei Seiten, die nicht
der Abstimmung dienen, sondern reinen Informationscharakter haben. Des Weite-
ren kann es auch Seiten geben, die nur von bestimmten Personen geändert werden
sollen oder bereits bearbeitet und verabschiedet sind.
Für die Verfolgung der Veränderung im Verlauf auf den Seiten werden sämtliche
Veränderungen oder besser gesagt die Vorgängerversionen gespeichert.54 Nach
Ansicht des Verfassers ist es jedoch notwendig eine Beschränkung zu berücksich-
tigen, da sich das Datenvolumen in komplexen Projekten sonst exponentiell entwi-
ckelt.55 Hierbei ist es möglich Vorgängerversionen und somit den ursprünglichen
Inhalt wieder zu speichern als finale Version. Diese Funktion kann als Rollback-
Funktion bezeichnet werden. In einigen Typen von Wikis gibt es zusätzlich beson-
dere Funktionen, mit denen Änderungen grafisch dargestellt werden, so dass es
nicht notwendig ist zwei Versionen Zeile für Zeile zu Vergleichen.56 Dies ermög-
licht eine spezielle Art der Kommunikation der Anwender57, die über die Änderun-
gen einen, wenn auch abstrakten, Dialog führen und sich so dem gemeinsamen
Ergebnis annähern.58
Zusätzlich zu dieser Funktion ist es möglich die letzten Änderungen in einem ge-
sonderten übergeordneten Dokument sichtbar zu machen. Dies kann für eine ge-
wisse Anzahl gelten, oder auch für Änderungen in einem bestimmten Zeitraum.
Auch bei dieser speziellen Funktion gibt es Typen von Wikis, bei denen ein An-
wender gezielt einzelne Artikel nachverfolgen kann. Dies erleichtert einem Pro-
jektleiter oder Verantwortlichen für einen Teilbereich die Überprüfung und Trans-
parenz.59
53 Vgl. Ebersbach et al. 2008 /Wiki/ S. 22.
54 Vgl. Ebersbach et al. 2008 /Wiki/ S. 23.
55 In welchem Rahmen dies erfolgen kann wird hier nicht weiter behandelt. Dies ist bei der Imple-
mentierung im Einzelfall zu entscheiden und zu berücksichtigen.
56 Vgl. Ebersbach et al. 2008 /Wiki/ S. 23.
57 Es sei darauf hingewiesen, dass bei einer nachträglichen Änderung durch denselben Anwender
keine Kommunikation erfolgen kann, dies kann im Rahmen dieser Arbeit jedoch vernachlässigt
werden.
58 Vgl. zur Kommunikation über die Funktion der Veränderungsverfolgung Blaschke 2008 /Wikis in
Organisationen/ S. 188.
59 Vgl. Ebersbach et al. 2008 /Wiki/ S. 23 f.
10Sollte ein Anwender einen bestimmten Artikel oder eine Begrifflichkeit suchen, so
gibt es die Möglichkeit eine klassische Volltext- oder Titelsuche durchzuführen.
Wurde darauf geachtet die Seitentitel eindeutig zu definieren, so kann das Wiki wie
ein Karteikartensystem genutzt werden.60
Darüber hinaus ist es grundsätzlich möglich sämtliche Daten in einem Wiki bereit
zu stellen, die auch auf jeder anderen Internetseiten gespeichert werden können.61
Dies ermöglicht es somit auch andere Werkzeuge und deren Output mit zu berück-
sichtigen. Bspw. spezielle Formalismen und Konzepte im Requirements-
Engineering, wie Ablaufdiagramme, Petrinetze und modellbasierte Beschreibun-
gen.62
Aufgrund der Wiki-Technologie ist bei einer Anwendung im Intranet oder Internet
eine verteilte Bearbeitung möglich. Sollten zwei Anwender gleichzeitig arbeiten, so
wird die Seite, welche in Bearbeitung ist, durch den ersten Anwender gesperrt.63
Dies stellt sicher, dass die o.g. Funktion der Speicherung von Versionen immer ein-
deutig ist.
3.2. Semantische Wikis
Innerhalb einer Gruppe kann es vorkommen, dass das Vokabular, trotz der identi-
schen natürlichen Sprache unterschiedlich ist. Beispielsweise schreibt ein Anwen-
der „Präsentation“, ein Anderer „Praesentation“. Dies führt dazu, dass die o.g. Such-
funktionen und auch Zuordnungen in Hypertexten nicht zu 100% funktionieren.
Semantische Wikis steuern diesem mit semantischen Technologien entgegen. Das
Wiki mit dieser Technologie kann bei einem Eintrag die Wörter überprüfen und
60 Vgl. Ebersbach et al. 2008 /Wiki/ S. 24.
61 Vgl. Bry 2009 /Kreidetafel/ S. 29.
62 Vgl. zu den unterschiedlichen Formalismen und Konzepten die Darstellungen in Partsch 2010
/Requirements-Engineering/ S. 69 ff.
63 Vgl. Geisser et al. 2007 /Wikis/ S. 5.
11eine einheitliche Schreibweise vorschlagen.64 Somit ist es für die Speicherung von
strukturiertem Wissen sinnvoll ein semantisches Wiki zu verwenden.65
Die o.g. semantischen Technologien können unter dem Begriff des Semantic-Web
zusammengefasst werden. Das Semantic-Web hat die Vision die Inhalte einer In-
ternetseite mit einer Maschine erfassen zu können.66 Als Beispiel für eine derartige
Unterstützung kann man das Projekt Semantic Wikipedia betrachten. Ein Anwen-
der kann, wenn er innerhalb eines Textes das Wort Berlin und auch Deutschland
liest, erkennen, dass es sich bei Berlin um die Hauptstadt Deutschlands handelt.
Ein reguläres Wiki67 kann dies nicht. Da im regulären Wikipedia68 keine semanti-
sche Funktion verfügbar ist, ist ein zusätzliches Modul entwickelt worden. Das fer-
tige Produkt ist das Semantic MediaWiki, welches eine Erweiterung des MediaWiki
darstellt.69 Durch dieses Modul ist es dem Wiki möglich die Metainformation „ist
Hauptstadt“, gemäß dem o.g. Beispiel, hinzuzufügen. So ist es möglich eine Abfrage
der Hauptstädte in Europa zu machen und schnell ein Ergebnis zu erzielen.70
Die Erweiterung eines Wiki um die semantische Technologie kann als Erweiterung
oder Evolution eines Wiki gesehen werden, die Standardfunktionen werden durch
diese Erweiterung nicht negativ beeinflusst. Somit ist ein Wiki nicht nur auf die
Texterstellung beschränkt, sondern kann auch bei strukturiertem Wissen gute Ar-
beit leisten. Die hierbei entstehenden Möglichkeiten aus bestehenden Artikel neu-
es Wissen zu generieren werden bestehende Wikis zu mächtigen Datenbanken
machen.71
64 Vgl. Bry 2009 /Kreidetafel/ S. 28 f.
65 Vgl. Geisser et al. 2007 /Wikis/ S. 10.
66 Vgl. Hüner et al. 2008 /Semantisches Wiki/ S. 36.
67 Das Wiki soll hier verstanden werden als die reine Maschine ohne Bezug zu einem Konzept.
68 Wikipedia basiert auf dem MediaWiki. Vgl. Hüner et al. 2011 /Metadatenmanagement/ S. 102.
69 Vgl. Hüner et al. 2011 /Metadatenmanagement/ S. 102.
70 Vgl. Geisser et al. 2007 /Wikis/ S. 10 f.
71 Vgl. Geisser et al. 2007 /Wikis/ S. 11.
124. Wiki im Requirements-Engineering
Für das Requirements-Engineering ist es wichtig die richtigen Werkzeuge zu nut-
zen. Ohne gute Werkzeuge ist ein größeres Projekt kaum händelbar.72 Im Speziel-
len für das RE gibt es Werkzeuge, es ist jedoch nach Ansicht des Verfassers zu be-
rücksichtigen, dass diese sehr oft für die Anwender und ggf. in Teilbereichen auch
für die Entwickler, neu sind. Ein Wiki ist hingegen bei den Entwicklern bekannt73
und wird oft im abgegrenzten Bereich der Entwicklung eingesetzt. Dies auch vor
dem Hintergrund, dass die agilen Methoden im Bereich der Software-Entwicklung
einfache flexible Werkzeuge benötigen.74 Darüber hinaus haben auch die Anwen-
der durch Wikipedia Kenntnisse dieses Werkzeuges.75 Dies stellt somit unter der
Komplexität eines Software-Projektes eine gute Möglichkeit zur Komplexitätsre-
duzierung und Nutzung dar. Die Anwender müssen sich nicht in eine neue Soft-
ware einarbeiten, um in einem Software-Projekt mitarbeiten zu können.
Die Mitarbeit ist hierbei unabhängig von Ort und Zeit, durch die Möglichkeit ver-
teilt arbeiten zu können. Daraus folgt, dass ein Wiki gut in internationalen Soft-
ware-Projekten einsetzbar ist. Mehrere Projektmitglieder können im Team zu-
sammenarbeiten.76
Auf Basis des oben beschriebenen Anforderungsprozesses ist zu prüfen, in wie
weit ein Wiki den Prozess der Anforderungserhebung- und -analyse77 unterstützen
kann.
4.1. Anforderungserhebung und –analyse mit einem Wiki
Bei der Nutzung eines Wikis für die Anforderungserhebung und –analyse kann zu
jeder initial entstandenen Anforderung eine eigene Seite aufgemacht werden. 78 Auf
dieser Seite kann die Anforderung beschrieben, wichtige zusätzliche Dokumente
72 Vgl. Kittlaus, Rau, Schulz 2004 /Software-Produkt-Management/ S. 131.
73 Vgl. Kapitel 2 und die Entstehung des Wiki. Die Nutzung bei Entwicklern ist die Basis der heuti-
gen Wikis.
74 Vgl. Rodé, Schnitter, Wend /IT-Anwendungen/ S. 46.
75 Vgl. Komus, Wauch 2008 /Wikimanagement/ S. 172.
76 Vgl. Rüping 2011 /Dokumentation/ S. 32.
77 Vergleiche zum Prozess Kapitel 2.1. Anforderungserhebung und –analyse.
78 Vgl. Geisser et al. 2007 /Wikis/ S. 5.
13hinzugefügt oder auch verlinkt werden.79 Zusätzlich zu der reinen Anforderung
kann durch die möglichen Kommentare ein Abstimmungsprozess eingeleitet wer-
den.80 Durch die Standardfunktion der Kommentare und auch der Nachverfolgbar-
keit kann somit folgender Prozess durchgeführt werden.81 Ein Anwender erstellt
eine initiale Anforderung an die Software, andere Anwender aus dem Unterneh-
men können diese lesen und nach ihrer Meinung fehlerhafte Daten ändern oder
auch für sie selbst wichtige Punkte ergänzen. Hierbei kann von einer Entschei-
dungsinstanz82 die Seite geprüft und nach dem Abstimmungsprozess zur weiteren
Verarbeitung gesperrt werden.83 Durch diese Vorgehensweise werden alle An-
wender an dem Prozess beteiligt und das organisationale Wissen genutzt. Des Wei-
teren ist der Entstehungsprozess immer klar nachvollziehbar.84 Durch die Ab-
stimmung in der Unternehmung können Fehler vermieden und die teilweise vor-
handenen Schwierigkeiten der Externalisierung des Wissens gelöst werden.85
Bei der Betrachtung Tätigkeit innerhalb der Anforderungserhebung und –analyse
ist zu erkennen, dass Fachtermini wichtig sind. Gerade in diesem Bereich kann ein
Wiki eine sehr gute Unterstützung leisten. Wird ein Glossar erstellt, so können in-
nerhalb der Anforderung auftretende Fachtermini mit einem Hyperlink versehen
werden und im Glossar erklärt werden.86 Für das Glossar selbst gelten die gleichen
Funktionen, wie auch für die Anforderung selbst, so dass auch dort Kommentare
und Versionen verfügbar sind. Sollte es vorkommen, dass Fachtermini durch Fach-
termini erklärt werden, so wird auch dort die Verlinkung angewendet. Dies er-
leichtert allen Beteiligten das Verständnis in einer heterogenen Gruppe aus An-
wendern und Entwicklern.
Sollte, als Vergleich, beim RE Büro-Software genutzt werden, liegt die Verantwort-
lichkeit der Ablage bei den einzelnen Anwendern, Entwicklern und dem Projektlei-
79 Zur Möglichkeit der Verlinkung vgl. Kapitel 3.1.
80 Vgl. Geisser et al. 2007 /Wikis/ S. 5.
81 Vgl. zu der Möglichkeit der Kommentare und der Nachverfolgbarkeit Kapitel 3.1.
82 Dies kann der Projektleiter oder anderes organisatorisches Gremium wie bspw. ein Lenkungs-
ausschuss sein.
83 Vgl. zur Möglichkeit der Sperrung einzelner Seiten Kapitel 3.1.
84 Vgl. Geisser et al. 2007 /Wikis/ S. 5.
85 Vgl. zum Wissensmanagement mit Groupware und Social Software Lehner 2009
/Wissensmanagement/ S. 241 ff.
86 Vgl. Parson 2011 /Dokumentation/ S. 42.
14ter. Folglich kann es vorkommen, dass Änderungen nicht mehr nachvollzogen
werden können.87 Dieses Problem wird bei der Nutzung eines Wikis behoben, da
sämtliche Versionen verfügbar sind und so eine Nachverfolgung ermöglicht wird.88
Auch die gleichzeitige Bearbeitung einer Seite wird durch die Sperrung des ersten
Anwenders verhindert. Somit kommt es nicht vor, dass zwei Dokumente 89 mit glei-
cher Bezeichnung unterschiedliche Inhalte haben. Zusätzlich ist die Verfolgung
über den Status der Anforderung möglich, so dass immer klar ist, wie weit die Be-
arbeitung des Dokuments fortgeschritten ist.90
Durch die Möglichkeit der Verschlagwortung und der Kategorisierung der Anfor-
derungen kann die Suche innerhalb eines Wiki sehr stark vereinfacht werden. Es
ist somit einfach möglich notwendige Informationen über eine Volltextsuche zu
suchen. Dies erleichtert ebenfalls die Arbeit im Requirements-Engineering.91
4.2. Requirements-Engineering mit einem semantischen Wiki
Dem semantischen Wiki kommt innerhalb des Requirements-Engineering eine
besondere Bedeutung zu. Es ist durch die semantische Technologie möglich, die
entstandenen Anforderungen weiter zu strukturieren und neue Informationen aus
den bestehenden Daten zu extrahieren. Hierbei wird die Ermittlung der Sprache
nicht ersetzt, sondern erweitert. Der evolutionäre Prozess der Anforderungsab-
stimmung / -entstehung wird zusätzlich mit berücksichtigt und ermöglicht neue
Erkenntnisse. Gerade diese Funktion macht ein Wiki Requirements-Engineering
tauglich. Die verwendeten Schlussfolgerungssysteme, Regelsprachen oder dekla-
rative Abfragesprachen ermöglichen die dynamische Generierung von Inhalten
oder können für Modelldaten und deren Validierung genutzt werden.92 Im Zu-
sammenhang mit der Requirements-Engineering ist es auch möglich einzelne ERP-
Transaktion mit „genutzt in“ zu integrieren, so dass dies bei der Anforderungser-
87 Vgl. Geisser et al. 2007 /Wikis/ S. 3 f.
88 Vgl. Ebersbach et al. 2008 /Wiki/ S. 23.
89 Es wird hier nicht von Seite, sondern Dokument gesprochen, da dieses Problem bei einem Wiki
nicht auftritt und die Begrifflichkeit Seite in diesem Zusammenhang einen falschen Schluss zulassen
würde. Dokumente können sein Excel, Word, PDF und ähnliche Dokumentenarten.
90 Vgl. Parson 2011 /Dokumentation/ S. 41.
91 Vgl. Parson 2011 /Dokumentation/ S. 41.
92 Vgl. Geisser et al. 2007 /Wikis/ S. 11.
15hebung und auch der späteren Programmierung verwendet werden kann und ein
einheitlicher Bezug besteht.93
5. Fazit
Wie oben dargestellt ist ein Wiki einfach in der Bedienung und eignet sich somit
gut für das am Anwender ausgerichtete Requirements-Engineering. Dabei werden
die Tätigkeiten unterstützt, die für das RE wichtig und notwendig sind in Verbin-
dung mit neuen Möglichkeiten das Wissen der Anwender zu sammeln, zu struktu-
rieren und eine gemeinsame Sprache zu finden. Aber auch aus Sicht der Entwick-
ler, die traditionell eher weniger an der schriftlichen Aufnahme der Anforderungen
interessiert sind und lieber programmieren, stellt ein Wiki eine gute Möglichkeit
der Formalisierung der Anforderungen dar.
Es sei jedoch angemerkt, dass die Funktionsfähigkeit eines Wiki nicht nur von der
Technik abhängt. Wenn ein Wiki im RE eingesetzt wird, so ist es unabdingbar ein
klares Vorgehensmodell zu nutzen und ggf. die spezifischen Bedingungen im Ein-
zelfall eines Projektes zu berücksichtigen.94
Bei der Betrachtung der zukünftigen Entwicklung und den aktuell diskutierten
agilen Methoden im Software-Engineering kann ein Wiki, im Speziellen durch die
Flexibilität, eine gute Unterstützung leisten. An der Diskussion und der Prüfung
der Möglichkeiten der Unterstützung der Dokumentation durch ein Wiki in agilen
Projekten kann erkannt werden, dass sich Wikis in einem evolutionären Prozess
befinden.95 Ob es hier in Zukunft ein Wiki für das Software-Engineering oder spe-
zielle Bereiche gibt ist nach Ansicht des Verfassers fraglich, jedoch kann man er-
kennen, dass Potenziale vorhanden sind, die Software-Projekte erfolgreicher ma-
chen können.
93 Vgl. zur Möglichkeit der Verknüpfung der ERP-Transaktion Hüner et al. 2011
/Metadatenmanagement/ S. 100.
94 Vgl. zu einem beispielhaften Vorgehensmodell i.V.m. der Dokumentation in der Software-
Entwicklung Parson 2011 /Dokumentation/ S. 42 f.
95 Vgl. zu der Prüfung eines Wiki zur Dokumentation Parson 2011 /Dokumentation/ S. 40 ff.;
Rüping 2011 /Dokumentation/ S. 28 ff.
16Gerade durch die semantischen Wikis ist es vorstellbar, dass diese in der Lage sind
aus den Informationen in einem Wiki, bei ausreichendem Formalisierungsgrad,
Quellcode zu generieren.
Somit ist nach Ansicht des Verfassers ein Wiki geeignet Unterstützung im Requi-
rements-Engineering zu leisten und zusätzliche Effizienz und Effektivität zu errei-
chen.96
96 Vgl. auch zu den Erfahrungen von Entwicklern in Projekten Rüping 2011 /Dokumentation/ S. 32.
17Literaturverzeichnis
Balzert, H. 2008 /Softwaremanagement/ Lehrbuch der Softwaretechnik - Softwa-
remanagement. 2. Auflage, Heidelberg 2008.
Blaschke, S. 2008 /Wikis in Organisationen/ Wikis in Organisationen: Von Kom-
munikation zu Kollaboration. In: Alpar, P.; Blaschke, S. (Hrsg.): Web 2.0 – Eine em-
pirische Bestandsaufnahme. Wiesbaden 2008, S. 183 – 203.
Bry, F. 2009 /Kreidetafel/ Kreidetafel und Lounge 2.0 – Der Einzug sozialer Medi-
en in Technik und Wissenschaft. In: Information Management & Consulting, Vol-
ume 24, Issue 1, p. 26 – 33.
Dumke, R. 2003 /Engineering/ Software Engineering. 4. Auflage, Wiesbaden 2003.
Ebersbach, A. et al. 2008 /Wiki/ Wiki, Kooperation im Web. 2. Auflage, Berlin Hei-
delberg 2008.
Gallenbacher, J. 2007 /CMS/ Wikis contra CMS. In: Lange, C. (Hrsg.): Wikis und
Blogs. Böblingen 2007, S. 21 – 38.
Geisser et al. 2007 /Wikis/ Einsatzpotenziale von Wikis in der Softwareentwick-
lung am Beispiel von Requirements Engineering und Traceability Management.
Working Paper Universität Mannheim 2007.
Goeken, M. 2006 /Data-Warehouse-Systeme/ Entwicklung von Data-Warehouse-
Systemen. Wiesbaden 2006.
Hood, C. et al. 2008 /Requirements Management/ Requirements Management.
Berlin Heidelberg 2008.
Hüner, K et al. 2011 /Metadatenmanagement/ Fachliches Metadatenmanagement
mit einem semantischen Wiki. In: HMD - Praxis der Wirtschaftsinformatik 2011,
Heft 277, S. 98 – 108.
18Hüner, K et al. 2008 /Semantisches Wiki/ Metadatenmanagement mit einem se-
mantischen Wiki. In: Information Management & Consulting, Volume 23, Issue 2,
p. 34 – 40.
Kittlaus, H.-B.; Rau, C.; Schulz, J. 2004 /Software-Produkt-Management/ Software-
Produkt-Management. Berlin Heidelberg 2004.
Komus A., Wauch F. 2008 /Wikimanagement/ Wikimanagement. München 2008.
Koschek, H. 2011 /Anforderungsermittlung/ Das A-Team: Anforderungsermittlung
in agilen Projekten. In: OBJEKTspektrum 2011, Nr. 3, S. 80 – 85.
Lehner, F. 2009 /Wissensmanagement/ Wissensmanagement. München Wien
2009.
Parson, U. 2011 /Dokumentation/ Im Team schreiben: Dokumentation von techni-
schen Schnittstellen mit Wikis. In: OBJEKTspektrum 2011, Nr. 3, S. 40 – 43.
Partsch, H. 2010 /Requirements-Engineering/ Requirements-Engineering system-
atisch. 2. Auflage, Berlin, Heidelberg 2010.
Pohl, K. 2010 /Requirements-Engineering/ Requirements-Engineering, Funda-
mentals, Principles, and Techniques. Berlin Heidelberg 2010.
Rodé, Schnitter, Wend /IT-Anwendungen/ Erfolgreich IT-Anwendungen entwi-
ckeln – Wissensmanagement hilft. In: wissens management 2009, Heft 8, S. 46 – 48.
Rüping, A. 2011 /Dokumentation/ Von agilen Verfahren lernen: Auf dem Weg zu
bedarfsgerechter Dokumentation. In: OBJEKTspektrum 2011, Nr. 3, S. 28 – 33.
Sommerville, I. 2001 /Software-Engineering/ Software-Engineering. 6th Edition,
Edinburgh Gate 2001.
19Zuser, W.; Grechenig, T.; Köhle, M. 2004 /Software Engineering/ Software Enginee-
ring mit UML und dem Unified Process. 2. überarbeitete Auflage, München 2004.
20Sie können auch lesen
