Hochschule Mitttweida. Pflichtenheft. Für ein Verkehrsstudie System

Transkript

1 Hochschule Mitttweida Pflichtenheft Für ein Verkehrsstudie System Franziska Frenzel

2 Inhalt 1. Ziel/Produktzweck Musskriterien Kannkriterien Abgrenzungskriterien Produkteinsatz Anwendungsbereich Zielgruppen Betriebsbedingungen Produktübersicht Produktfunktionen Funktionen für App und Nutzer Funktionen für Forscher und Server Produktdaten Produktleistungen Qualitätsanforderungen Benutzeroberfläche App Server Nichtfunktionale Anforderungen Spezielle Anforderungen an die Entwicklungsumgebung Gliederung in Teilprodukte Ergänzungen... 8 Anhang: Glossar... 9 Anhang: Data Dictionary Anhang: Klassendiagramme Anhang: Use Case Diagramm

3 1. Ziel/Produktzweck 1.1 Musskriterien Dieses System dient für eine Verkehrsstudie. Das heißt, in Kombination mit eine Smartphone App für Android und einem Webserver soll analysiert werden, mit welchem Verkehrsmittel wie häufig gefahren wird und welche Strecken. Dazu muss das Smartphone in Form einer App gewisse Sensordaten und Geodaten mitloggen. Diese Daten werden an einen Webserver gesendet und in Form einer SQL Datenbank gespeichert. Der Forscher muss auf dem Webserver Einsicht in die Daten haben und diese auch auf Korrektheit überprüfen können. Dafür wird eine entsprechende Weboberfläche programmiert. Für die einfachere Verarbeitung der Daten, werden simple Umfragedialoge an den Appnutzer gesendet. Dieser muss der Nutzer so einfach wie möglich beantworten können. 1.2 Kannkriterien Damit aus diesem System eine vollwertige Verkehrsstudie wird, wäre es wünschenswert ein komplettes Umfragesystem einzubauen. Ebenfalls sollte das Nutzerverhalten auf grafische Weise visualisiert werden. Das heißt als KML-Datei exportieren und mit Kartenmaterial hinterlegen. Diese Visualisierung soll nur auf dem Webserver sichtbar sein. Für das vereinfachte Senden der Daten wäre ein sogenanntes Widget wünschenswert. Dieses legt man sich auf den Desktop mit der Größe eines 1x1 Feldes. Tippt der Nutzer auf dieses Widget werden die Daten gesendet und alle Funktionen, die damit zusammen hängen, ausgeführt. Dieser Vorgang vereinfacht das Senden der Daten, da der Nutzer die App nicht extra dafür öffnen muss. 1.3 Abgrenzungskriterien Die App sollte nicht für niedrigere Versionen als Android 4.0 entwickelt werden. Viele Design Richtlinien und API-Funktionen stehen erst ab der 4. Androidversion zur Verfügung. Auch das auslesen aller Sensordaten funktioniert erst ab Ice Cream Sandwich. Die Wahl der angesprochenen Sensoren sollte genau überdacht sein. Da nicht in allen Geräten alle Sensoren eingebaut sind. Wenn einige Testpersonen keinen verbauten Sensor besitzen, könnte das Ergebnis verfälscht werden. 2. Produkteinsatz 2.1 Anwendungsbereich Die App soll mobil die Verkehrswege und Nutzerverhalten aufzeichnen. Die gesammelten Informationen werden an einen Webserver gesendet. Auf diesem werden diese auf Korrektheit überprüft und sollen anschließend grafisch angezeigt werden. 2

4 2.2 Zielgruppen Pflichtenheft Mit diesem System wird ein weites Spektrum an Personen angesprochen. Sowohl Junge als auch Alte und sowohl Technik versierte als auch Technik unversierte sollen hier angesprochen werden. Im Endeffekt muss die App einfach programmiert werden, so dass sie jeder intuitiv Bedienen kann. 2.3 Betriebsbedingungen Die App sollte im Hintergrund dauerhaft laufen und nur vom Benutzer beendet werden. Sie sollte also nicht sich selbst beenden können oder durch das System. Optimal wäre es wenn sich die App mit dem Neustart des Smartphone ebenfalls startet. Für eine stetige und Zeitunabhängige Kommunikation zwischen App und Webserver, sollte der Webserver immer erreichbar sein. 3. Produktübersicht Für eine größere Darstellung, siehe Anhang: Use Case Diagramm 3

5 4. Produktfunktionen 4.1 Funktionen für App und Nutzer /PF 000/ Funktion: App ausführen inkl. Tracking und UUID erstellen Beschreibung: Mit dem Starten der App werden die Sensordaten und Geodaten ausgelesen und mit Zeitstempel in eine Datei gespeichert. Zuvor wird geprüft ob eine uuid Datei vorhanden ist oder ob sie leer ist. Wenn ja, wird eine neue UUID generiert. /PF 001/ Funktion: Modus wechseln Beschreibung: Nach statt der App wird automatisch der Sensormodus übernommen. Hier wird ein Wechsel zum Nachtmodus (läuft aktiv im Hintergrund, ohne Aufzeichnungen) und Erhebungsmodus (Durchführung der Umfrage) und zurück zum Sensormodus möglich. /PF 002/ Funktion: Einstellungen Beschreibung: Diverse Einstellungen sind hier vorzunehmen. /PF 010/ Funktion: Mini-Umfrage herunterladen und durchführen Beschreibung: System lädt die Umfrage herunter und der Nutzer kann die Umfrage durchführen. Die Ergebnisse werden anschließend in eine Datei gespeichert. /PF 020/ Funktion: Daten hochladen, sichern und löschen Beschreibung: Auf Befehl des Nutzers werden die Daten an den Webserver gesendet. War dies erfolgreich, werden die Daten zunächst auf dem Gerät, als Backup, gesichert und anschließend werden die original Daten gelöscht. /PF 021/ Funktion: Historie erweitern Beschreibung: Die Historie wird nach dem Hochladen erweitert. Sowohl Erfolg als auch Misserfolg von Aktionen sollen notiert werden 4.2 Funktionen für Forscher und Server /PF 030/ Funktion: Mini-Umfrage erstellen und bereitstellen Beschreibung: Forscher erstellt ein paar Fragen zu seiner Umfrage, über die Website. Sobald die Umfrage fertig ist, muss der Forscher sie als bereit flaggen, damit der Nutzer die Umfrage herunterladen kann. /PF 040/ Funktion: Speicherung der Daten Beschreibung: Via Webservices werden die erhaltenen Daten, von der App /PF 020/, in die Datenbank übertragen /PF 050/ Funktion: Roh-Daten Korrektur Beschreibung: Der Forscher muss die Möglichkeit haben, die Daten zu sichten und Fehlwerte auszusortieren. Anschließend werden die Korrekten Daten und die Fehlerhaften Daten in unterschiedliche Tabellen extra gespeichert. 4

6 /PF 060/ Funktion: Daten visualisieren Beschreibung: Die korrigierten Daten werden grafisch, mit unterlegter Karte, auf einer Weboberfläche dargestellt. /PF 070/ Funktion: Historie erweitern Beschreibung: Entspricht /PF 021/, nur wird diese Historie in die Datenbank des Webservers gespeichert. 5. Produktdaten /PD 010/ Datengruppe: Mini-Umfragedialoge Beschreibung: Daten und Konfigurationen die für das entsprechende Umfragesystem relevant sind. In Form einer XML Datei oder Datenbank-Tabelle (Umfragesystem abhängig) /PD 011/ Datengruppe: Erhebungsdaten Beschreibung: Rohdaten aus der Erhebung (Geodaten, Nutzerdaten, Antworten, Metadaten, Einstellungen des Nutzers wie Profildaten und Bearbeitungsfortschritte in den Nutzerdialogen pro teilgenommener Studie). Als Textdatei (Smartphone) und als Datenbank (Webserver) vorhanden. /PD 012/ Datengruppe: Backupdaten Beschreibung: Alle Daten aus /PD 011/, nach ihrer Übertragung, werden hier fest, auf dem Smartphone, gespeichert. /PD 014/ Datengruppe: Historie Beschreibung: Senden der Daten und Umfrage durchführen, wird als Historie gespeichert /PD 016/ Datengruppe: Fehlerhafte Daten Beschreibung: Daten die aus den Rohdaten aussortiert werden, da sie die Korrektur nicht bestanden haben. /PD 017/ Datengruppe: Plausible Roh-Daten Beschreibung: Die nach der Korrektur bestandenen Erhebungsdaten. /PD 018/ Datengruppe: Verkehrsmittelweg Beschreibung: Enthält Informationen zu den Wegen der Verkehrsmittel. /PD 019/ Datengruppe: Mobilitätskarten-Daten Beschreibung: Speicherung der Erhebungsdaten in einem Kartenformat, zum grafischen wiedergeben der Wege. /PD 020/ Datengruppe: Einzelwege-Daten Beschreibung: n-fach benutzte Wege errechnet, welche über Filter nach Geografischem Gebiet, Benutzungshäufigkeit, Benutzungszeitraum, Verkehrsmittel und Teilgruppe der Probanden zerlegt 5

7 /PD 021/ Datengruppe: Kombinierte Wege Beschreibung: gruppierte Daten mit zusammenhängenden Wegen /PD 022/ Datengruppe: Verkehrsknotenpunkte Beschreibung: Nutzungshäufigkeit und Punkten, an denen Verkehrsmittel gewechselt werden, kann eine Karte mit Verkehrsknotenpunkten 6. Produktleistungen /PL 010/ Simples ausführen und beenden der App. /PL 020/ Es muss eine Möglichkeit geben, die Daten auf Fehlwerte zu überprüfen. /PF 050/ /PL 030/ Daten sollten in einem Backup gesichert werden, für den Fall eines Fehlsendens. /PF 022/ /PL 040/ Sendevorgänge sollen in einer Historie festgehalten werden. /PF 021/ /PL 050/ Energiesparmodus, App darf den Akku nicht, auf schnellsten Wege, leeren. 7. Qualitätsanforderungen Qualität Sehr gut Gut Normal Nicht relevant Funktionalität x Zuverlässigkeit x Benutzbarkeit x Effizienz x Änderbarkeit x Übertragbarkeit x Das System sollte von beiden Seiten, also vom Probanden und Forscher, funktional sein. Das heißt es soll die Arbeit des Forschers erleichtern. Und für den Probanden nicht unnötig verkomplizieren. Aus diesem Grund, wird auf die Funktionalität viel Wert gelegt. Die Zuverlässigkeit des Systems ist besonders wichtig. Der Server muss immer erreichbar sein, damit eine Kommunikation mit der App stattfinden kann. Auch die App sollte fehlerfrei im Hintergrund laufen um ein permanentes Sammeln der Erhebungsdaten zu gewehrleisten. Besonderes Augenmerk sollte hier auf die Funktion des Sendens der Daten geachtet werden. Da durch Internetabbrüche Fehler entstehen können, muss das System entsprechend reagieren. Damit die Abläufe und der Umgang mit dem System reibungslos verläuft und sowohl der Forscher als auch der Proband intuitiv das System bedienen kann, muss auf die Benutzbarkeit erhöhtes Augenmerk gesetzt werden. Besonders wichtig für die Probanden, da jede Altersgruppe angesprochen werden soll. Technikkenntnisse müssen keine Voraussetzung sein, um dieses System bedienen zu können. 6

8 Die App sollte nicht die CPU des Smartphone überlasten, so dass der Nutzer nichts mehr damit machen kann. Ebenso wenig darf sie nicht den Akku binnen ein paar Stunden aufbrauchen. Da sie aber im Hintergrund laufen sollte, muss hier auf die Effizienz geachtet werden. Auf Änderbarkeit sollte geachtet werden. Damit ein einfaches Einarbeiten in das Programm, seitens der Programmierer, problemlos klappt. Änderungen und Einstellungen müssen schnell vorgenommen werden, ohne sich mit dem ganzen Programm auseinander setzen zu müssen. Für weitere Hilfestellungen, müssen hier entsprechende Dokumente erstellt werden. Auch die Übertragbarkeit ist wichtig. Da die App auf verschiedenen Modellen laufen soll, muss auf Kompatibilität der Geräte und Betriebssysteme geachtet werden. 8. Benutzeroberfläche 8.1 App Due Hauptfunktionen der App laufen im Hintergrund ab, deshalb gibt es nur einen Startbildschirm mit Willkommenstext und einem Button zum manuellen Senden der Daten. Zusätzlich sollte es noch einen Einstellungsdialog geben und einen für den Modus wechseln. 8.2 Server Auf dem Server laufen Webservices im Hintergrund die mit keinem Nutzer kommunizieren. Dementsprechend ist keine Benutzeroberfläche vorhanden. 7

9 9. Nichtfunktionale Anforderungen Die Probanden müssen im Besitz eines Android Smartphone sein, auf denen Apps laufen, die in Java geschrieben wurden. Um die Funktionen im vollen Umfange nutzen zu können, sollte die Smartphones der Probanden alle mit einem Android über 4.0 (Ice Cream Sandwich) ausgestattet sein. Zudem muss der Webserver eine MySQL Datenbank installiert sein. Und PHP-Dokumente müssen lauffähig sein. In Kombination sollte das Tool PHPmyAdmin installiert sein. Ebenfalls müssen auf dem Webserver Webservices laufen können. 10. Spezielle Anforderungen an die Entwicklungsumgebung Zum Erstellen der Architektur Entwürfe, wird das Tool ObjectIF, Version 7.1 von der Firma MicroTool, verwendet. Da dieses Tool eine Schnittstelle zur Java-IDE Eclipse verwendet, wird auch in diesem Projekt Eclipse verwendet. Zusätzliche Plugins für die Android- und Webentwicklung wurden installiert. Die Systemtests erfolgen über JUnit. Als Datenbanksystem wird eine MySQL Datenbank verwendet, in Kombination mit dem PHPmyAdmin Tool. Für die Ausführen und Präsentation der App werden diverse Android Emulatoren verwendet. Ebenfalls stehen zwei unterschiedliche Modelle der Marke Sony (Xperia Z und Xperia Go) zur Verfügung. 11. Gliederung in Teilprodukte Step 1: Step 2: Step 3: Step 4: Step 5: Step 6: Entwicklung der App und ihre Hauptfunktionalitäten. Aufsetzen eines Webserver mit MySQL Datenbank zur Onlinespeicherung der Daten. Erstellen einer Weboberfläche für Auswertungen der gesammelten Daten. ausführliches Umfragesystem in die Anwendung einbauen. Weitere Zusatzfunktionen in App und Weboberfläche integrieren. Umsetzung eines Widget, zum hochladen der Daten. 12. Ergänzungen Die App wird auf dem Webserver zur Verfügung gestellt. Mittels QR-Code kann der Downloadlink an die Probanden verteilt werden. Anhänge: Glossar Data Dictionary Klassendiagramm Use Case Diagramm 8

10 Hochschule Mitttweida Anhang: Glossar 9

11 Erhebungsdaten Umfrage loggen Mini-Umfrage Enthalten alle Information. Das Heißt die ausgelesenen Sensordaten, die Gespeicherten Geodaten und die abgefragten Werte einer Umfrage Gezieltes Abfragen an Informationen mittels selbstbestimmter Fragen permanentes Aufzeichnen der Daten Eine sehr vereinfachte Umfrage, die nur aus ein paar wenigen Dialogen besteht. Dient dazu um im Vorfeld Daten zu sammeln, bevor ein bestehendes Umfragesystem integriert wird 10

12 Hochschule Mitttweida Anhang: Data Dictionary 11

13 FT-Nr. Name Datentyp Beschreibung/Kommentar /FT 999/ Geodaten/ID Laufende Nummer, immer von 1 integer beginnend /FT 100/ Geodaten/UUID varchar {Zeichen}36; GeräteID /FT 012/ Geodaten/DatumZeit " :00:00" datetime Datum und Uhrzeit des Tracks /FT 013/ Geodaten/gpsLatitude float Breitengrade /FT 014/ Geodaten/gpsLongitude float Längengrade /FT 015/ Geodaten/gpsAltitude float Höhengrade /FT 999/ Sensordaten/ID Laufende Nummer, immer von 1 integer beginnend /FT 100/ Sensordaten/UUID varchar {Zeichen}36; GeräteID /FT 021/ Sensordaten/DatumZeit " :00:00" datetime Datum und Uhrzeit des Tracks /FT 022/ Sensordaten/accelerometerX float Bewegung an der X-Achse, in m/s² /FT 023/ Sensordaten/accelerometerY float Bewegung an der Y-Achse, in m/s² /FT 024/ Sensordaten/accelerometerz float Bewegung an der Z-Achse, in m/s² /FT 025/ Sensordaten/gyroscopeX float Rotation an der X-Achse, in rad/s /FT 026/ Sensordaten/gyroscopeY float Rotation an der Y-Achse, in rad/s /FT 027/ Sensordaten/gyroscopeZ float Rotation an der Z-Achse, in rad/s /FT 028/ Sensordaten/orientationAzimuth float Grad um die Z-Achse, in Grad /FT 029/ Sensordaten/orientationPitch float Grad um die X-Achse, in Grad /FT 020/ Sensordaten/orientationRoll float Grad um die Y-Achse, in Grad /FT 999/ User/ID Laufende Nummer, immer von 1 integer beginnend /FT 031/ User/Login {Zeichen}8; kurzer Loginname (Aus Vor- und Nachnamen generiertes varchar Kürzel) /FT 032/ User/Passwort varchar {Zeichen}32; gehashtes Passwort /FT 033/ User/Vorname varchar {Zeichen}20; Vorname des Users /FT 034/ User/Nachname varchar {Zeichen}20; Nachname des Users /FT 035/ User/ varchar {Zeichen}50; des Users Laufende Nummer, immer von 1 /FT 999/ Historie/ID integer beginnend Zeitstempel wann die Aktion vom /FT 041/ Historie/Zeit timestamp Verantwortlichen durchgeführt wurde ID des Users, welcher diese Aktion /FT 999/ Historie/UserID integer durchführte {Zeichen}255; Kurzbeschreibung der /FT 042/ Historie/Aktion varchar ausgeführten Aktion (Programmgeneriert) /FT 043/ Historie/Gerät varchar {"App", "Server"} 12

14 Hochschule Mitttweida Anhang: Klassendiagramme 13

15 14 Pflichtenheft

16 Hochschule Mitttweida Anhang: Use Case Diagramm 15

17 16 Pflichtenheft