Lastenheft

= = =ACHTUNG! Lastenheft fürs Review nicht mehr änderbar! Inhalt am 27.04.2011 20:13 Uhr fürs Review kopiert!!= =**Dokumentenhistorie**=
 * Lastenheft**

=1 Einleitung= Im Rahmen des Verbundstudiums ist im Modul Fortgeschrittene Softwaretechnologie die Durchführung eines eigenständigen Softwareprojekts in Projektteams von 3-5 Mitgliedern vorgesehen. In diesem Zusammenhang hat sich diese Projektgruppe bestehend aus den Projektmitgliedern Andrea Höpfner, Marcel Menze, Oliver Webersberger, Sebastian Wehmeyer und Aleksandar Dimitrov das Ziel gesetzt eine Anwendung zu entwickeln, die es ermöglicht spontane Fahrgemeinschaften zu bilden. Zur Anforderungsaufnahme dient dieses Lastenheft, das die Rahmenbedingungen für die Entwicklung festgelegt. Diese werden in der Gesamtsystemspezifikation –dem Pflichtenheft- detailliert beschrieben. Kern des Lastenhefts sind die funktionalen und nichtfunktionalen Anforderungen an das System, sowie eine Skizze des Gesamtsystementwurfs.

=2 Ausgangssituation, Zielbestimmung und Stakeholder=

2.1 Ausgangssituation
Zurzeit werden Mitfahrgelegenheiten durch Anbieter wie die Mitfahrzentrale angeboten. Diese bieten die Möglichkeit vor Beginn einer Reise eine Fahrgemeinschaft zu bilden. Um eine Fahrgemeinschaft zu bilden ist vorab eine Anmeldung am jeweiligen System des Anbieters über die entsprechende Internetseite notwendig. Um den Wettlauf um Mobile Endgeräte wie Smartphones nicht zu verlieren, werden Applikationen von den einzelnen Anbietern der Mitfahrgelegenheiten angeboten, die die Betriebssysteme iOS und Android ebenfalls unterstützen. Der Nachteil der bestehenden Systeme besteht in der fehlenden Anbindung an Soziale Netzwerke, die immer stärker an Beliebtheit und neue Mitglieder gewinnen. Darüber hinaus sind spontane Reisen nicht möglich, da Reisen stets in das System eingegeben werden müssen, um von potentiellen Mitfahrern dort gebucht werden zu können. Die bestehenden Systeme der Mitfahrgelegenheitanbieter stellen keine Möglichkeiten zur Verfügung, um spontane Reisen anzutreten. Diese Lücke soll die zu entwickelnde Anwendung schließen. Mitglieder von Sozialen Netzwerken wie Facebook können die Anwendung ebenso nutzen, wie Personen, die ein Profil am neuen System erstellen. Weiterhin können Anwender spontane Fahrten in das System eingeben, die durch speziell hierfür zu entwickelnde Maßnahmen an die weiteren Mitglieder weitergeleitet werden, damit diese ebenso spontan an Fahrten als Mitfahrer teilnehmen können. Der Vorteil für Fahrer und Mitfahrer ist, dass die Kosten der Reise aufgeteilt werden können. Für Personen ohne eigenes Fahrzeug ist dies als Alternative zu öffentlichen Verkehrsmitteln zu sehen.

2.2 Zielbestimmung
Die Anwendung soll Fahrer und potentielle Mitfahrer zueinander bringen um eine Fahrgemeinschaft zu bilden, wenn ein ähnlicher Fahrtwunsch vorliegt. Aus Sicht des Fahrtanbieters soll die zu entwickelnde Anwendung Mitfahrer mit ähnlichem Start und Ziel anzeigen. Potentielle Mitfahrer, deren Startpunkt in der Nähe der zurückzulegenden Strecke liegen, sollen dem Fahrtanbieter ebenfalls präsentiert werden. Auch nach Fahrtantritt sollen dem Fahrtanbieter potentielle Mitfahrer mit ähnlichem Ziel übermittelt werden, deren Startort in der Nähe der aktuellen Position des Fahrtanbieters liegt. Dem Fahrer werden die freigegebenen Profilinformationen und bisherigen Bewertungen des potentiellen Mitfahrers angezeigt. Entscheidet der Fahrer, dass er einen Mitfahrer mitnehmen möchte, so muss die Anwendung dem Fahrer die Kontaktinformationen des Fahrtsuchenden anzeigen. Die Kontaktaufnahme und die Verhandlung über das Kostenteilen muss von der Anwendung nicht unterstützt werden. Aus Sicht der Mitfahrer soll das Reisegesuch im Voraus oder spontan angegeben werden können. Die Anwendung soll dem Mitfahrer alle zu seinem Mitfahrwunsch passenden Fahrtangebote anzeigen. Der Mitfahrer wählt unter den ermittelten Fahrtangeboten aus. Auch dem Mitfahrer sollen die freigegebenen Profilinformationen und die bisherigen Bewertungen des Fahrers angezeigt werden können. Damit eine Kontaktaufnahme möglich ist, muss die Anwendung dem Mitfahrer die Kontaktinformationen des Fahrers anzeigen. Die Anwendung soll es den Teilnehmern ermöglichen Informationen zur Person und in einem eigenen Profil zu pflegen. Fahrer sollen Informationen zu Ihrem Fahrzeug in der Anwendung hinterlegen können. Kommt eine Fahrgemeinschaft zu Stande, sollen sich die Fahrer und Mitfahrer im Anschluss daran gegenseitig Bewerten können. Die Anwendung soll auf aktuellen mobilen Endgeräten (Smartphones/TabletPCs) lauffähig sein.

2.3 Stakeholder der Anwendung
Zu den Benutzergruppen der Anwendung zählen alle Personen: =3 Geschäftsprozesse= Im Folgenden ist ein Geschäftsprozess modelliert, der die grundsätzlichen Funktionen der zu implementierenden Anwendung besser veranschaulichen soll.
 * sozialer Netzwerke, die ohne zusätzliche Profilerstellung Dienste anderer Anbieter nutzen möchten
 * mit Reisewunsch ohne eigenes Fahrzeug (als alternative zu öffentlichen Verkehrsmitteln)
 * mit Fahrzeug, die eine Strecke einmalig oder wiederholt zurücklegen und Sitzplätze im Fahrzeug frei haben
 * die Ressourcen finanzieller und oder ökologischer Natur sparsam einsetzen wollen
 * ungern alleine Reisen
 * spontan Reisen oder Reisen wollen



Zunächst erfolgt der Aufruf der Applikation über ein Smartphone. Anschließend muss sich der Benutzer an der Anwendung anmelden. Daraufhin befindet er sich im Hauptmenu der Anwendung. Hier wird unterschieden, ob der Anwender eine Fahrt für Mitfahrer anbietet, ob der Anwender eine Mitfahrgelegenheit sucht oder ob er sich Mitfahrgesuche anzeigen lassen will. Sofern der Anwender eine Mitfahrgelegenheit anbieten will, muss er zunächst seine Reisedaten veröffentlichen. Anschließend wird geprüft, ob es passende Mitfahrer mit dem gleichen Reiseziel gibt. Ist dies der Fall, werden dem Fahrer weitere Informationen über den potentiellen Mitfahrer angezeigt und der Fahrer kann mit dem Mitfahrer weitere Details und den Fahrpreis aushandeln. Eine weitere Option ist die Anzeige von vorhandenen Fahrtgesuchen in einem bestimmten Umkreis des Fahrers. Nachdem er den Umkreis entsprechend eingegrenzt hat, werden ebenfalls wieder Details zu den potentiellen Mitfahrern angezeigt und der Fahrer kann mit ihnen Kontakt aufnehmen. Sofern ein potentieller Mitfahrer nach einem Fahrtanbieter sucht, ermittelt das System entsprechende Fahrer. Anschließend kann der Mitfahrer dann Details über einzelne Fahrer aufrufen und mit ihnen Kontakt aufnehmen. =4 Überblick über zu realisierende Anwendungsfälle=

=5 Funktionale Anforderungen= Im Folgenden werden die Anforderungen beschrieben, die im Rahmen dieses Projektes umgesetzt werden sollen. Hierbei findet eine Unterscheidung zwischen Pflichtanforderungen, optionalen Anforderungen und nicht funktionalen Anforderungen statt. Sämtliche Pflichtanforderungen müssen bis zum Projektabschluss umgesetzt werden. Die optionalen Anforderungen stellen einen Mehrwert für das Produkt dar, der über die Kernfunktionalität der zu realisierenden Anwendung hinausgeht. Aus diesem Grund müssen diese nur umgesetzt werden, sofern im Projektverlauf noch Aufwand und Budget für die Realisierung vorhanden sind. Grundsätzlich muss im Entwicklungsprozess aber stets berücksichtigt werden, dass die optionalen Anforderungen in einem nachfolgenden Release möglichst problemlos umzusetzen sind. Die nicht funktionalen Anforderungen beziehen sich in erster Linie auf Querschnittsthemen, die die gesamte Applikation betreffen und Qualitätseigenschaften der Anwendung definieren.

5.1 Pflichtanforderungen
In diesem Kapitel sind die Pflichtanforderungen definiert, die in jedem Fall umzusetzen sind. Diese Anforderungen werden zunächst detailliert einzeln beschrieben. Abschließend werden alle Pflichtanforderungen noch einmal tabellarisch zusammengefasst.

5.1.1 Registrierung
Eine zentrale Funktionalität und Vorbedingung für die Nutzung der Anwendung ist die Registrierung am System. Um die Hürde für die Registrierung möglicht gering zu halten, sollen nur essentielle Daten erfasst werden. In der folgenden Tabelle sind die zu erfassenden Daten im Rahmen der Benutzerregistrierung abgebildet: Muss mindestens aus 5 Zeichen bestehen Muss mindestens ein Sonderzeichen beinhalten || x || Ja || Als Benutzername kann der Anwender eine beliebige Zeichenfolge wählen. Der Benutzername muss einen Anwender eindeutig im System identifizieren.
 * **Feld** || **Beschreibung** || **Pflichtangabe** || **Änderbar** ||
 * Nickname/Username || Frei wählbarer Benutzername des Anwenders || x || Nein ||
 * Passwort || Frei wählbares Passwort des Anwenders
 * Vorname || Vorname des Anwenders ||  || Ja ||
 * Name || Nachname des Anwenders ||  || Ja ||
 * Emailadresse || Email-Adresse des Anwenders || x || Ja ||
 * Mobilfunknummer || Mobilfunknummer des Anwenders || x || Ja ||

5.1.2 Anmeldung
Sofern ein Nutzer bereits am System registriert ist, muss er sich mit seinen Zugangsdaten (Benutzername und Passwort) jederzeit an der Anwendung anmelden können. Die Anmeldung muss direkt über die Startseite der Applikation möglich sein. Sofern die Anmeldung aufgrund fehlerhafter Angaben nicht funktioniert hat, muss der Anwender hierüber entsprechend informiert werden. Für den Fall, dass der Anwender sein Passwort vergessen hat, muss die Möglichkeit bestehen, dass der Anwender sich ein neues Passwort an eine registrierte E-Mail Adresse zuschicken lässt. Zu diesem Zweck muss auf der Anmeldemaske ein Link integriert werden (Passwort vergessen?). Nach der Eingabe einer E-Mail Adresse wird dem Benutzer ein neues Passwort zugesandt, mit dem er sich am System anmelden kann.

5.1.3. Pflege von Profildaten
Grundsätzlich müssen alle bei der Registrierung angegebenen Daten (mit Ausnahmen des Benutzernamens) über das Profil geändert werden können. Demnach müssen folgende Eigenschaften editierbar sein: Muss mindestens aus 5 Zeichen bestehen Muss mindestens ein Sonderzeichen beinhalten || x || Für die Pflege der oben aufgeführten Felder muss es einen entsprechenden Bereich in der Applikation geben. Um die Übersichtlichkeit zu gewährleisten ist hier auch gerne eine sinnvolle Gruppierung der Eigenschaften zulässig (bspw. Adresse: PLZ, Ort, Str., Hausnr).
 * **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
 * Mobilfunknummer || 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 ||  ||

5.1.4 Mitfahrgelegenheiten anbieten
Anwender, die eine Fahrt planen und hierfür eine Mitfahrgelegenheit anbieten wollen, müssen in der Anwendung Details zu ihrer geplanten Route hinterlegen, damit potentielle Mitfahrer ausgemacht werden können. Zu diesem Zweck muss die Oberfläche der Anwendung dem Nutzer die Eingabe der entsprechenden Routendetails ermöglichen. Folgende Eigenschaften müssen dabei erfasst werden: Alternativ muss dieser auch über GPS ermittelt werden können || x || Alternativ muss der Anwender hier auch Sofort auswählen können || x || Nachdem der Anwender alle erforderlichen Daten angegeben hat, kann er seine Fahrt durch die Betätigung eines Buttons veröffentlichen. Ab diesem Zeitpunkt kann diese Fahrt bei der Suche nach Mitfahrgelegenheit mit verwendet werden.
 * **Feld** || **Beschreibung** || **Pflichtangabe** ||
 * Start || Genaue Adresse des Fahrers
 * Ziel || Genaue Adresse des Reiseziels (Mind.: PLZ, Ort, Str.) || x ||
 * Reisebeginn || Datum des Reisestarts
 * Freie Sitzplätze || Anzahl möglicher Mitfahrer || x ||

5.1.5 Mitfahrgelegenheit suchen
Das Suchen einer Mitfahrgelegenheit ist die zweite Kernfunktionalität der Anwendung. Folgende Eigenschaften sind bei der Suche nach einer Mitfahrgelegenheit zu berücksichtigen: Alternativ muss dieser auch über GPS ermittelt werden können || x || Anhand der oben genannten Kriterien muss die Anwendung die zu den Suchinformationen passenden potentiellen Fahrtanbieter in einer Tabelle anzeigen. Optional ist eine Kartendarstellung zu realisieren, welche die potentiellen Fahrer in ihrer aktuellen Position als Punkte auf der Karte darstellt. Durch Auswählen aus der Tabelle oder der Karte werden die Informationen aus dem Fahrtgesuch und die freigegebenen Profilinformationen des potentiellen Fahrers dem Mitfahrer angezeigt. Zu diesem Zeitpunkt liegt die Auswahl beim Mitfahrer, der anschließend eigenständig (mit Hilfe der Profilinformationen) mit dem Fahrtanbieter Kontakt aufnehmen muss. Sollten anhand der Routeninformationen keine geeigneten Mitfahrgelegenheiten gefunden werden, muss die Suchanfrage gespeichert werden. Für Fahrer wird daraufhin sichtbar, dass es auf seiner Strecke Mitfahrgesuche gibt, die er ebenfalls eigenständig kontaktieren kann. Die nächste Anforderung konkretisiert dieses Szenario.
 * **Feld** || **Beschreibung** || **Pflichtangabe** ||
 * Start || Genaue Adresse des Mitfahrers
 * Ziel || Genaue Adresse des Reiseziels (Mind.: PLZ, Ort, Str.) || x ||
 * Reisebeginn || Datum des Reisestarts || x ||

5.1.6 Mitfahrgelegenheit anzeigen
Ein Fahrer, der eine neue Fahrt geplant hat, muss die Möglichkeit haben, sich potentielle Mitfahrer in einem ausgewählten Umkreis von 3, 5, 10 und 20 km anzeigen zu lassen. Das Fahrtziel muss hierbei nicht berücksichtigt werden. Diese Information muss der Fahrer selbständig über die Anzeige des Fahrtgesuches erhalten. Diese Anzeige muss wieder die folgenden Eigenschaften beinhalten: Sofern sich der Mitfahrer dazu entscheidet einen potentiellen Mitfahrer mitzunehmen, da die Reiseziele bspw. identisch sind, muss der Fahrer über das Profil des Mitfahrers die Kontaktdaten ermitteln und entsprechend den Kontakt herstellen.
 * **Feld** || **Beschreibung** || **Pflichtangabe** ||
 * Start || Angegebene Startadresse/Position des Fahrers || x ||
 * Ziel || Genaue Adresse des Reiseziels (Mind.: PLZ, Ort, Str.) || x ||
 * Reisebeginn || Datum des Reisestarts || x ||

5.1.7 Mitfahrgelegenheit/Mitfahrgesuch löschen
Entscheidet sich ein Fahrtanbieter, dass er seine Fahrt doch nicht mehr anbieten möchte, so muss er seine Fahrten, bei denen noch kein weiterer Mitfahrer zugeordnet ist löschen können. Die gelöschten Fahrten werden dann nicht mehr bei der Suche nach Fahrtangeboten angezeigt. Auch die Benachrichtigung, wenn ein entsprechendes Mitfahrgesuch eingegeben wird, darf für die gelöschte Fahrt nicht mehr erfolgen. Auch Mitfahrer müssen ihre eigenen Gesuche löschen können. Wird eine Fahrt angeboten, die auf das gelöschte Gesuch passt, darf an den Suchenden keine Benachrichtigung erfolgen.

5.1.8 Benachrichtigung bei passenden Reisezielen/Fahrtangeboten
Grundsätzlich müssen Fahrer und potentielle Mitfahrer benachrichtigt werden, sobald ein passendes Reisependant für die gewünschte Reise gefunden wurde. Hat ein Fahrer bspw. seine Fahrt angetreten und ein potentieller Mitfahrer meldet eine Stunde später das gleiche Reiseziel an (mit gleichen Reisezielen ist hier die Stadt gemeint), muss der Fahrer hierüber informiert werden, sofern der Reisestart in einem Umkreis von 5 KM zu seiner Route liegt. Die Information muss über die Einblendung eines Hinweises in der Applikation erfolgen. Umgekehrt muss diese Funktionalität auch realisiert werden, sobald ein potentieller Fahrer das gleiche Ziel wie ein vorhandenes Fahrtgesuche hat. In diesem Fall muss der potentielle Mitfahrer eine Information darüber erhalten, dass ein Fahrer mittlerweile eine Fahrt zum gleichen Reiseziel plant. Wünschenswert wäre in diesem Zusammenhang auch die Darstellung der Information auf einer Karte, sofern die Anzeige darüber realisiert wird.

5.1.9 Bewertungen abgeben
Die Anwendung soll eine Bewertungsfunktionalität beinhalten. Nach Beendigung sollen die Mitfahrer einer Fahrgemeinschaft den Fahrer bewerten können. Der Fahrer soll seine Mitfahrer bewerten können. Das Bewertungssystem soll durch Vergabe von 1 bis 5 Punkten und einen Freitext realisiert werden. Die Anzahl der vergebenen Punkte könnte durch Sterne dargestellt werden.

5.1.10 Passwort zurücksetzen
Hat ein Nutzer Passwort oder Usernamen vergessen, muss die Anwendung eine Möglichkeit beinhalten, dass der Nutzer wieder Zugang zu seinem Account erhält. Es muss sichergestellt werden, dass nur der Ursprüngliche Nutzer seinen Account wieder freischalten lassen kann. Zu diesem Zweck muss der Nutzer seine E-Mail Adresse angeben. An diese Adresse wird dann sein Benutzername und ein neu generiertes Passwort gesendet.

5.1.11 Historie von Benutzern
Die Anwendung muss es ermöglichen, eine Historie der Fahrtangebote und Mitfahrgesuche des angemeldeten Benutzers anzuzeigen. Weiterhin soll die Anzeige an teilgenommenen Fahrgemeinschaften als Historie möglich sein.

5.1.12 Administrative Eingriffe
Die Anwendung muss es ermöglichen einem Administrator Zugriff auf alle Benutzerdaten zu erlauben. Das Passwort muss dabei aus Sicherheitsgründen verschlüsselt hinterlegt sein. Folgende Aktivitäten muss ein Administrator durchführen können:
 * Deaktivierung eines Accounts
 * Aktivierung eines Accounts
 * Passwort neu generieren
 * Bewertungen löschen
 * Fahrten löschen

Der Zugriff muss nicht über die mobile Applikation selbst realisiert werden. Es ist hier ausreichend, wenn der Administrator die o. g. Aktivitäten auf dem System direkt ausführt.

5.2 Optionale Anforderungen

 * **ID** || **Beschreibung** ||
 * O01 || Ameldung an der Anwendung über Facebook ||
 * 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 ||
 * O04 || Darstellung der Fahranbieter/Fahrtsucher auf einer Karte ||
 * O05 || Anzeige von Fahrtsuchern die sich in der Nähe der Wegstrecke des Fahrers befinden. ||

5.3 Übersicht über funktionale Anforderungen
=6 Schnittstellen=
 * **ID** || **Beschreibung** ||
 * F01 || Registrierung ||
 * 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 ||
 * F11 || Historie von Benutzern ||
 * F12 || Administrative Eingriffe ||
 * O01 || Ameldung an der Anwendung über Facebook ||
 * 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 ||
 * O04 || Darstellung der Fahranbieter/Fahrtsucher auf einer Karte ||
 * O05 || Anzeige von Fahrtsuchern die sich in der Nähe der Wegstrecke des Fahrers befinden. ||

6.1 System-Schnittstellen
Im ersten Schritt ist es ausreichend, wenn die Anwendung auf Smartphones mit Android-Systemen nutzbar ist. Langfristig sollen jedoch auch andere Betriebssysteme unterstützt werden. Zudem ist auch eine Web-basierte Variante geplant, über die jeder Nutzer mit einem aktuellen Browser zugreifen können soll. Dies ist jedoch nicht Bestandteil dieses Leistungsumfangs. Um die zukünftige Realisierung jedoch zu ermöglichen, muss die Datenhaltung in einer eigenständigen Backend-Applikation realisiert werden. Der Zugriff auf diese Daten kann dann beispielsweise über Webservices realisiert werden. Diese könnten später dann auch von anderen Systemen genutzt werden. Des Weiteren müssen Schnittstellen von Android zu Kartenanbietern realsiert werden, um Fahrtanbieter und potentielle Mitfahrer auf einer Karte (bspw. Google Maps) anzeigen zu können. Ein weiterer Punkt ist noch die Integration der sozialen Netzwerke. Hier muss zunächst die Social Community Facebook mit integriert werden.

6.2 Benutzungsschnittstelle
Da die Zielplattorm der Anwendung aktuelle mobile Endgeräten umfassen soll, muss die Oberfläche problemlos über ein bei Smartphones übliches Touchscreen bedienbar sein. =7 Nicht-Funktionale Anforderungen=
 * **ID** || **Beschreibung** ||
 * NF01 || Die Anwendungsdaten müssen auf dem Server vor unrechtmäßigen Zugriffen geschützt abgelegt werden. ||
 * NF02 || Die Kommunikation zwischen mobilen Endgerät und Serveranwendung müssen verschlüsselt erfolgen ||
 * NF03 || Die Kommunikation des mobilen Endgerätes mit dem Kartenanbieter kann unverschlüsselt erfolgen ||

7.1.1 Performance
Anfragen an das Backendsystem sollen durch dieses in maximal fünf Sekunden, ohne Netzlaufzeiten zwischen dem anfragendem Gerät und der Serveranwendung, beantwortet werden. Falls die Internetverfügbarkeit Clientseitig nicht vorhanden ist, soll der User durch eine aussagekräftige Meldung darauf hingewiesen werden.
 * Anfrage an das Backendsystem**

Der Serverresponse mit den entsprechenden Informationen ist in maximal zwei Sekunden nach dem vollständigen übertragen des Response an den Client am Client zu verarbeiten und darzustellen.
 * Verarbeiten der Serverresponse**

Jede Userinteraktion in der Clientanwendung, innerhalb der erlaubten Businessprozesse, ist von der Anwendung in maximal einer Sekunde zu verarbeiten und darzustellen.
 * Userinteraktion **

7.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.
 * Skalierbarkeit des Backends **

Es sind geeignete Monitoringmöglichkeiten zu schaffen, so dass frühzeitig absehbar ist, welche Komponente in kürze einen Engpass darstellen könnte, damit diese Erweitert werden kann, damit die festgelegte maximale Antwortzeit niemals überschritten wird. Für das Monitoring sind geeignete Schwellwerte zu definieren um frühzeitig Maßnahmen zur Performanceanpassung einleiten zu können.
 * Monitoring Backend **

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.
 * Skalierbarkeit der Clientanwendung **

7.1.3 Verfügbarkeit
Die Entwicklung muss stets vor dem Hintergrund stattfinden, dass die Anwendung zu einem späteren Zeitpunkt für die Endkunden hochverfügbar ist. Demnach muss die Anwendung auch in einem Fehlerfall weiter zur Verfügung stehen. Es ist in diesem Zusammenhang jedoch ausreichend die niedrigste Verfügbarkeitsklasse 2 mit einer Ausfallzeit von 87,7 Stunden/Jahr zu unterstützen. Im Desasterfall darf die Mean time to Recover 12 Stunden nicht überschreiten. Die Mean time between failures darf 50 Tage nicht unterschreiten.
 * Backendverfügbarkeit **

Die Backuplösung muss gewährleisten, dass alle Applikationsdaten bis zu dem Zeitpunkt des Fehlerfalls wieder hergestellt werden können.
 * Backup **

7.2.1 Datensicherheit
Sämtliche Daten der Anwendung müssen vor unbefugtem Zugriff geschützt sein. Die Übertragung von Daten zwischen dem Client und dem Backend muss verschlüsselt erfolgen. Daten dürfen nicht Massenweise ausgelesen werden können.

7.2.2 Sicherheit des Backends
Das Backend muss vor eventuellen Hackerangriffen geschützt sein. Denial of Service Attacken müssen verhindert werden.

7.2.3 Sicherheit des Clients
Es muss sichergestellt werden, dass der Client ausschließlich mit den definierten Endpunkten kommuniziert. Man in the middle Attacken müssen ausgeschlossen werden.

7.3 Code-Qualität
Abhängigkeiten zwischen Paketen müssen zyklenfrei sein Die relative Average Component Dependency (rACD) darf höchstens 6% betragen Die zyklomatische Komplexität von Java Methoden darf den Wert 15 nicht überschreiten Eine Java Klasse darf maximal 1.000 Zeilen lang sein Eine Java Methode darf maximal 100 Zeilen lang sein Trennung von Oberfläche und Businesslogik Jede produktionskritische Funktion muss mit Testcode überprüft werden Über „Code Coverage Tests“ soll der Grad der Testabdeckung jederzeit bereitstehen

7.4 Benutzbarkeit
Die Anwendung muss auf Endgeräten mit kleinen Touchscreens bedienbar sein. Weiterhin muss Oberfläche selbst erklärend sein, damit die Nutzer die Anwendung schnell nutzen können und die Akzeptanz hoch ist. Im nachfolgenden Kapitel werden Skizzen und Beschreibungen einer möglichen Benutzeroberfläche vorgestellt. Diese dienen als Referenzmodell für die Umsetzung der Clientanwendung. =8 Skizze der Architektur und der Benutzeroberfläche=

8.1 Skizze der Infrastruktur
Im Folgenden werden erste Skizzen der Infrastruktur dargestellt, die als Richtlinie für spätere Technologieentscheidungen dienen soll.

8.2 Skizze der Benutzungsoberfläche
Nachdem man die Applikation geladen und sich über Emailadresse und Passwort authentifiziert hat, stehen drei Reiter zur Verfügung. Der Reiter Profil, der Reiter Suche und der Reiter Route. Auf dem ersten Reiter Profil ist es möglich, seine Daten zu sehen und zu bearbeiten. In der obigen Skizze findet man einen Auszug der vorhandenen Profildaten. Hat man etwas geändert, kann man seine Änderungen mit dem SAVE-Button speichern oder das Ändern über den CANCEL-Button abbrechen.
 * Profil**


 * Suche**

Auf dem zweiten Reiter 'Suche' ist es möglich über Hinreisedatum, Rückreisedatum und Ziel bereits vorhandene, anstehende Fahrten zu suchen. Ob die Fahrten passen, wird geprüft, indem ein Abgleich mit dem im Profil eingegebenen Startort gemacht wird. Alle Fahrten, die zwischen Startort und Ziel sowie im Zeitraum liegen, werden in einer Liste angezeigt. In der oberen Ansicht ist ein mögliches Suchergebnis dargestellt. Das Ergebnis einer Suche wird in Listform dargestellt. Zu jedem Sucheergebnis werden mindestens Reiseantrittsdatum und -uhrzeit, Start- und Zielort sowie die Anzahl freier Plätze angezeigt. Über einen Klick auf eine Zeile der Ergebnisliste verzweigt man in die Fahrt und erhält weiter Informationen.
 * Suchergebnis**

In der oberen Skizze ist der Reiter 'Route' abgebildet. Hier wird später grafisch abgebildet, ob sich potenzielle Fahrer oder Mitfahrer auf einer vorher definierten Route (im Beispiel von Osnabrück (A) nach Dortmund (B)) befinden. Ähnlich wie im Beispiel Start- und Ziel können weitere Markierungen mit dem Namen der Personen auf der Karte gezeigt werden. Durch einen Klick auf eine Markierung kann dann z.B. Kontakt zur Person aufgenommen werden. =9 Lieferumfang= Zum Lieferumfang der Gesamtanwendung gehört ein lauffähiger Client für die Anwendung auf dem Betriebssystem Android. Ebenso muss eine lauffähige Backendsoftware, die mit dem Client kommuniziert geliefert werden. Für den Client und die Backendsoftware muss ein Handbuch geliefert werden, welches den Umgang mit dem System erklärt. Des Weiteren ist ein Backup und Betriebskonzept für die Anwendung zu liefern. Ein Prototyp des Clients muss geliefert um die Machbarkeit des Konzeptes zu zeigen. =10 Abnahmekriterien=
 * Route mit Karte**

10.1 Voraussetzung für die Abnahme
Voraussetzung für die Abnahme sind die folgenden Bedingungen: 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.

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

= =