Quasi alle großen kommerziellen GIS-Anbieter bieten für ihre Produkte eine Web-Komponente an - häufig sogar kostenfrei. Auch im OpenSource Bereich gibt es sehr viele Ansätze und Lösungen in dieser Richtung. Leider sind diese Lösungen bisher oft nur in der GIS Branche bekannt und es benötigt sehr viel GIS Know-how, um ein solches WebGIS für eigene Ansprüche zu konfigurieren und aufzusetzen. Die Anwendungsbereiche gehen aber in viele verschiedene Richtungen und sind nicht nur auf die reine GIS Branche beschränkt. In vielen dieser Anwendungsbereiche ist GIS allerdings kein Standard-Werkzeug und durch die fehlenden WebGIS-Experten ist entsprechendes Know-how teuer und mühsam zu erwerben. In dieser Studie soll untersucht werden, welche Möglichkeiten es gibt, um WebGIS-Funktionalitäten auch für Laien zugänglich zu machen. Eine erfolgreiche Umsetzung soll GIS bzw. WebGIS einem breiteren Publikum - insbesondere Nicht-GIS-Experten - zugänglich und nutzbar machen. Am Ende liegt ein umfangreicher Anforderungskatalog mit möglichen Anforderungen für den Aufbau und die Benutzung eines auch für Laien einfach handhabbaren WebGIS-Systems vor. Des Weiteren wurde überprüft, welches der drei getesteten Softwareprodukte die Anforderungen am weitgehensten erfüllt.

Textprobe: Kapitel 3.1, Spezifikationslevel in der Anforderungsermittlung: In der Praxis ist es in der Regel so, dass nicht sofort jede Anforderungen bis ins kleinste Detail bedacht und ausformuliert werden kann. Oftmals ist während der ersten Spezifikationsphase auch noch nicht jedes Detail des Systems bekannt. Wie zuvor beschrieben, verläuft die Ermittlung der Anforderungen deshalb in mehreren Schritten ab, um zunächst sehr grobe Anforderungen in einem iterativen Prozess weiter zu verfeinern. Im Rahmen dieser Dokumentation werden deshalb drei aufeinander aufbauende Spezifikationslevels (1-3) eingesetzt. Der erste Spezifikationslevel beschreibt die ‘Rohdaten’ einer Anforderung, dies sind unbearbeitete Anforderungen, welche z. B. direkt von den Stakeholdern oder aus der Untersuchung der Software kommen und noch nicht aufbereitet wurden. Hierbei wird das System zunächst nur sehr grob umrissen ohne die Anforderungen im Detail auszuformulieren. Anforderungen vom Level 1 liegen als Stichwortlisten und Prosatext vor. Die nächste Spezifikationsstufe (Level 2) beschreibt die erste Verfeinerungsstufe der Anforderungen. Die noch nicht ausformulierten Stichworte der Stichwortliste und die Prosatexte werden von unwichtigen, doppelten Informationen befreit und wo nötig aus- bzw. umformuliert. Die Anforderungen des zweiten Levels sind hierbei oftmals noch nicht ‘umsetzungsfähig’. Um die Anforderungen umsetzen zu können, fehlen oftmals noch bestimmte wichtige Informationen. Jede Anforderungen muss also noch einmal geprüft und mit ggf. fehlenden Informationen ergänzt werden. Nach dieser Phase liegen Anforderungen in Spezifikationslevel 3 vor. 3.2, Grobe Systemanforderungen ermitteln (Level 1): Um Anforderungen für das neue System zu evaluieren, wurde zunächst versucht den Gesamtumfang des Systems grob zu umreißen. In diesem Schritt wurden die Systemgrenzen abgesteckt. Durch verschiedene Kreativitätstechniken als Hilfsmittel zur Anforderungsanalyse) mit Hilfe der Stakeholder und durch Überprüfen der drei getesteten Softwareprodukte wird versucht die Ziele des Systems zu identifizieren. Das Ergebnis ist eine Liste mit groben Systemanforderungen. Die Anforderungen sind in diesem Stadium der Erhebung noch nicht weiter aufbereitet oder angepasst und liegen im Spezifikationslevel 1 vor. Die Anforderungen sind außerdem in dieser ersten Phase noch mit allgemeinen Zielen des Systems gleichzusetzen, d.h. sie gehen noch nicht ins Detail und bieten meist nur Hauptmerkmale und noch keine detaillierten funktionalen Anforderungen. Die Anforderungen auf Spezifikationslevel 1 wurden mithilfe der Stakeholder im Brainstorming erhoben. Hierfür wurde eine Sitzung mit den Stakeholdern der verschiedenen Gruppen (Nutzer, Entwickler, Auftraggeber, Tester, Betreiber) abgehalten. Hier wurde die Idee hinter dem Thema kurz vorgestellt. Anschließend wurden weitere Ziele, Ideen und Anforderungen für ein gewünschtes System in der Runde diskutiert und protokolliert. Als Ergebnis dieser Brainstorming-Sitzung entstand eine erste Stichwortliste mit groben Merkmalen und Anforderungen, welche ein späteres System erfüllen sollte. ‘Grob’ heißt hierbei, dass die Anforderungen in der Stichwortliste noch nicht ausformuliert und überarbeitet sind. Weitere Anforderungen wurden über eine schriftliche Art ‘Mail-Brainstorming-Verfahren’ ebenfalls mit Hilfe der Stakeholder erhoben. Hierbei wurden die Stakeholder per E-Mail dazu aufgerufen drei - fünf Ideen für ein gesuchtes System zu formulieren. Nachdem so jeder Beteiligte seine ‘Wünsche’ schriftlich fixiert hatte, wurden diese an den jeweils nächsten Beteiligten in der Runde der Stakeholder weitergegeben. Der Leser der jeweiligen Anforderungen hatte nun die Aufgabe die von den anderen Stakeholdern genannten ‘Wünsche’ wiederum zu kommentieren und zu verfeinern. Dies wurde so lange wiederholt bis alle Anforderungen von jedem Beteiligten bearbeitet wurden. In einem zweiten Schritt wurden die drei Software-Lösungen ArcGIS Online, Mapbender und Cartaro auf sinnvolle Anforderungen überprüft (siehe Kapitel 3.2.2. Analyse bestehender Softwareprodukte auf sinnvolle Anforderungen)Hierzu wurde bei jeder Software jeweils der Ablauf des Installations- und Konfigurationsprozesses, der Funktionsumfang, die Dateneinbindungsmöglichkeiten, das Layout und Design, sowie Möglichkeiten der Hilfe und Dokumentation untersucht. Auch in diesem Schritt wurden Anforderungen zunächst in Spezifikationslevel 1 erhoben und noch nicht ausformuliert und überarbeitet. Alle Anforderungen liegen in diesem Stadium der Anforderungserhebung in Spezifikationslevel 1 vor. 3.2.1, Stakeholder für die Anforderungsanalyse ermitteln: Als Stakeholder werden alle Personen oder Gruppen bezeichnet, welche in irgendeiner Form am System beteiligt sind oder sonst vom System profitieren. Dies können z. B. die Nutzer, die Betreiber, die Entwickler oder Programmierer, die Tester oder die Auftraggeber sein. Um die notwendigen Anforderungen an das System bestmöglich abdecken zu können, wäre es natürlich am besten wenn jede der genannten Rollen vertreten wäre. Ein Entwickler hat eine andere Sicht auf das System als der Nutzer und der Auftraggeber. Es ist in der Praxis leider nicht immer möglich Stakeholder aus jeder Gruppe zu verpflichten, da oftmals Zeit- und Kostengründe dagegen sprechen. Im Rahmen dieser Anforderungsanalyse wurden Stakeholder aus dem Bereich der Nutzer, der Entwickler, der Auftraggeber (der Autor), der Tester und Betreiber eingebunden. Aus Datenschutzgründen werden die Stakeholder hier nicht namentlich genannt, sondern nur eine Rolle zugeordnet. Ausserdem kommen die Stakeholder aus verschiedenen Fachbereichen. Dies ist wichtig, da die entsprechenden evaluierten Anforderungen somit natürlich vor allem aus den beteiligten Fachrichtungen kommen. Die Stakeholder kommen aus dem Bereich der Umweltwissenschaften sowie der Geoinformatik allgemein. So gibt es z.B. Beteiligte aus der Umweltplanung, aus dem Wildtier- und Landschaftsmanagement oder aus dem Bereich der Fachgruppe für Vegetationsanalysen. 3.2.1.1, Kreativitätstechniken als Hilfsmittel zur Anforderungsanalyse: Mithilfe der Stakeholder sollen Anforderungen ermittelt werden. Hierbei ist es notwendig viele Meinungen unter einen Hut zu bringen. Unabhängig von Detaillierungsgrad oder Art der Anforderung muss jede Anforderung fachlich gut hinterlegt und kompetent ermittelt werden. Eine Schwierigkeit in diesem Projekt ist es, verschiedenste Stakeholder von einer ‘fremden’ Meinung zu überzeugen. Häufig sind sich die Beteiligten zu Beginn noch nicht darüber bewusst, wohin die Reise geht bzw. was das System können soll oder was es besser macht als das alte System. Der Sinn eines neuen Systems wäre ja die bisherige Situation zu verbessern oder zu vereinfachen. Ziel der gesamten Anforderungsermittlungen ist es, ‘Mit möglichst geringem Aufwand und angepasst an die Projekt-Rahmenbedingungen die Ziele und Anforderungen zu erfassen, um ein System zu entwickeln, das dem Stakeholder möglichst viel Gewinn bringt.’ (Rupp, Chris & die SOPHISTen, 2009) in der Regel ist es so, dass Anforderungen bis ins kleinste Detail verfeinert werden können und es treten immer wieder neue Ziele und Wünsche auf. Oftmals ist es auch so, dass die Beschreibung einer Anforderung wieder diverse neue Anforderungen zu Tage bringt. Hier ist es wichtig den effizientesten Mittelweg zwischen Kostenaufwand und Nutzen zu finden. Es macht keinen Sinn Anforderungen bis ins kleinste Detail zu evaluieren und zu formulieren, wenn dann kein Budget mehr für den Rest der Arbeiten vorhanden ist. Aus diesem Grund wurden die Anforderungen nur bis zu einem gewissen Grad erhoben, der einen Überblick über das Gesamtsystem zulässt, aber noch keine Umsetzungsdetails spezifiziert. Da die Ermittlung der Anforderungen die Zusammenarbeit von unterschiedlichen Menschen erfordert, ist es wichtig geeignete Techniken auszuwählen, um die ‘verborgenen’ Anforderungen in den Köpfen der Stakeholder möglichst effizient herauszuholen und zu dokumentieren. Die Ermittlung von Anforderungen an Hand von Softwareprodukten aus Hilfen oder Dokumentationen ist noch relativ autonom zu bewerkstelligen, aber beim Zusammenspiel mehrerer Personen bedarf es der Wahl einer geeigneten Ermittlungs-oder Kreativitätstechnik. Es gibt hier eine ganze Reihe unterschiedlicher Techniken, die sich in unterschiedlichen Kontexten und Situationen anbieten, vom einfachen Fragebogen über eine Selbstaufschreibung bis hin zu Feldbeobachtungen. Die Anforderungsermittlungen wurden in diesem Rahmen mit zwei grundlegenden Methoden durchgeführt, einem einfachen Brainstorming in der Gruppe und mit der Methode 6-3-5 per E-Mail. 3.2.1.1.1, Kreativitätstechnik - Brainstorming: Das Brainstorming ist eine bekannte Kreativitätstechnik, weshalb an dieser Stelle nur sehr kurz darauf eingegangen werden soll. Das Brainstorming wurde hierfür in einem Workshop mit den entsprechenden Stakeholdern durchgeführt. Ziel dieses Workshops war es zunächst einmal die Idee vorzustellen ein ‘einfaches’ Produkt zu entwickeln, um auch GIS- bzw. Programmier-Laien die Möglichkeit zu geben eine WebGIS-Seite aufzusetzen. Anschließend wurden in einem Brainstorming in der Gruppe Ideen gesammelt und entwickelt. Hieraus entstand eine erste Stichwortliste, welche im Folgenden wiederum in Zusammenarbeit mit den Stakeholdern ausformuliert und verfeinert wurde. Das Brainstorming hat den Vorteil, dass viele Ideen in relativ kurzer Zeit gefunden werden können. Durch die direkte Beteiligung aller Stakeholder können Ideen auch direkt weiterentwickelt und verfeinert werden. 3.2.1.1.2, Kreativitätstechnik - Methode 6-3-5: Die Methode 6-3-5 besagt, dass sechs Teilnehmer drei Ideen in fünf Minuten schriftlich festhalten. Aus diesem Grund heißt es Methode 6-3-5. Anschließend werden die Ideen an den nächsten Teilnehmer in der Runde weitergegeben. Dieser kommentiert und entwickelt nun die drei Ideen seines Vorgängers. Dies wird so lange wiederholt, bis jede Idee von jedem Teilnehmer kommentiert wurde. Diese Methode wurde mit allen Stakeholder durchgeführt. Da die Ideen schriftlich fixiert werden sollten, wurde die Methode per E-Mail durchgeführt. D.h. Jeder Stakeholder hat drei bis fünf Ideen aufgeschrieben und an den nächsten Stakeholder in der Liste versandt. Dies wurde solange fortgesetzt, bis jede Idee von jedem Stakeholder angesehen wurde. Die Methode 6-3-5 ist recht flexibel einsetzbar, da die Stakeholder auch über die Entfernung miteinander kommunizieren können und nicht unbedingt an einem Ort sein müssen. Dies kann auf der anderen Seite aber auch ein Nachteil sein, weil es weniger direkte Kommunikation und Diskussion gibt. Aus diesem Grund wurde der 6-3-5-Methode ein ‘normales’ Brainstorming vorgeschaltet, um einen ersten Überblick und erste Ideen zu bekommen. 3.2.2, Analyse bestehender Softwareprodukte auf sinnvolle Anforderungen: Sinnvolle Anforderungen können nicht nur von Stakeholdern kommen. Auch bereits bestehende Softwareprodukte liefern viele nützliche Hinweise. Es werden drei Softwareprodukte betrachtet, ESRI ArcGIS Online, Mapbender und Cartaro. In einem ersten Durchgang wurden alle Softwareprodukte auf mögliche ‘gute Ideen’ untersucht, um so Anforderungen zu erheben, welche eventuell übernommen werden können. Zum einen wurden hierfür die Dokumentationen, Hilfen und Online Beschreibungen der jeweiligen Software studiert, zum anderen gibt es viele Demo-Seiten, auf welchen die jeweilige Software eingesetzt wird. Auch aus diesen Seiten lassen sich Möglichkeiten ableiten. Zum Schluss wurde eine eigene Installation durchgeführt, um mit eigenen Daten eine Beispiel-Anwendungen aufzusetzen. Als Beispieldatensatz wurden hierbei Vektordaten verwendet. Im speziellen jeweils Punkt-, Linien-, und Polygon-Features aus einer Datei (Shape), sowie aus einer PostGIS-Datenbank. Außerdem wurde eine Rasterdatei eingebunden. Zum Schluss wurde noch ein WMS-Dienst in die jeweilige Oberfläche integriert. Da Mapbender nur OGC-Dienste unterstützt, wurden die Vektordaten und das Rasterfile zusätzlich über einen UMN Mapserver als WMS-Dienst aufbereitet. So konnten dieselben Daten auch Mapbender zur Verfügung gestellt werden und gleichzeitig die Möglichkeit der Einbindung eines WMS in die anderen Produkte untersucht werden. Die Beispieldaten wurden eingebunden, um auch bei den notwendigen Konfigurationsschritten sinnvolle Anforderungen evaluieren und übernehmen zu können.

• WebMapping

• Geoinformatik

• Anforderungsanalyse

• Geoinformation

• GIS-Branche

• Webseite

• Software

Hanno Rahn wurde 1979 in Eutin geboren. Sein Studium der Geoinformatik an der Fachhochschule Oldenburg schloss der Autor im Jahre 2007 mit dem akademischen Grad des Diplom-Ingenieurs (FH) erfolgreich ab. Im Anschluss erlangte er einen Masterabschluss in Geoinformatik an der Universität Salzburg. Bereits während des Studiums sammelte der Autor umfassende praktische Erfahrungen in der Geoinformatik-Branche - auch im Ausland. Schwerpunktmäßig beschäftigt er sich seit einigen Jahren mit der Thematik WebGIS und WebMapping.