Pflichtenheft

== =ACHTUNG! Änderungsstopp am 30.04.2011 17:00 Uhr!!=
 * Pflichtenheft**

Pflichtenheft ->23.4
=**1.Zielbestimmung -> Sebastian**=

1.1. Musskriterien
Aus dem Lastheft ergeben sich folgende Musskriterien

F01 Registrierung
Das Backend muss einen Webservice bereitstellen, über den es möglich ist, dass der neue Benutzer sich ein Benutzerkonto anlegt. Die vom neuen Benutzer eingegebenen Daten müssen durch das Backend persistent abgelegt werden. Der Client für das mobile Endgerät muss eine entsprechenden Maske anbieten, in der der Benutzer alle Pflicht -und optionalen Angaben für das Benutzerkonto eingeben kann. Die Anzeige zum Anlegen eines neuen Benutzerkontos muss die Applikation ermöglichen, ohne dass man sich an der Anwendung anmeldet. Folgende Informationen muss der Werbservice des Backends und die Maske des Clients bei der Erstellung des Benutzeraccounts verarbeiten können:

Passwortbidlungsvorschift: Mindestlänge: 5 Zeichen 1 Sonderzeichen muss enthalten sein ||  || ja || x || x ||
 * Feld || Beschreibung || Optional* || änderbar || Webservice || Client-GUI ||
 * Nickname || Benutzername/Profilname des Nutzers ||  || Nein || x || x ||
 * Passwort || Anwendungspasswort des Nutzers:
 * Vorname || Vorname des Anwenders || x || ja || x || x ||
 * Name || Nachname des Anwenders || x || ja || x || x ||
 * Emailadresse || gültige Emailadresse des Nutzers ||  || ja || x || x ||
 * Mobilfunknummer || Mobilfunknummer des Anwenders ||  || ja || x || x ||
 * Optional markierte Felder sind keine Pflichtfelder, und müssen von dem Benutzer bei der Registrierung nicht angegeben werden. Webservice und Client-GUI müssen diese Felder berücksichtigen.

1.1.2 F02 Anmeldung Bevor ein registrierter Nutzer die Anwendung nutzen kann, muss er sich an der Anwendung mittels Nickname und Passwort oder Emailadresse und Passwort über den Client am Backend anmelden.

1.1.3 F03 Pflege von Profildaten Das Backend muss einen Webservice zur Vefügung stellen, der eine Profildatenpflege ermöglicht. Über die GUI am Client wird die Pflege der Profildaten realisiert. Die Daten werden im Backend abgespeichert. Folgende Profildaten müssen gepflegt werden können:

Muss mindestens aus 5 Zeichen bestehen Muss mindestens ein Sonderzeichen beinhalten || x ||
 * Feld || Beschreibung || Pflichtangabe ||
 * Vorname || Vorname des Anwenders ||  ||
 * Name || Nachname des Anwenders ||  ||
 * Emailadresse || E-Mail Adresse des Anwenders || x ||
 * Passwort || Frei wählbares Passwort des Anwenders
 * Mobilfunktnummer || Mobilfunknummer des Anwenders || x ||
 * Telefon || Zusätzliche Telefonnummer des Anwenders ||  ||
 * PLZ || PLZ der Heimatadresse ||  ||
 * Ort || Ort der Heimatadresse ||  ||
 * Strasse || Strasse der Heimatadresse ||  ||
 * Hausnummer || Hausnummer der Heimatadresse ||  ||
 * Führerschein seit || Datum, seit dem der Anwender seinen Führerschein besitzt ||  ||
 * Geburtstag || Geburtsdatum ||  ||
 * Fahrzeug || Fahrzeugmarke und Modell (Frei Editierbar) ||  ||
 * Raucher || Raucher (Ja, Nein) ||  ||
 * Umwege || Nimmt der Anwender Umwege in Kauf (Ja, Nein) ||  ||
 * Profilfoto || Profilfoto des Anwenders ||  ||

1.1.4 F04 Mitfahrgelegenheit anbieten Der Client bietet eine Oberfläche, mit der es möglich ist alle relevanten Informationen zu einer Mitfahrgelgenheit, die man anbieten möchte anzugeben. Das Backend bietet einen entsprechenden Webservice an, der die Daten entgegennehmen und verarbeiten kann. Folgende Daten können eingegeben werden:

Alternativ muss der Anwender hier auch Sofort auswählen können || x ||
 * Feld || Beschreibung || Pflichtangabe ||
 * Start || Adresse von wo der Fahrer die Reise antreten möchte || x ||
 * Ziel || Genaue Adresse des Reiseziels (Mind.: PLZ, Ort, Str.) oder Koordinaten || x ||
 * Reisebeginn || Datum des Reisestarts
 * Freie Sitzplätze || Anzahl möglicher Mitfahrer || x ||

Zur Unterstützung des Nutzers kann auf Fahrtangebote zurückgegriffen werden können, welche der Fahrer in der Vergangenheit angeboten hat. Als Startadresse kann der Nutzer seine aktuelle Position übernehmen. Die Position wird dann über die Geolocationsfunktionen des Endgerätes möglichst genau ermittelt.

1.1.5 F05 Mitfahrgelegenheit suchen/Mitfahrgesuch aufgeben Die Android-Applikation und das Backend realisieren eine Funktion, die es ermöglicht, eine Mitfahrgelgenheit zu suchen. Im Client müssen dazu folgende Informationen angegeben werden:


 * Feld || Beschreibung || Pflichtangabe ||
 * Start || Adresse, von der der Mitfahrer abgeholt werden möchte || x ||
 * Ziel || Genaue Adresse des Reiseziels (Mind.: PLZ, Ort, Str.) || x ||
 * Reisebeginn || Datum/Uhrzeit des gewünschten Reisestarts oder Sofort || x ||

Die GUI unterstützt den Fahrtsucher bei der Eingabe der Daten anhand von Maskeneingaben aus der Vergangenheit. Auf Wunsch des kann die Startadrasse möglichst genau durch die Geolocationsfunktionen des mobilen Endgerätes ermittelt werden. Wird als Reisebeginn Sofort gewählt, wird als Startadresse immer die aktuelle Position des Nutzers angegeben. Hierzu wird auf Geolocationsfunktionen des mobilen Endgerätes zurückgegriffen.

Das Backend nimmt die Daten entgegen und wertet sie, sodass zur Suche passende Ergebnisse an den Client gesendet werden. Der Client stellt die Ergebnisse in einer Tabelle dar. Folgende Informationen werden an den Client zurückgeliefert:

bei angetretener Fahrt aktuelle Position des Fahrers ||
 * Feld || Beschreibung ||
 * Nickname || Nickname des Fahrtanbieters ||
 * Start/Position* || Startort des Fahrers
 * Ziel || Ziel der angebotenen Reise des Fahrers ||
 * Reisedatum || Datum/Uhrzeit Fahrtantritt der Reise ||
 * Bewertung || Durchschnittsnote aller Bewertungen ||
 * Bewertungsanzahl || Anzahl der Bewertungen ||


 * Es wird nicht die genaue Position des Fahrers übergeben, sodass Stalking erschwert wird.

1.1.6 Mitfahrgesuche anzeigen Ein Fahrer, der eine Fahrt anbietet und schon eingegeben hat, kann die Möglichkeite nutzen, sich Mitfahrgesuche anzeigen zu lassen, die seiner geplanten Fahrt entsprechen. Für die Suche kann er zuvor eingeben, in welchem Umkreis um seine Startposition oder auch aktuelle Position nach Mitfahrerern gesucht werden soll. Die aktuelle Position wird durch Funktionen des Endgerätes ermittelt. Die Applikation realisiert eine Eingabemaske für den Fahrer um Mitfahrgesuche ermitteln zu können. Die Eingabemaske zeigt zunächst alle geplanten und noch nicht abgeschlossenen Fahrten des Nutzers. Hier kann der Nutzer die Fahrt aussuchen, für die er Mitfahrer suchen möchte. Die Eingabe der gewünschten Umkreissuche wird ermöglicht. Die Daten der Anfrage werden an das Backend übermittelt. Der Webservice des Backendes muss die Daten vom Client verarbeiten können. Das Backend ermittelt anhand des aktuellen Datenbestandes alle Mitfahrgesuche, die zu der Suche des Fahrers passen und übermittelt das Ergebnis an den den Client. Der Client stellt die empfangenen Daten in einer Tabelle dar. Folgende Daten werden je potentiellem Mitfahrer präsentiert

oder die aktuelle Position des Suchers ||
 * Feld || Beschreibung ||
 * Nickname || Nickname des Fahrtsuchers ||
 * Start/Position* || Startort des Fahrtsuchers
 * Ziel || Wunschziel Fahrtsuchers ||
 * Reisedatum || Datum/Uhrzeit Fahrtantritt der Reise ||
 * Bewertung || Durchschnittsnote aller Bewertungen ||
 * Bewertungsanzahl || Anzahl der Bewertungen ||


 * Um Stalking zu erschweren wird die aktuelle Position des Fahrtsuchers ungenau angezeigt.

Der Nutzer kann sich Profilinformationen und Bewertungen, der User, die in der Ergebnismenge enthalten sind anzeigen lassen.

1.1.7 Mitfahrgelgenheit/Mitfahrgesuch löschen 1.1.7.1 Mitfahrgelegenheit löschen Die GUI bietet die Möglichkeit angebotene, aber noch nicht angetretene Reiseangebote des eigenen Benutzers zu löschen. Das Backend bietet dazu einen passenden Webservice an. Auf Backendseite wird sichergestellt, dass der angemeldete Benutzer nur seine eigenen Angebote löschen kann. Die GUI listet in einer Tabelle die noch nicht angetretenen Angebote auf. Folgende Information je Angebot werden dem Nutzer präsentiert:


 * Feld || Beschreibung ||
 * Start || Startadresse ||
 * Ziel || Zieladresse ||
 * Datum || Reisedatum ||

1.1.7.2 Mitfahrgesuch löschen Die GUI bietet dem Nutzer die Möglichkeit eigene, eingegebene Reisegesuche zu löschen. Das Backend bietet dazu einen passenden Webservice an. Auf Backendseite wird sichergestellt, dass der angemeldete Benutzer nur seine eigenen Gesuche löschen kann. Die GUI listet in einer Tabelle die eingegebenen Gesuche auf. Folgende Information je Gesuch werden dem Nutzer präsentiert:


 * Feld || Beschreibung ||
 * Start || Startadresse ||
 * Ziel || Zieladresse ||
 * Datum || Reisedatum ||

1.1.8 Benachrichtigung bei passenden Reisezielen / Fahrtangeboten Wenn die Anwendung auf dem Endgerät läuft und der Benutzer angemeldet ist, fragt die Anwendung in regelmäßigen Intervallen bei dem Backend an. Hat der Nutzer ein Mitfahrgesuch oder eine Mitfahrangebot auf dem Server veröffentlicht, ermittelt der Server bei jeder Anfrage des Endgerätes, ob entsprechende Angebote oder Gesuche eingegeben wurden und übermittelt diese an das Endgerät. Ist die Anwendung auf dem Endgerät im Vordergrund, so werden die gefundenen Ergebnisse sofort auf dem Bildschirm angezeigt. Die Anzeige erfolgt in einer Tabelle wie in 1.1.5 und 1.1.6 beschrieben. Befindet sich die Anwendung im Hintergrund, so wird bei neu gefundenen Ergebnissen ein Symbol in der Statusleiste des Endgerätes angezeigt.

1.1.9 Bewertung abgebgen Der Client bietet über eine Maske eine Bewertungsmöglichkeit. Auf der Bewertungsmaske werden alle anderen Nutzer angezeigt, für die man eine Bewertung abgeben kann. Je möglicher Bewertung wird eine Tabellenzeile angezeigt. Folgende Inhalte hat jede Zeile:


 * Feld || Beschreibung ||
 * Datum || Datum an dem die Fahrt stattgefunden hat ||
 * Start || Startort der Fahrt ||
 * Ziel || Zielort der Fahrt ||
 * Nickname || Nickname des zu bewertenden Nutzers ||
 * Rolle || Rolle des zu bewertenden Nutzers (Fahrer/Mitfahrer) ||

Durch Antippen der Zeile kann für diese Fahrt eine Bewertung eingegeben werden. Es wird eine weitere Maske geöffnet. In dieser Maske kann ein Freitext von 255 Zeichen eingegeben werden. Darüberhinaus kann eine Punktzahl (1-5) für die Bewertung angegeben werden, wobei 5 die höchste Wertigkeit darstellt.

Bedingungen für die Bewertung eines anderen Nutzers: Eine Bewertung eines anderen Nutzers ist nur dann möglich, wenn der bewertende Nutzer und der zu bewertende Nutzer in unterschiedlichen Rollen an der gleichen Fahrgemeinschaft teilgenommen haben. Bis zu 1 Monat nach Beendigung einer gemeinsamen Fahrt ist eine Bewertung möglich.

Das Backend liefert dem Client die Daten für die Auswahltabelle der Bewertung. Es liefert nur die Daten, die für den angemeldeten/anfragenden Nutzer relevant sind. Das Backend stellt einen Webservice zur Verfügung, der die Bewertungsinformationen für einen Nutzer (Freitext, Punktzahl) entgegennehmen kann. Die Bewertungsinformationen werden in der Datenbank abgelegt. Das Backend stellt sicher, dass die weiter oben beschriebenen "Bedingungen für die Bewertung eines anderen Nutzers" eingehalten werden.

1.1.10 Passwort zurücksetzen Die GUI realisiert die Möglichkeit das Passwort eines Nutzers zurücksetzen zu lassen. Zur Rücksetzung wird die Emailadresse benötigt, mit welcher der Nutzer registriert ist. Das Backend realisiert einen Webservice, der die Emailadresse von der Clientanwendung entgegennimmt. Im Backend wird dann ein neues Passwort generiert, bei den Userdaten abgespeichert und an die Emailadresse des Nutzers gesendet.

1.1.11 Historie eines Benutzers Die GUI bietet einen Screen, mit dem es dem angemeldeten Nutzer möglich ist alle seine Mitfahrgesuche, Mitfahrangebote und genutzte Mitfahrgelgenheiten anzuzeigen. Je nach Displaygröße des Endgerätes wird nur ein Teil angezeigt. Durch klicken auf Mehr können weitere historische Einträge abgerufen werden. Aus diesem Screen heraus ist es möglich, nicht mehr gewünschte Angebote und Gesuche zu löschen (siehe 1.1.7).

Das Backend stellt der Clientanwendung die Daten bereit. Der Webservice des Backendes wird so implementiert, das nur die vom Client angefrangte Menge von historischen Einträgen übermittelt wird.

1.1.12 Administrative Eingriffe Die administrativen Eingriffe erfolgen direkt auf der Datenbank. Es werden entsprechende Views, Funktionen und Skripte auf der Datenbank realisiert, um folgende Funbktionen zur Administration zu ermöglichen:


 * Deaktivierung eines Accounts
 * Aktivierung eines Accounts
 * Passwort Neugenerierung
 * Löschen von Bewertungen

1.1.13 Anzeige von Profilinformationen eines anderen Nutzers Verschiedene Fälle der Anwendung erfordern es, dass ein Nutzer das Profil eines anderen Nutzers einsehen kann, z.B. bei dem Use-Case "Mitfahrgelgenheit suchen" muss der Benutzer sich die Profilinformationen des Fahrtanbieters anschauen können um zu entscheiden, ob er mit dem Fahrer mitfahren möchte und um Kontakt aufzunehmen. Der Webservice der Anwendung sendet die Profilinformationen an den Client. Das Backend stellt sicher, dass eine Massenauslesung der Profilinformationen nicht möglich ist. Der Client kann nur die Profile abrufen, die innerhalb seines aktuellen Use-Cases für ihn relevant sind. Beispiel Use-Case Fahrten suchen:
 * Der Mitfahrer sucht eine Mitfahrgelgenheit
 * Die Ergebnisse der Suche werden in einer Tabelle angezeigt.
 * Der Mitfahrer kann sich jetzt nur die Profile der anderen Nutzer anzeigen lassen, die in der Ergebnissmenge der vorherigen Suche enthalten sind.

In der Client-Anwendung werden über die GUI die Profilinformationen angezeigt. Folgende Profildaten werden vom Backend gesendet und vom Client angezeigt:


 * Feld || Beschreibung ||
 * Nickname || Nickname des Anwenders ||
 * Vorname || Vorname des Anwenders ||
 * Name || Nachname des Anwenders ||
 * Emailadresse || E-Mail Adresse des Anwenders ||
 * Mobilfunktnummer || Mobilfunknummer des Anwenders ||
 * Führerschein seit || Länge des Führerschein ||
 * Alter || Alter des Fahrers ||
 * Fahrzeug || Fahrzeugmarke und Modell (Frei Editierbar) ||
 * Raucher || Raucher (Ja, Nein) ||
 * Profilfoto || Profilfoto des Anwenders ||

1.1.14 Anzeige von Bewertungen Verschiedene Fälle der Anwendung erfordern es, dass ein Nutzer die Bewertungen eines anderen Nutzers einsehen kann, z.B. bei dem Use-Case "Mitfahrgelgenheit suchen" dienen diese als Entscheidungshilfe für den Mitfahrer, ob er mit einem Fahrer eine Fahrgemeinschaft eingehen möchte

Der Webservice der Anwendung sendet die Bewertungen des entsprechenden Nutzers an den Client. Das Backend stellt sicher, dass eine Massenauslesung der Bewertungen nicht möglich ist. Der Client kann nur die Bewertungen abrufen, die innerhalb seines aktuellen Use-Cases für ihn relevant sind. Beispiel Use-Case Fahrten suchen:
 * Der Mitfahrer sucht eine Mitfahrgelgenheit
 * Die Ergebnisse der Suche werden in einer Tabelle angezeigt.
 * Der Mitfahrer kann sich jetzt nur die Bewertungen der anderen Nutzer anzeigen lassen, die in der Ergebnissmenge der vorherigen Suche enthalten sind.

In der Client-Anwendung werden über die GUI die Bewertungen angezeigt. Folgende Bewertungsinformationen werden vom Backend gesendet und vom Client angezeigt:

0.n: ein Nutzer kann beliebig viele Bewertungen haben. Das Backend überträgt zunächst die aktuellesten. Um Datenvolumen zu sparen werden nicht alle Bewertungen übertragen. In der Anfrage des Clients kann die Anzahl der Bewertungen und die "Seite" mitgegeben werden. Wird keine Anzahl mitgegeben, so lierfert das Backend die 5 aktuellsten Bewertungen. Unter Seite ist zu verstehen, dass auch ältere Bewertungen abgerufen werden können.
 * Feld || Beschreibung ||
 * Nickname || Nickname des Nutzers auf den die Bewertung zutrifft ||
 * Durchschnittsnote || Durchschnittsnote aller Bewertungen ||
 * Gesamtanzahl || Gesamtanzahl der Bewertungen ||
 * 0.n Einzelnote || Einzelnote je Bewertung ||
 * 0.n Bewertungsfreitext || Freitext je Bewertung ||
 * 0.n Datum || Datum der Bewertung ||
 * Rolle || Fahrer oder Beifahrer bei dieser Bewertung ||

Beispiel: Anzahl von Bewertungen pro Seite = 7 1.1.2 sonstige Musskriterien
 * Seite || Bewertungen ||
 * 1 || 1 - 7 ||
 * 2 || 8 - 14 ||
 * 6 || 43 - 49 ||

1.1.2.1 Standardschnittstellen Das Backend verwendet zur Kommunikation mit dem Client standardisierte Protokolle und Schnittstelle, damit auch andere mobile Endgeräte als Android angebunden werden können.

1.1.2.1 Bedienungsoberfläche Die Bedienungsoberfläche wird selbsterklärend gestaltet, eine Bedienung mittels Touchscreen wird ermöglicht.

1.2. Wunschkriterien 1.2.1 Ameldung an der Anwendung über Facebook 1.2.2 Posting vo nFahrtangebote und –gesuche aufder Facebookseite des jeweiligen Users 1.2.3 Aktualisierung der Position des Nutzers auf der zugehörigen Facebookseite 1.2.4 Darstellung der Fahranbieter/Fahrtsucher auf einer Karte 1.2.5 Anzeige von Fahrtsuchern die sich in der Nähe der Wegstrecke des Fahrers befinden

1.3. Abgrenzungskriterien 1.3.1 Oberfläche für Geräte der Smartphoneklasse Die Oberfläche wird für Androidgeräte mit einem Display von bis zu 5 Zoll entwickelt. Die Anwendung ist auf Tablet-PC mit Android-Betriebssystem lauffähig, aber wird nicht für die größeren Displays optimiert.

1.3.2 Einsatzort Die Applikation und das Backend werden für den Einsatz in Deutschland entwickelt.

=2. Produkteinsatz= Im folgenden Abschnitt wird auf den Produkteinsatz der Applikation eingegangen. Dabei wird im Anwendungsbereich der Zweck der Applikation erläutert. Bei den Zielgruppen geht es darum zu erläutern, welche Personen mit welchen Qualifikationen die Anwendung nutzen sollen und bei den Betriebsbedingungen geht es darum, diese zu erläutern. [1]

[1] Vgl. [] (23.04.2011, 12:50 Uhr).

Die Anwendung wird von einzelnen Personen zur Suche von Mitfahrgelegenheiten und zum Bekanntmachen einer Fahrt genutzt. Dem Anwender wird es so ermöglicht, Kosten zu sparen, indem er sich an einer Fahrt beteiligt oder selbst eine Fahrt tätig und hier andere Nutzer mitnimmt. Zur Ziel gehören, die im Lastenheft erörterten Personen. Die Anwender sollten ein Smartphone mit Internetzugang und dem Betriebssystem Android besitzen. Weiterhin sollten Kenntnisse im Umgang mit dem Umgang von Smartphone Applikationen vorhanden sein. Da die Software in deutscher Sprache umgesetzt wird, sollte der Anwender diese Sprache beherrschen. Hinsichtlich der Betriebsbedingungen orientiert sich die Anwendung an den üblichen Bedingungen von Smartphone Applikationen und Webservices: [1] - Betriebsdauer: 24 Stunden täglich - Wartungsfrei - Keine ständige Beobachtung des Systems nötig
 * 2.1. Anwendungsbereiche
 * 2.2. Zielgruppen
 * 2.3. Betriebsbedingungen

[1] Vgl. [] (23.04.2011, 12:50 Uhr).

=3. Produktumgebung=

3.1.1.Software
Für die Android Endgeräte wird die Betriebssystemversion 2.1 Codename Eclair verwendet. Durch die Verwendung dieser Version können laut der unten zu sehenden Grafik bis zu über 90% aller Android Usern durch die AppFahrt unterstützt werden. Somit würde im Gegensatz zur Implementiertung für eine höhere Androidversion wie beispielsweise 2.3 ein höhere Abdeckung möglich sein, da Apps grundsätzlich abwärtskompatibel sind.

Quelle (http://developer.android.com/resources/dashboard/platform-versions.html .- Stand 25.04.2011)

Im Gegensatz zur Version 2.2 weist die aktuelle Version 2.3 Codename Gingerbread keine für diese Applikation nennenswerte Vorteile, sodass diese ausgeschlossen werden kann.

3.1.2 Oberfläche
Um die geforderten Anforderungen benuterfreundlich zu realisieren werden folgende Oberflächen in der Android App realisiert. Detailierte Beschreibung sowie Abbildungen erfolgen im Kapitel Benutzungs- und Systemschnittstellen.
 * App Start
 * ProfilerstellenFacebook Login
 * Facebook Aktionen - Login
 * Map
 * Map - Fahrt antreten
 * Map - Fahrt suchen
 * Map - Fahrt bewerten

Für die Entwicklung der clientseitigen Applikation werdne folgende Komponenten eingesetzt:

 * ====als Programmiersprache Java====
 * ====als Entwicklungsumgebung Eclpise Helios Service Release====
 * ====Andorid SDK für Eclipse====
 * Android Emulator (enthalten im Android SDK)
 * Facebook API
 * OpenStreetMap - Osmdroid Projekt
 * CloudMade Registrierung

3.2. Hardware
Die Applikation ist so konzepiert, dass diese auf allen Smartphones mit der Betriebssystemversion 2.1 Codename Eclair lauffähig ist. Grundsätzlich ist die haupt Androidplattform die ARM Architektur Der größte Vorteil der ARM Architektur ist die geringe Leistungsaufnahme, wodruch diese Architektur insbesondere für mobile Endgeräte eingesetzt wird. (Quelle http://en.wikipedia.org/wiki/Android_%28operating_system%29#Hardware_running_Android)

3.4 Voraussetzung für die Nutzung der Applikation
Für die Nutzung der Applikation ist sowohl eine Internetverbindung als auch GPS Verbindung zwingend notwendig. Die Internetverbindung ist sowohl für die Verbindung zum Webserver der Anwendung notwendig als auch für die Verbindung zu den Servern von CloudMade und OpenStreetMap. Durch eine aktive GPS Verbindung ist die Ermittlung der aktuellen Position möglich. Weiterhin werden die GPS Koordinaten serverseitig benötigt, um die notwenidgen Berechnungen durchführen zu können und potentielle Mitfahrer und Fahrer zu verbinden.

3.4. Produkt – Schnittstellen
Die clientseitige Applikation verfügt über Webserviceschnittstellen, die für die Kommunikation zum Webserver dienen. Darüberhinaus ist eine Schnittstelle zum Facebookdienst vorhanden. Die Anwendung immplementiert die Facebook API und greift über das Internet auf die Facebook Webserver zu und ermöglicht so die Nutzung der zu Verfügung gestellten Services. Weiterhin nutzt die clientseitige Anwendung den Webservice von Cloudmade und Open Street Map für die Darstellung der aktuellen Positon auf der Karte.

=**4. Akteure und Anwendungsfälle**=

4.1 Akteure
Für das System AppFahrt werden vier Akteure modelliert. Die Akteure Mitfahrer, Fahrer und Adminstrator sind eine Generalisierung des Akteurs Anwender, der einen generische Akteur darstellt.



Nachfolgend eine Kurzbeschreibung der vier Akteure:


 * **Name** || **Kurzbeschreibung** ||
 * Anwender || Stellt einen Rumpf-Akteur dar, von dem alle weiteren Akteure abgeleitet werden. ||
 * Fahrer || Ein Fahrer bietet im System Fahrten an. Ein Fahrer kann prinzipiell auch ein Mitfahrer sein, jedoch nicht bei der gleichen Fahrt. ||
 * Mitfahrer || Ein Mitfahrer sucht nach Fahrten bei denen er mitfahren kann. Ein Mitfahrer kann prinzipiell auch ein Fahrer sein, jedoch nicht bei der gleichen Fahrt. ||
 * Administrator || Ist eine übergeordnete Instanz mit besonderen Berechtigungen. ||

4.2 Use Case Überblick


Im weiteren Verlauf der Spezifikation und Entwicklung werden zur Wahrung des Projektrahmens nur die Anwendungsfälle des Pakets"Fahrt planen und durchführen" weiter betrachtet. Die charakteristischen Funktionen des Systems AppFahrt sind in diesem Paket enthalten. Anwendungsfälle der weiteren Pakete Userprofil verwalten und Administration enthalten Funktionalitäten, so z.B. der Anwendungsfall Userprofil bearbeiten, die in herkömmlichen IT-Systemen enthalten sind und an dieser Stelle nicht detailiert beschrieben werden müssen, wenngleich sie für die Umsetzung des Gesamtsystems notwendig sind.

4.2.1 Fahrt planen
Fahrer ist am System angemeldet. || 2. Der Fahrer gibt den Endpunkt der Fahrt ein. 3. Das System macht einen Vorschlag für den Fahrpreis. Der Fahrer gibt den Fahrpreis an. 4. Der Fahrer gibt einen Starttermin der Fahrt an (Datum und Uhrzeit). 5. Der Fahrer gibt die Anzahl der freien Plätze an. 6. Der Fahrer veröffentlicht die Fahrt. 7. Das IT-System bietet die Möglichkeit eine Rückfahrt einzugeben. || 4. Der Fahrer gibt als Starttermin "Sofort" ein. ||
 * Name und Identifier || 1.1 Fahrt planen ||
 * Beschreibung || Ein Fahrer plant eine Fahrt und bietet Mitfahrern die Möglichkeit sich für diese Fahrt anzumelden. ||
 * Beteiligte Akteure || Fahrer ||
 * Status || final ||
 * Verwendete Anwendungsfälle || - ||
 * Auslöser || - ||
 * Vorbedingungen || Fahrer hat ein Userprofil
 * Invarianten ||  ||
 * Ergebnis || Fahrt ist angelegt und für Mitfahrer sichtbar. ||
 * Standardablauf || 1. Der Fahrer gibt den Startpunkt der Fahrt ein.
 * Alternative Ablaufschritte || 1. Der Fahrer gibt seine aktuelle GPS-Position als Startpunkt ein.
 * Hinweise || - ||
 * Änderungsgeschichte || 28.03.2011, OW Ersterstellung ||

4.2.2 Mitfahrwunsch angeben
Standardablauf: Es existiert bereits eine passende Fahrt, die der Mitfahrer auswählen kann.
 * Name und Identifier || 1.2 Mitfahrwunsch angeben ||
 * Beschreibung || Ein Mitfahrer sucht eine Mitfahrt. Dabei können die folgenden Fälle unterschieden werden.

Alternative Ablaufschritte: Es gibt keine passende Fahrt. Der Mitfahrer veröffentlicht seinen Mitfahrwunsch, mit dem Ziel, dass sich ein Fahrer dazu findet.

In diesem Use Case können auch Mitfahrwünsche für bereits aktiven Fahrten (D.h. die Fahrt ist bereits angetreten) angegeben werden. Die Anzeige bzw. Auswahl von aktiven Fahrten ist abhängig von den einzugebenen Suchkriterien (Abfahrtort, Abfahrttermin) einer Fahrt. || Mitfahrer ist am System angemeldet. || 2. Das IT-System liefert den Suchkriterien entsprechende Fahrten zur Auswahl zurück. 3. Der Mitfahrer wählt eine Fahrt aus. 4. Der Mitfahrer äußert seinen Mitfahrwunsch gegenüber dem Fahrer. || 3. Der Mitfahrer veröffentlicht seinen Mitfahrwunsch mit den in den Suchkriterien angegebenen Attributen (Startpunkt, Endpunkt, Termin). 4. Der Mitfahrer gibt einen Fahrpreis an. 4. Der Mitfahrer veröffentlicht seinen Mitfahrwunsch. Der Mitfahrwunsch ist für Fahrer sichtbar. ||
 * Beteiligte Akteure || Mitfahrer. ||
 * Status || final ||
 * Verwendete Anwendungsfälle || - ||
 * Auslöser || - ||
 * Vorbedingungen || Mitfahrer hat ein Userprofil.
 * Invarianten ||  ||
 * Ergebnis || Der Mitfahrer hat seinen Mitfahrwunsch veröffentlicht. Der Fahrer kann den Mitfahrwunsch akzeptieren. ||
 * Standardablauf || 1. Der Mitfahrer sucht nach einer Fahrt. Suchkriterien sind Startpunkt, Endpunkt und Uhrzeit. Die freien Plätze einer Fahrt werden dabei berücksichtigt.
 * Alternative Ablaufschritte || 2. Das IT-System liefert kein passendes Ergebnis. Der Mitfahrer kann seine Suchkriterien anpassen.
 * Hinweise || 1. Als Startpunkt können Startpunkt kann "Hier" angegeben werden. Dies ist die aktuelle GPS-Position. Als Startzeitpunkt kann "Jetzt" angegeben werden. Dies ist die aktuelle Uhrzeit. ||
 * Änderungsgeschichte || 28.03.2011, OW Ersterstellung. ||

4.2.3 Mitfahrwunsch annehmen

 * Name und Identifier || 1.3 Mitfahrwunsch annehmen ||
 * Beschreibung || Ein Fahrer hat seine Route geplant. Ein oder mehrere Mitfahrer haben einen Mitfahrwunsch gegenüber angegeben. Der Fahrer bestätigt den Mitfahrwunsch.

Dabei ist es unerheblich, ob die Fahrt noch geplant oder bereits aktiv ist. || Fahrer hat ein Userprofil. Fahrer ist am System angemeldet. || 2. Der Fahrer kontaktiert den Mitfahrer. 3. Der Fahrer bestätigt den Mitfahrwunsch. Die Anzahl freier Plätze wird aktualisiert. 4. Der Mitfahrer erhält eine Bestätigung der Mitfahrt per Email/ SMS. ||
 * Beteiligte Akteure || Fahrer, Mitfahrer ||
 * Status || final ||
 * Verwendete Anwendungsfälle || - ||
 * Auslöser || Mitfahrwunsch wurde angegeben. ||
 * Vorbedingungen || Mitfahrwunsch liegt vor
 * Invarianten || - ||
 * Ergebnis || Mitfahrwunsch ist angenommen. Mitfahrer wird über die Annahme des Mitfahrwunschs informiert. ||
 * Standardablauf || 1. Dem Fahrer werden Mitfahrwünsche angezeigt.
 * Alternative Ablaufschritte || 3. Der Fahrer lehnt den Mitfahrwunsch ab. Es erfolgt keine weitere Aktion bezüglich des abgelehnten Mitfahrwunsches. Der Fahrer wählt einen weiteren Mitfahrwunsch aus und kann wiederum über den Mitfahrwunsch entscheiden. ||
 * Hinweise || Die Anzeige der Mitfahrwünsche kann Mitfahrwünsche enthalten, die entlang der aktiven Fahrt liegen oder die auf der vor Fahrtantritt geplanten Route liegen. ||
 * Änderungsgeschichte || 28.03.2011, OW Ersterstellung. ||

4.2.4 Fahrt antreten und tracken
Fahrer hat ein Userprofil Fahrer ist am System angemeldet. || 2. Fahrer aktualisiert die Anzahl der freien Plätze. 3. Fahrer startet seine Fahrt. 4. Die Position des Fahrers wird geändert und zyklisch aktualisiert. 5. Der Fahrer beendet die Fahrt. || 26.04.2011, OW Erweiterung. ||
 * Name und Identifier || 1.4 Fahrt antreten und tracken ||
 * Beschreibung || Eine geplante Fahrt wird gestartet. Während der Fahrt wird die Position des Fahrers erfasst und aktualisiert. ||
 * Beteiligte Akteure || Fahrer, Mitfahrer ||
 * Status || final ||
 * Verwendete Anwendungsfälle ||  ||
 * Auslöser || Route wurde geplant. Starttermin ist eingetreten. ||
 * Vorbedingungen || Route ist geplant.
 * Invarianten ||  ||
 * Ergebnis || Fahrt ist aktiv und wird getrackt. ||
 * Standardablauf || 1. Mitfahrer treffen Fahrer am vereinbarten Startpunkt zur vereinbarten Startzeit.
 * Alternative Ablaufschritte || Schritt 1 ist optional. Der UC kann auch mit Schritt 2 beginnen. ||
 * Hinweise || Beginnt ein Fahrer seine Fahrt, wird seine aktuelle Position an den Server gesendet, wenn er noch Kapazitäten frei hat ||
 * Änderungsgeschichte || 28.03.2011, OW Ersterstellung.

4.2.5 Fahrt bewerten
Fahrer hat ein Userprofil Fahrer ist am System angemeldet. || 2. Fahrer klick auf "Fahrt bewerten". 3. Fahrer vergibt Bewertungspunkte für einen Mitfahrer. 4. Fahrer schreibt als Bewertung einen Freitext. 5. Fahrer klickt auf "Bewertung absenden" ||
 * Name und Identifier || 1.5 Fahrt bewerten ||
 * Beschreibung || Während oder nach einer Fahrt können sich die Fahrer und Mitfahrer gegenseitig bewerten. Mitfahrer sollen sich jedoch nicht gegenseitig bewerten können. ||
 * Beteiligte Akteure || Fahrer, Mitfahrer ||
 * Status || final ||
 * Verwendete Anwendungsfälle ||  ||
 * Auslöser || Fahrt ist angetreten oder beendet ||
 * Vorbedingungen || Fahrt ist geplant.
 * Invarianten ||  ||
 * Ergebnis || Fahrer und Mitfahrer einer Fahrt wurden bewertet ||
 * Standardablauf || 1. Fahrer wählt eine Fahrt aus.
 * Alternative Ablaufschritte || - ||
 * Hinweise || Bewertung erfolgt genauso für einen Mitfahrer. ||
 * Änderungsgeschichte || 26.04.2011, OW Ersterstellung. ||

**4.2 Domänen-Klassendiagramme ->Marcel + Sebastian**
Das nachstehende Klassendiagramm stellt alle Gegenstände dar, die im Rahmen der geforderten Anwendungsfälle Verwendung finden. Anhand der vorgegebenen Sturktur mit Klassen und Attributen soll die Entwicklung der Anwendung durchgeführt werden. Die aufgezigten Klassen samt Attributen sollen als Basis für den Entwurf genutzt werden, in dem weitere Attribute und vor allem Methoden an den Klassen ergänzt werden müssen, die für die Anwendung benötigt werden.

**App Start**
Beim erstmaligen Start der Applikation wird das AppFahrt Logo dargestellt. Das Logo soll die Applikation einleiten. Nach einigen Sekunden wird das Logo ausgebledet und der Login Screen erscheint. Das Logo erscheint wie bereits erwähnt beim erstmaligen Start der Anwendung. Befindet sich die Anwendung bereits im RAM Speicher des Smartphones erscheint sofort das Login Screen. Wird die Anwendung jedoch vom Android Betriebssystem aus dem RAM entfernt und die Anwendung zum späterem Zeitpunkt gestartet, so wird das Logo wieder dargestellt.

**Login Screen**
Der Login Screen ermöglich wie der Name bereits aussagt das Einloggen eines Benutzers in die Applikation. Hierfür trägt der Anwender seine Email und Passwort in die entsprechenden Felder ein. Die Anmeldedaten werden verefiziert und beim erfolgreichen verefizieren der eingegebenen Daten wird die Map angezeigt. Sind die eingegebenen Daten jedoch fehlerhaft, wird durch eine Meldung der User darauf hingewiesen und die Map wird nicht dargestellt. Enthält der Benutzer noch kein Useraccount für diese Applikation kann dieser durch das auswählen des __Profil erstellen__ Buttons ein Profil für die Applikation anlegen. Weiterhin hat der Anwender die Möglichkeit sich durch sein Facebook Account an der Anwendung anzumelden. Zum Facebook Login Screen gelangt der Anwender durch das klicken auf den Facebook Button.

Falls noch kein Profil für die Applikation vorhanden ist, kann der Anwender wie bereits erwähnt ein Profil erstellen. Der __Kontakdaten__ Screen enthält Eingabefelder für die Eingabe notwendiger Informationen für das Profil. Welche Pflichtfelder befüllt werden müssen, um die einmalige Profilerstellung erfolgreich abzuschließen, kann dem Kaptitel 1.1.1 Funktionale Anforderung entnehmen.Wird ein Pfichtfeld nicht befüllt so erscheint eine Meldung mit dem Pflichtfeld / Pflichtfeldern die noch auszufüllen sind, um das Profil erfolgreich zu erstellen.
 * Profilerstellen**

Möchte man sich mit deinem Facebook Account an der Applikation anmelden, so drückt der Benutzer auf das Facebook Icon Button. Nach dem Klicken verändert sich die Farbe des Icons von blau nach grau. Anschließend erscheint der __Facebook Login Screen__.
 * Facebook Login**

**Facebook Aktionen - Login**
Hier hat der User zunächst die Möglichkeit sich durch das klicken auf den __Login Button__ mit seinem Facebook Logindaten anzumelden.

Es erscheint der __Facebook-Anmeldung__ Bildschirm, wo der Anwender seine Facebook Logindaten eingeben kann und anschließend mit Anmelden bestätigen.

Im nächsten Screen, dem __Anfrage für Genehmigun__g Bildschirm, wird der Anwender aufgefordert durch das Klicken auf den Button __Zulassen__ einige Berechtigung für die Anwendung freizugen. Diese Berechtigung sind notwendig, damit die Anwendung unter anderem auf die Emailadresse des Anwenders zugreifen kann, um diese in die eigene Datenbank abzuspeichern, ähnlich wie beim erstellen eines Profils für die Anwendung. Nach dem erfolgreichen Anmelden am Facebook ist der Anwender in der Lage, durch das klicken auf den Button __Post__ beispielsweise seine geplante Fahrt auf seine Pinwand zu posten. Seine Facebook Freunde sowie die Freunde von AppFahrt bekommen dadurch im Voraus mit welche Fahrt der Anwender plant und können somit den Anwender direkt kontaktieren um ggf. mitfahren zu können.


 * Map**

Nachdem erfolgreichen anmelden an Applikation öffnet sich der __Map Screen__. Es wird die aktuelle Position des Anwenders angezeigt. Die aktuelle Position wird an Hand der GPS Daten ermittelt. Durch das klicken auf die Manü Taste des jeweiligen Smartphones öffnen sich in der unteren Leiste view Menüoptionen.


 * Back - Durch das klicken auf Back gelangt der Anwender wieder zurück auf den Login Screen.
 * Fahrt erstellen... - Durch das klicken auf Fahrt erstellen...gelangt der User in den __Fahrtantritt Screen__
 * Fahrt suchen...- Durch das klicken auf Fahrt suchen...gelangt der User in den __Fahrtgesuch Screen__
 * Fahrt bewerten...- Durch das klicken auf Fahrt bewerten...gelangt der User in den __Fahrtbewerten Screen__


 * Map - Fahrt antreten**

Wie bereits erwähnt durch das klicken auf den Button __Fahrt erstellen...__ erscheint das Fahrtantritt Screen. Hier kann der Anwender eine spontante Fahrt erstellen. Kapitel 1.1.4 Kann man die Pflichtfelder hierfür entnehmen.

Wie bereits erwähnt durch das klicken auf den Button __Fahrt suchen...__ erscheint das Fahrtgesuch Screen. Hier kann der Anwender nach Fahrten suchen. Kapitel 1.1.5 Kann man die Pflichtfelder hierfür entnehmen.
 * Map - Fahrt suchen**

Durch das klicken auf den Button __Fahrt bewerten...__ erscheint der Fahrtbewertung Screen. Hier kann hat der Anwender die Möglichkeit seine Fahrten zu bewerten gemäß der Anforderung im Kapitel 1.1.9.
 * Map - Fahrt bewerten**

**4.3.2 Android Applikation - Schnittstellen**
Android Applikation enthält Schnittstellen zu
 * Facebook - diese Schnittstelle wird verwendet, um das Einloggen des Anwenders mit Facebook zu ermöglichen
 * Webservce der Applikation - diese Schnittstelle dient dem grundsätzlichen Datenaustausch
 * CloudMade - durch dises Schnittstelle erhält die Applikation Geodaten und kann darüber hinaus Routinfunktionen ausführen

**4.3.3 Webserver - Schnittstellen**
Der Webserve enthält Schnittstellen zu
 * Facebook - diese Schnittstelle dient der Abfrage von Benutzerinformationen von Facebook
 * Android Smartphones - diese Schnittstelle dient dem grundsätzlichen Datenaustausch zwischen Server und Clients
 * DB Server - diese Schnittstelle dient der Ausführung der CRUD-Operationen mit der Persistenzschicht des Webservers

=**5.Nicht-Funktionale Anforderungen**=

**5.1 Qualitätsanforderungen -> Aleks(test) + Marcel (technische qualitätssicherung z.b. Zeiten)**

 * TODO:Hier sollten wir auch auf Tests eingehen**

5.1.1 Performance
Anhand von reproduzierbaren Messungen soll die Performance bewertet werden. Folgende Anwendungsfälle müssen in besteimmten Zeitrahmen durchgeführt werden können:

Dies sind die elementaren und zeitkritischen Anwendungsfälle der Anwendung und müssen im Rahmen der angegeben Ladezeigt durchgeführt werden können. Die ist immer ab dem Zeitpunkt zu betrachten, an dem der Anwender seine Daten oder eine Anfrage absendet. Des Weiteren beziehen sich die Ladezeiten auf die Übermittlung der ermittelten Daten an das Endgeärt und schließen die visuelle Darstellung nicht mit ein.
 * **Fall** || **Max. Sekunden Ladezeit** ||
 * Start || 5 ||
 * Anmeldung || 5 ||
 * Mitfahrgesuche anzeigen || 5 ||
 * Mitfahrgelegenheit anbieten || 5 ||
 * Mitfahrgelegenheit suchen || 5 ||

Die Verarbeitung der Daten auf dem Client darf maximal zwei Sekunden in Anspruch nehmen.

5.1.2 Skalierbarkeit
Da die Akzeptanz und somit die Anzahl der gleichzeitig aktiven Benutzer nicht absehbar ist, muss das Backend skalierbar ausgelegt sein. Das Backend muss minimal Anfragen von 100 aktiven Nutzern in der definierten Antwortzeit bearbeiten können. Das System muss flexibel ausgelegt sein, so dass durch hinzunahme weiterer Hardware, Anfragen von bis zu 10.000 aktiven Nutzern in der vorgegebenen Antwortzeit bearbeitet werden können. Um Anschaffungs- und Betriebskosten zu sparen soll das System zunächst für 100 aktive Nutzer ausgelegt sein. Durch die definierten Anforderungen an Performance und Skalierbarkeit werden im Laufe der Entwicklung und der Integrationstests die Anforderung an die Hardware, das Sizing, abgeleitet. Hier wird die Prognose des Wachstums mit einfließen.

Wird ein Performance-Engpass am Client festgestellt, so ist durch einen dynamischen Prozess sicherzustellen, dass ausreichend Ressourcen für diese Anwendung vom Clientbetriebssystem reserviert werden. Ist das beschaffen zusätzlicher Ressourcen vom Clientbetriebssystem nicht möglich, so ist der Benutzer durch eine Meldung über den Ressourcen-Engpass zu informieren.

5.1.3 Verfügbarkeit
Im Lastenheft ist gefordert, dass die Anwendung als hochverfügbar ausgelegt sein muss. In diesem Zusammenhang muss bei der Auswahl des Backendsystems darauf geachtet werden, dass die einzelnen Komponenten diese Anforderung erfüllen. Zu diesem Zweck sollte die Serveranwendeung auf mehreren Instanzen zur Verfügung stehen. Der Client hat dann die Möglichkeit über einen Loadbalancer auf den Server zuzugreifen.

Für etwaige Systemausfälle müssen Backups der Produktivdaten gesichert werden. Das Backup muss sämtliche Applikationsdaten bis zu dem entstandenen Fehlerfall wiederherstellen können.

**5.2 Sicherheit**
Sämtliche Daten der Anwendung müssen vor unbefugtem Zugriff geschützt sein. Zu diesem Zweck muss die Übertragung von personenbezogenen Daten zwischen dem Client und dem Backend verschlüsselt erfolgen. Daten dürfen nicht Massenweise ausgelesen werden können. Böswillige Attacken werden unterbunden.

Das Backend muss vor eventuellem Hackerangriffen geschützt sein. Denial of Service Attacken müssen verhindert werden**.**

Es muss sichergestellt werden, dass der Client ausschließlich mit den definierten Endpunkten kommuniziert. Man in the middle Attacken dürfen nicht möglich sein.

5.3 Testkonzept
Im Kapitel Abnahmekriterien des Lastenhefts wird gefordert, dass die nicht- und funktionale Anforderungen durch Tests nachgewiesen werden.
 * Anwendungsfall || F01 Registrierung ||
 * Szenario || Registrierung eines neuen Benutzers ||
 * Voraussetzung || Der Benutzer ist noch nicht am System registriert. Eine Anmeldung mit der Emailadresse ist am System nicht möglich. ||
 * Eingangsparameter || Pflichtparameter werden in der ensprechenden Maske befüllt. ||
 * Durchzuführende Aktion || Anwender führt eine Registierung durch in dem er ein Profil in der entsprechenden Maske erstellt. ||
 * Erwartetes Ergebnis || Nach dem alle Pflichtfelder bedient wurden, wird eine neues Profil erstellt. Das Einloggen mit diesem Profil ist nun möglich. ||
 * Tatsächliches Ergebnis ||  ||


 * Anwendungsfall || F02 Anmeldung ||
 * Szenario || Clientseitige Anmeldung an der Applikation ||
 * Voraussetzung || Anwender ist am System Registriert. ||
 * Eingangsparameter || Email und Passwort das bei der Registrierung vergeben wurden ||
 * Durchzuführende Aktion || Anwender meldet sich am System durch Eingabe seiner Emailadresse und des Passwortes in der entsprechenden Maske an. ||
 * Erwartetes Ergebnis || Ist die Eingabe falsch oder das Benutzerprofil ist nicht vorhanden, erhält der Anwender eine entsprechende Meldung. Andernfalls gelangt der Benutzer auf den nächsten Screen nachdem die Daten durch den Server erfolgreiche verifiziert wurden. ||
 * Tatsächliches Ergebnis ||  ||
 * Anwendungsfall || F03 Pflege von Profildaten ||
 * Szenario || Clientseitige Pflege von Profildaten ||
 * Voraussetzung || Anwender ist am System Registriert und Profil ist vorhanden ||
 * Eingangsparameter || Ensprechend der Anfroderung F3 können Angaben geändert werden ||
 * Durchzuführende Aktion || Profildaten die in der Anforderung F03 markiert sind werden nacheinander geändert ||
 * Erwartetes Ergebnis || Die Ändrung der markierten Profildaten ensprechend der Anforderung F03 ist möglich. Andere Daten können nicht geändert werden. ||
 * Tatsächliches Ergebnis ||  ||
 * Anwendungsfall || F04 Mitfahrgelegenheit anbieten ||
 * Szenario || Clientseitige Möglichkeit Mitfahrgelegenheiten an den Server zu übermitteln ||
 * Voraussetzung || Anwender ist am System Registriert ||
 * Eingangsparameter || Ensprechend der Anfroderung F04 kann der Anwender eine Fahrt anbieten. ||
 * Durchzuführende Aktion || Der Anwender ruft den entsprechenden Screen auf und bedient die Eingabefelder. Das erstellte Angebot wird anschließend automatisch per Webservice an den Server übermittelt ||
 * Erwartetes Ergebnis || Der Anwender erhält eine positive Meldung, dass das erstellte Fahrangebot an den Server übermittelt wurde ||
 * Tatsächliches Ergebnis ||  ||
 * Anwendungsfall || F05 Mitfahrgelegenheit suchen ||
 * Szenario || Clientseitige Möglichkeit Mitfahrgelegenheiten zu suchen. ||
 * Voraussetzung || Anwender ist am System Registriert ||
 * Eingangsparameter || Ensprechend der Anfroderung F05 kann der Anwender am Client Fahrangbote suchen. ||
 * Durchzuführende Aktion || Der Anwender ruft den entsprechenden Screen auf und bedient die Eingabefelder. Der erstellte Gesuch wird an den Server per Webservice übermittelt. ||
 * Erwartetes Ergebnis || Der Anwender erhält eine Anwort vom Server. Falls Fahrten zu diesem Angebot vorhanden sind, werden diese dem Anwender dargestellt, andernfalls erhält er eine Meldung das zurzeit keine Fahrten vorhanden sind. ||
 * Tatsächliches Ergebnis ||  ||
 * Anwendungsfall || F06 Mitfahrgesuche anzeigen ||
 * Szenario || Clientseitige Möglichkeit potentielle Mitfahrgelegenheiten darzustellen ||
 * Voraussetzung || Anwender ist am System Registriert. Mitfahrgelegenheiten zum gesuchten Ziel und/oder Umkreis sind vorhaden ||
 * Eingangsparameter || eine detailierte Ansicht der dargestellten Fahrangebote ist durch das klicken auf ein ensprechendes Angebot möglich. ||
 * Durchzuführende Aktion || Der Anwender gibt im vorherigen Screen seine Suchparameter ein. Diese werden per Webservice an den Server übermittelt. Das Ergebnis wird an den Client wieder übertragen und tabellarisch dargestellt. Weitere Informationen ensprechend der Anfordernung können durch das klicken auf das jeweilige Angebot detalierter eingesehen werden. ||
 * Erwartetes Ergebnis || Der Anwender erhält eine Anwort vom Server. Falls Fahrten zu diesem Angebot vorhanden sind, werden diese dem Anwender dargestellt, andernfalls erhält er eine Meldung das zurzeit keine Fahrten vorhanden sind. ||
 * Tatsächliches Ergebnis ||  ||
 * Anwendungsfall || F07 Mitfahrgelegenheit/Mitfahrgesuch löschen ||
 * Szenario || Clientseitige Möglichkeit bereits eingetragene Gesuche und Angebote löschen ||
 * Voraussetzung || Anwender ist am System Registriert. Fahrangebot /Mitfahrgelegenheitsgesuch ist bereits im System eingestellt ||
 * Eingangsparameter || Anwender kann seine erstellten Fahrangebote oder Gesuche entfernen, falls diese noch nicht angetreten wurden. Hierfür wählt der Anwender das entsprechende Abgebot/Gesuch aus der dargestellten Liste aus. ||
 * Durchzuführende Aktion || Der Anwender wählt das Angebot/Gesuch im entsprechenden Screen aus und kann dieses durch das klicken auf löschen entfernen. Das entfernte Angebot/Gesuch werden per Webservice an den Server übertragen und dort entgültig gelöscht, sodass diese für weitere Anwender nicht mehr angezeigt werden. Angetretene Fahrten oder gerade stattfinde Fahrt kann nicht gelöscht werden. ||
 * Erwartetes Ergebnis || Der Anwender erhält eine Anwort vom Server. Falls Fahrten zu diesem Angebot vorhanden sind, werden diese dem Anwender dargestellt, andernfalls erhält er eine Meldung das zurzeit keine Fahrten vorhanden sind. ||
 * Tatsächliches Ergebnis ||  ||
 * Anwendungsfall || F07 Mitfahrgelegenheit/Mitfahrgesuch löschen ||
 * Szenario || Clientseitige Möglichkeit bereits eingetragene Gesuche und Angebote löschen ||
 * Voraussetzung || Anwender ist am System Registriert. Fahrangebot /Mitfahrgelegenheitsgesuch ist bereits im System eingestellt ||
 * Eingangsparameter || Anwender kann seine erstellten Fahrangebote oder Gesuche entfernen, falls diese noch nicht angetreten wurden. Hierfür wählt der Anwender das entsprechende Abgebot/Gesuch aus der dargestellten Liste aus. ||
 * Durchzuführende Aktion || Der Anwender wählt das Angebot/Gesuch im entsprechenden Screen aus und kann dieses durch das klicken auf löschen entfernen. Das entfernte Angebot/Gesuch werden per Webservice an den Server übertragen und dort entgültig gelöscht, sodass diese für weitere Anwender nicht mehr angezeigt werden. Angetretene Fahrten oder gerade stattfinde Fahrt kann nicht gelöscht werden. ||
 * Erwartetes Ergebnis || Der Anwender erhält eine Anwort vom Server. Falls Fahrten zu diesem Angebot vorhanden sind, werden diese dem Anwender dargestellt, andernfalls erhält er eine Meldung das zurzeit keine Fahrten vorhanden sind. ||
 * Tatsächliches Ergebnis ||  ||
 * Tatsächliches Ergebnis ||  ||


 * Anwendungsfall || F08 Benachrichtigungen bei passenden Reisezielen / Fahrtangeboten ||
 * Szenario || Clientseitige Anzeige von gefundenen Übereinstimmungen für Fahrtangebote / Fahrtgesuche ||
 * Voraussetzung || Anwender ist am System Registriert. Fahrangebot /Mitfahrgelegenheitsgesuch ist bereits im System eingestellt ||
 * Eingangsparameter || Mitfahrtsuche / Mitfahrtangebot sind eingetragen und am System veröffentlicht. ||
 * Durchzuführende Aktion || Der Anwender öffnet die Anwendung und meldet sich am System an. In der Vergangenheit hat er bereits Mitfahrtsuchen / Mitfahrtangebote veröffentlicht. ||
 * Erwartetes Ergebnis || Die Anwendung zeigt bei gefunder Übereinstimmung das Ergebnis an, sobald der User sich an der Anwendung angemeldet hat. Ist die Anwendung im Hintergrund aktiv und Anwender ist angemeldet, so erscheint in der Statusleiste des Smartphones ein Symbol für die gefundene Übereinstimmung. ||
 * Tatsächliches Ergebnis ||  ||
 * Anwendungsfall || F09 Bewertungen abgeben ||
 * Szenario || Clientseitige Möglichkeit durchgeführte Fahrten zu bewerten ||
 * Voraussetzung || Anwender ist am System Registriert. Eine Fahrt wurde durchgeführt. ||
 * Eingangsparameter || Der Anwender wählt im Bewerungsbildschirm die durchgeführte Fahrt aus. ||
 * Durchzuführende Aktion || Nachdem der Anwender die Fahrt ausgewählt hat, hat er die Möglichkeit weitere Eingaben durchzuführen und anschließend die Fahrt mit Sternen 1-5 zu bewerten. Anschließend bestätigt er seine Eingabe mit OK. ||
 * Erwartetes Ergebnis || Wenn der Anwender die Bewertung zum späteren Zeitpunkt erneut aufruft, werden die bereits Eingegebenen Informationen korrekt aufgerufen. ||
 * Tatsächliches Ergebnis ||  ||
 * Anwendungsfall || F10 Passwort zurücksetzen ||
 * Szenario || Clientseitige Möglichkeit festgelegtes Benutzerpasswort zurückzusetzen, ||
 * Voraussetzung || Anwender ist am System Registriert. ||
 * Eingangsparameter || Anwender wählt im entsprechenden Bildschirm das er sein Passwort zurücksetzen möchte. ||
 * Durchzuführende Aktion || Nachdem der Anwender ausgewählt hat das er sein aktuelles Passwort zurücksetzen möchte wird ihm durch das System eine generiertes Passwort an seine registrierte Email Adresse zugeschickt. ||
 * Erwartetes Ergebnis || Ein vom System generiertes Passwort wird dem Anwender zugeschickt. Mit diesem Passwort kann sich der Anwender am System clientseitig anmelden und daraufhin ein neues Passwort vergeben. ||
 * Tatsächliches Ergebnis ||  ||
 * Anwendungsfall || F11 Historie von Benutzern ||
 * Szenario || Clientseitige Möglichkeit bereits durchgeführte Fahrten und Angebote einzusehen. ||
 * Voraussetzung || Anwender ist am System Registriert. Fahrangebot wurden bereits wahrgenommen. ||
 * Eingangsparameter || Der Anwender wählt den entsprechende Bildschirm in der Applikation aus. ||
 * Durchzuführende Aktion || Nachdem der Anwender den Bildschirm ausgewählt hat, werden die darzustellenden Informationen vom Webserver an den Client gesendet. ||
 * Erwartetes Ergebnis || Es werden die vom Anwender durchgeführten Aktionen durchgeführt. Weiterhin ist der Anwender anschließend in der Lage durchgeführte Aktionen zu löschen. ||
 * Tatsächliches Ergebnis ||  ||
 * Anwendungsfall || F12 Administrative Eingriffe ||
 * Szenario || Serverseitige Durchführung administrativer Aktionen ||
 * Voraussetzung || Datenbankzugriff ist möglich. Administrationskennung ist vorhanden. ||
 * Eingangsparameter || Administrator meldet sich mit seiner Kennung an der Datenbank an. ||
 * Durchzuführende Aktion || Der Administrator kann alle administrative Aktionen durchführen. ||
 * Erwartetes Ergebnis || Die definierten administrativen Aktionen sind durchführbar. ||
 * Tatsächliches Ergebnis ||  ||
 * Szenario || Serverseitige Durchführung administrativer Aktionen ||
 * Voraussetzung || Datenbankzugriff ist möglich. Administrationskennung ist vorhanden. ||
 * Eingangsparameter || Administrator meldet sich mit seiner Kennung an der Datenbank an. ||
 * Durchzuführende Aktion || Der Administrator kann alle administrative Aktionen durchführen. ||
 * Erwartetes Ergebnis || Die definierten administrativen Aktionen sind durchführbar. ||
 * Tatsächliches Ergebnis ||  ||

=**6.Fachliche Architektur**=

**6.2 Spezifikations-Interaktionsdiagramme -> Oli "Sequenz"**
Die folgenden Sequenzdiagramme sind nicht aus den Spezifikationsklassendiagrammen generiert. Grundlage der Erstellung waren die Anwendungsfälle, Architekturüberlegungen und Prototypen der GUI. Es ergibt sich an dieser Stelle also momentan ein Bruch im modellgetriebenen Vorgehen, der sich in der nicht durchgängigen Bezeichnung der Instazen widerspiegelt Dieser Bruch ist dem nicht-sequentiellen, sondern parallelen und verteiltem Vorgehen innerhalb des Projekts geschuldet, soll an dieser Stelle nicht weiter hinderlich sein.


 * 6.2.1 Fahrt planen**


 * 6.2.2 Fahrt antreten und tracken**
 * 6.2.3 Mitfahrwunsch angeben**
 * 6.2.4 Mitfahrwunsch annehmen**
 * 6.2.5 Fahrt bewerten**

=**7. Priorisierte Anforderungsverfolgung zum Lastenheft**= Es wird eine stufenweise Realisierung der oben aufgelisteten Anforderungen durchgeführt. Dabei werden die gesamten Anforderungen in drei Releases umgesetzt.

7.1 erstes Release
Im erste Release werden folgende Anforderungen umgesetz: Die hier aufgelisteten Anforderungen werden im ersten Release clientseitig implementiert, dabei werden die Webservices am Client durch eine lokale Datenbank simuliert.
 * F01 Registrieung
 * F02 Anmeldung
 * F03 Pflege von Profildaten
 * F04 Mitfahrgelegenheit anbieten
 * F05 Mitfahrgelegenheit suchen
 * F06 Mitfahrgesuche anzeigen
 * F07 Mitfahrgelegenheit/Mitfahrgesuch löschen
 * F08 Benachrichtigungen bei passenden Reisezielen / Fahrtangeboten
 * F09 Bewertungen abgeben
 * F10 Passwort zurücksetzen
 * O01 Ameldung an der Anwendung über Facebook
 * O04 Darstellung der Fahranbieter/Fahrtsucher auf einer Karte

7.2 zweites Release
Im zweiten Release werden folgende Anforderungen umgesetzt: Die hier aufgelisteten Anforderungen werden im zweuten Release ebenfalls clientseitig implementiert, dabei werden die Webservices am Client durch eine lokale Datenbank simuliert.
 * F10 Passwort zurücksetzen
 * F11 Historie von Benutzern
 * O02 Auf der Facebookseite des jeweiligen Users werden Fahrtangebote und –gesuche gepostet.
 * O03 Die aktuelle Position des Nutzers wird auf der zugehörigen Facebookseite aktualisiert
 * O05 Anzeige von Fahrtsuchern die sich in der Nähe der Wegstrecke des Fahrers befinden.

7.3 drittes Release
Im dritten Release erfolgt die serverseitige Implementierung der im ersten Kapitel aufgelisteten Anforderungen. Dabei werden insbesondere die geforderten Webservices umgesetzt. In diesem Release wird die clientseitige Datenbank durch Webservices abgelöst, sodass die Client - Server Kommunikation hergestellt wird.

=8 Lieferumfang= Der Lieferumfang des Systems entspricht folgendem Umfang zu den angegebenen Terminen =9 Abnahmekriterien=
 * ===Lieferumfang=== || ===Liefertermin=== ||
 * Lastenheft || 02.05.2011 ||
 * Pflichtenheft || 02.05.2011 ||
 * Architekturentwurf || 02.05.2011 ||
 * Datenbankentwurf || 02.05.2011 ||
 * Designentwurf || 27.05.2011 ||
 * Umsetzung erstes Release (Prototyp) || 27.05.2011 ||
 * Umsetzung zweites Release || 01.09.2011 ||
 * Umsetzung drittes Release || 01.02.2011 ||
 * Testkonzept || 27.05.2011 ||
 * Benutzerdokumentation || 15.07.2011 ||

9.1 Voraussetzung für die Abnahme
Voraussetzung für die Abnahme sind die folgenden Bedingungen:
 * Die Lieferung aller im Abschnitt „Lieferumfang“ definierten Produkte ist zu den angegebenen Lieferterminen zu erfolgt.
 * Der Prototyp der Clientapplikation ist zum angegeben Liefertermin in einem stabil lauffähigen Umfang zu liefern. Die Grundlegenden Businessprozesse werden im Groben zu erkennen sein.
 * Alle nichtfunktionalen Anforderungen müssen erfüllt sein und ihre Erfüllung muss durch entsprechende Tests nachgewiesen werden.
 * Alle nichtfunktionalen Anforderungen müssen erfüllt sein. Ihre Erfüllung ist durch entsprechende Tests nachzuweisen.
 * Durch Definition und Durchführung entsprechender Testfälle ist die korrekte Umsetzung aller Anwendungsfälle nachzuwesien. Voraussetzung für die Abnahme ist, dass mindestens 95% der Anwendungsfälle korrekt umgesetzt sind.

9.2 Durchführung und Aufbau der Testfälle
Für jeden spezifizierten Anwendungsfall muss mindestens ein Testfall definiert werden. Besteht der Anwendungsfall aus mehr als einem Hauptszenario, sind ebenfalls für die Alternativszenarien Testfälle zu erstellen.Der grundsätzliche Aufbau eines Testfalls orientiert sich dabei an folgender Vorlage, welcher jedoch verfeinert werden kann:
 * Anwendungsfall ||  ||
 * Szenario ||  ||
 * Voraussetzung ||  ||
 * Eingangsparameter ||  ||
 * Durchzuführende Aktion ||  ||
 * Erwartetes Ergebnis ||  ||
 * Tatsächliches Ergebnis ||  ||