WebGIS und WebMapping für Anfänger: Anforderungen an ein anwendungsfreundliches WebGIS-System

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.

Autorentext

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.

Leseprobe
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.