Online-Bergtourenplanung - sws.bfh.ch · SRS Anforderungsspezifikation (Software Requirements...

Lastenheft

Online-Bergtourenplanung

CAS Software Engineering 2013, Gruppe 2

Autoren Imsand Iwan; Aepli Norbert; Oesch Christof; Matter Aiko

Version 1.0

Status fertig gestellt (in Bearbeitung/fertig gestellt/geprüft/freigegeben)

Anzahl Seiten 63

Auftraggeber MegaSport

Lastenheft Online-Bergtourenplanung

Status: fertig gestellt v1.0 Seite 2 von 63

Dokumenten-Historie

Version Datum Bearbeiter Änderung, Bemerkung

V0.1 04.06.2013 NA Neues Dokument mit SRS-Struktur

V0.2 07.06.2013 AM Bearbeitung Kapitel 1

V0.3 12.06.2013 CO Bearbeitung von Kapitel 2

v0.4 20.06.2013 II Bearbeitung Kapitel 3, Use Cases

V0.5 21.06.2013 II Überführung in Word, Formatvorlagen angepasst.

V0.6 22.06.2013 NA Vorwort, Management Summary, Funktionale Anforderungen

V0.7 22.06.2013 II Änderungen aus V0.6 NA überprüft und akzeptiert

V0.8 22.06.2013 II Bearbeitung Kapitel 3.3.1, Beschreibungen der Use Cases hinzugefügt

V0.9 26.06.2013 II Aufnahme UC- und AG-/F- Nummern ins Inhaltsverzeichnis und Reduzierung von Redundanzen, Überarbeitung Funktionale / Nichtfunktionale Anforderungen

V0.10 27.06.2013 NA Bearbeitung Kapitel 4.5 Kosten

V0.11 28.06.2013 II Erstes Review, Diverse Anpassungen, Abbildungen beschriftet und Abbildungsverzeichnis eingefügt

V0.12 29.06.2013 NA Requirement-Formulierungen den Prioritäten angepasst, Update Terminplanung, diverse Schlussbearbeitungen

V0.13 01.07.2013 AM Review, Kommentare, einige Schreibfehler korrigiert, Kapitel Attribute gestrichen

V1.0 02.07.2013 alle Letzte Änderungen, Version vom Team an Teamsitzung abgenommen



Inhalt

Inhalt ....................................................................................................................................................... 3

Abbildungsverzeichnis ............................................................................................................................. 6

Vorwort ................................................................................................................................................... 7

Management Summary ........................................................................................................................... 7

1 Einleitung ......................................................................................................................................... 8

1.1 Konventionen .......................................................................................................................... 8

1.2 Zweck ....................................................................................................................................... 8

1.3 Ausgangslage ........................................................................................................................... 8

1.4 Ziele ......................................................................................................................................... 8

1.5 Produktumfang ........................................................................................................................ 8

1.6 Stakeholder ............................................................................................................................. 9

1.7 Definitionen, Akronyme, Abkürzungen, Glossar ................................................................... 10

1.7.1 Fachbegriffe ................................................................................................................... 10

1.7.2 Informatik-Begriffe ........................................................................................................ 10

1.7.3 Prozess-Wörter .............................................................................................................. 10

1.7.4 Logische Operatoren ..................................................................................................... 11

1.7.5 Raster für UseCases ....................................................................................................... 11

1.7.5.1 Legende ..................................................................................................................... 12

1.7.6 Raster für Anforderungen ............................................................................................. 12

1.7.6.1 Legende ..................................................................................................................... 13

1.8 Masseinheiten ....................................................................................................................... 13

1.9 Referenzen ............................................................................................................................ 13

1.10 Übersicht über die folgenden Kapitel der SRS ...................................................................... 13

2 Gesamt-Übersicht .......................................................................................................................... 13

2.1 Produkt-Umfeld ..................................................................................................................... 13

2.1.1 System-Schnittstelle ...................................................................................................... 14

2.1.2 Benutzer-Schnittstelle ................................................................................................... 14

2.1.3 Hardware-Schnittstelle .................................................................................................. 14

2.1.4 Software-Schnittstelle ................................................................................................... 14

2.1.4.1 Bezahlung mit Kreditkarte ......................................................................................... 14

2.1.4.2 Google Maps .............................................................................................................. 14

2.1.5 Kommunikations-Schnittstelle ...................................................................................... 15

2.1.6 Betriebssystem-Plattform ............................................................................................. 15

2.1.7 Speicher-Beschränkungen ............................................................................................. 15

2.1.8 Operationen .................................................................................................................. 15

2.1.9 Standort-spezifische Anforderungen ............................................................................ 15



2.2 Produkt-Funktionalität .......................................................................................................... 15

2.3 Abgrenzung ........................................................................................................................... 16

2.4 Mengengerüst, Periodizitäten ............................................................................................... 16

2.5 Benutzer-Charakteristika ....................................................................................................... 17

2.6 Randbedingungen ................................................................................................................. 17

2.7 Annahmen und Abhängigkeiten ............................................................................................ 17

2.8 Realisierungs-Verschiebung .................................................................................................. 18

3 Spezifische Anforderungen ........................................................................................................... 18

3.1 Externe Schnittstellen ........................................................................................................... 18

3.1.1 User Interfaces .............................................................................................................. 18

3.1.2 Hardware Interfaces ...................................................................................................... 18

3.1.3 Software Interfaces ....................................................................................................... 18

3.1.4 Kommunikations-Interfaces .......................................................................................... 18

3.2 Generelle Anforderungen ..................................................................................................... 19

3.2.1 Gesamtüberblick in Form einer Mind Map ................................................................... 19

3.2.2 Fachliche Entitäten ........................................................................................................ 20

3.2.3 Fehlerbehandlungen ..................................................................................................... 21

3.2.4 Plausibilitäten ................................................................................................................ 21

3.2.5 Layout und Formate der Masken .................................................................................. 21

3.3 Funktionale Anforderungen .................................................................................................. 21

3.3.1 Use Cases ....................................................................................................................... 21

3.3.1.1 Business ..................................................................................................................... 21

UC-0001 Tour buchen............................................................................................................ 22

UC-0002 Route auswählen .................................................................................................... 24

UC-0003 Berg auswählen ...................................................................................................... 24

UC-0004 Tour anbieten ......................................................................................................... 25

UC-0005 Dienstleistung auswählen ....................................................................................... 27

UC-0006 Dienstleistung anbieten .......................................................................................... 27

UC-0007 Hütte auswählen .................................................................................................... 29

UC-0008 Betten anbieten ...................................................................................................... 29

3.3.1.2 Verwaltung ................................................................................................................ 31

UC-0020 Buchungen verwalten ............................................................................................. 31

UC-0021 Touren verwalten ................................................................................................... 32

UC-0022 Betten verwalten .................................................................................................... 33

UC-0023 Dienstleistungen verwalten .................................................................................... 34

3.3.1.3 Administration Stammdaten ..................................................................................... 34

UC-0040 Berge verwalten ..................................................................................................... 35



UC-0041 Berghütten verwalten ............................................................................................ 36

UC-0042 Routen verwalten ................................................................................................... 37

UC-0043 Benutzer und Rollen verwalten .............................................................................. 38

3.3.2 Tabellarische Auflistung der funktionalen Anforderungen ........................................... 40

AG-0010 Webapplikation ...................................................................................................... 40

AG-0020 Formal falsche Benutzereingaben .......................................................................... 40

AG-0030 Webapplikation ...................................................................................................... 41

AG-0040 Benutzerregistrierung ............................................................................................ 41

AG-0050 An- und Abmelden ................................................................................................. 42

AG-0060 Dynamische Berechnungen in Formularen ............................................................ 43

AG-0070 Beibehalten von Benutzereingaben ....................................................................... 43

AF-1010 Basisdaten ............................................................................................................... 44

AF-1020 Berge auf Landkarte ................................................................................................ 45

AF-1030 Abrufen von Informationen .................................................................................... 45

AF-1040 Tour anbieten .......................................................................................................... 46

AF-1050 Tour buchen ............................................................................................................ 47

AF-1055 Buchungsbestätigung .............................................................................................. 48

AF-1057 Angebotsbestätigung .............................................................................................. 49

AF-1060 Bett anbieten .......................................................................................................... 50

AF-1070 Dienstleistung anbieten .......................................................................................... 51

AF-1080 Benachrichtigungen bei Statusänderungen ............................................................ 51

AF-1090 Tagesendverarbeitung ............................................................................................ 52

AF-1100 Kreditkarten Informationen prüfen ........................................................................ 53

3.4 Weitere Anforderungen ........................................................................................................ 54

3.5 Nicht-Funktionale Anforderungen ........................................................................................ 54

3.5.1 Anforderungen an das Grafische User-Interface .......................................................... 54

AN-5010 Publikum ................................................................................................................. 54

AN-5020 Corporate Design .................................................................................................... 54

AN-5030 Mehrsprachigkeit ................................................................................................... 55

3.5.1.1 Benutzbarkeit ............................................................................................................ 56

AN-5100 Systemverständlichkeit .......................................................................................... 56

AN-5110 Systembedienbarkeit ............................................................................................. 56

3.5.2 Zugriffsschutz- und Sicherheits-Anforderungen ........................................................... 57

3.5.2.1 Unauthorisierter Zugriff ............................................................................................ 57

3.5.2.2 Authentifizierung ....................................................................................................... 57



3.5.2.3 Rollenkonzept ............................................................................................................ 57

3.5.3 Performanz-Anforderungen .......................................................................................... 58

3.5.3.1 Effizienz ..................................................................................................................... 58

3.5.4 Design- und Implementations-Anforderungen ............................................................. 58

3.5.4.1 Zuverlässigkeit ........................................................................................................... 58

3.5.4.2 Systeminstallierbarkeit .............................................................................................. 59

3.5.4.3 Änderbarkeit .............................................................................................................. 59

3.5.5 Rechtliche Anforderungen ............................................................................................ 59

3.5.6 Lizenzen ......................................................................................................................... 59

4 Projekt-Randbedingungen ............................................................................................................. 59

4.1 Technische Randbedingungen .............................................................................................. 59

4.1.1 Betriebssystem .............................................................................................................. 59

4.1.2 Datenbank-Engine ......................................................................................................... 60

4.2 Dokumentation ..................................................................................................................... 60

4.2.1 Benutzer-Dokumentation .............................................................................................. 60

4.2.2 System-Dokumentation ................................................................................................. 60

4.3 Zeitplan .................................................................................................................................. 60

4.3.1 Gantt-Chart .................................................................................................................... 61

4.4 Kosten .................................................................................................................................... 62

4.5 Datenschutz ........................................................................................................................... 62

4.6 Offene Punkte ....................................................................................................................... 63

4.7 Lieferumfang ......................................................................................................................... 63

Abbildungsverzeichnis

Abbildung 1 – Stakeholder PYT ............................................................................................................... 9 Abbildung 2 – Funktionalitäten PYT ...................................................................................................... 19 Abbildung 3 – Zusammenhänge fachliche Entitäten............................................................................. 20 Abbildung 4 – UseCase Diagramm Business ......................................................................................... 22 Abbildung 5 – UseCase Diagramm Verwaltung ..................................................................................... 31 Abbildung 6 – UseCase Diagramm Stammdaten .................................................................................. 35 Abbildung 7 – Rollenvererbung ............................................................................................................. 58



Vorwort

Dieses Lastenheft wurde im Rahmen des Integrationsprojekts im Kurs Software Engineering erstellt. Es handelt sich um einen fiktiven Projektinhalt, der durch die Studierenden selbst ausgewählt wurde. Das Lastenheft dient als Basis für die weiteren Arbeiten im Integrationsprojekt. Ein Teil der Anforderungen dieses Lastenhefts soll im Rahmen eines Prototyps umgesetzt werden. Was im Prototyp enthalten sein wird und was nicht, wird jeweils in diesem Lastenheft abgegrenzt.

Management Summary

Dieses Lastenheft definiert die Anforderungen an die Webapplikation „PlanYourTour“ (PYT), das im Auftrag der Firma MegaSport erstellt werden soll. PYT stellt Bergführern, Hüttenwarten und später weiteren Dienstleistungsanbietern eine Plattform zur Verfügung, um ihre Dienstleistungen besser vermarkten zu können.

Basis von PYT soll eine Landkarte sein, mit deren Hilfe die Berggänger als Endkunden einen für sie interessanten Berg und eine passende Tour auswählen können. Diese Touren werden vorgängig durch die Bergführer für bestimmte Daten zusammengestellt und beinhalten bei mehrtägigen Touren auch die Übernachtungen in Berghütten.

Für die Erstellung dieses Lastenhefts wurden als Hilfsmittel Mind Maps und Use Cases verwendet. Die wichtigsten Use Cases sind „Tour anbieten“ und „Tour buchen“.

In diesem Lastenheft ist ebenfalls eine Zeitplanung für den weiteren Projektverlauf enthalten. Die an die Abgabe des Lastenhefts folgende Realisierungsphase dauert von Juli bis Ende September. Das Lieferergebnis am Schluss der Realisierungsphase beinhaltet eine ausführliche Projektdokumentation sowie einen funktionsfähigen Prototyp mit definiertem reduziertem Funktionsumfang.



1 Einleitung

1.1 Konventionen

Aus Gründen der Lesbarkeit wird in diesem Dokument jeweils nur die männliche Form verwendet. Selbstverständlich sind auch Kundinnen, Berggängerinnen, Bergführerinnen und andere weibliche Personen gemeint.

Falls in einem Kapitel nichts zu beschreiben ist, wird dies mit dem Platzhalter-Text “Absichtlich leer” gekennzeichnet.

1.2 Zweck

Dieses Dokument beschreibt die Anforderungen der Firma MegaSport an die neu zu entwickelnde Applikation PlanYourTour PYT, mit der eine Online-Bergtourenplanung möglich ist.

1.3 Ausgangslage

Die Firma MegaSport bietet verschiedene Online-Plattformen an, um sorgenfrei und praktisch Unterkünfte bei Sportevents zu planen. Als neues Segment soll nun eine Planung von Tages- und Mehrtagessportaktivitäten hinzukommen. Es wird mit einer Online-Bergtourenplanung begonnen.

1.4 Ziele

Die Online-Bergtourenplanung soll spezifisch auf den Bergtourismus zugeschnitten sein und dabei Personen ansprechen, die auf eine ambitionierte Bergtour gehen möchten. Diese Kunden sollen in einer einzigen Webapplikation eine passende Bergtour nach verschiedenen Suchkriterien finden können. Dazu sollen die notwendigen Ressourcen (Bergführer, Kletterpartner, Bergausrüstung, Sportzubehör, Hotel, Berghütte, Transport, Versicherung) gebucht werden können.

Ein Ausbau des Geschäftsfeldes in weitere ressourcenintensive Sportarten wie zum Beispiel Tauchen oder Reiten ist geplant.

1.5 Produktumfang

Die Applikation PlanYourTour soll es dem User ermöglichen, auf attraktive und übersichtliche Art eine anspruchsvolle Bergtour planen und die benötigten Ressourcen buchen zu können.

● Verschiedene Einstiegswege (Landkarte, Berg, Vorschläge nach Präferenzen)

● Anzeige wesentlicher Informationen (Hütten, Bergführer, Sportartikelverleih etc.)

● Zusammenstellung und Buchung des benötigten, individuellen Dienstleistungspakets

● Online-Markt für Dienstleister



1.6 Stakeholder

Abbildung 1 – Stakeholder PYT

Stakeholder Ziele Einfluss auf das Projekt

Interesse Methode zum Einholen der Anforderungen

MegaSport Auftraggeber hoch hoch Workshop, Interviews, Fragebogen

Dienstleister Umsatzsteigerung, Steigerung der Bekanntheit tief hoch Interviews, Fragebogen

Örtliches Gewerbe Gezielte Werbung tief hoch Fragebogen

Tourismuszentrale Förderung des Tourismus, Umsatzsteigerung tief hoch Fragebogen

Gemeindeverwaltung Promotion der Gemeinde, Unterstützung durch Gemeinde

tief tief Fragebogen



1.7 Definitionen, Akronyme, Abkürzungen, Glossar

1.7.1 Fachbegriffe

Route Geografische Beschreibung eines Wegs von A nach B

Tour Kombination von Route, Bergführer, Berghütte, evtl. weitere Dienstleistungen, Datum von, Datum bis

Gebuchte Tour Eine Tour, die von Kunden gebucht ist, bezahlt ist und somit durchgeführt wird

Gebucht Eine Ressource ist definitiv exklusiv reserviert und bezahlt (für eine fest definierte Tour)

Benutzer Ein beliebiger Applikationsbenutzer dieses Systems

Stakeholder Wissensträger oder Person mit direktem oder indirektem Interesse am Projekt

MegaSport Auftraggebende Unternehmung

PYT Abkürzung für den Namen der hier im Projekt entwickelten Applikation PlanYourTour

PlanYourTour Name der hier im Projekt entwickelten Applikation

Hüttenwart Eine Person, die eine Berghütte betreibt und die Betten anbietet.

1.7.2 Informatik-Begriffe

GUI Grafische Benutzeroberfläche (Graphical User Interface)

SRS Anforderungsspezifikation (Software Requirements Specification)

IEEE 830-1998 Empfehlung der IEEE Organisation bezüglich der Ausgestaltung einer SRS

Plausibilitätsprüfung Programmgesteuerte Kontrolle von Eingaben. Ziel ist die Unterbindung unsinniger Eingaben. (Quelle: http://www.geoinformatik.uni-rostock.de/einzel.asp?ID=-381491132)

UID User Identifier = Benutzerkennung, die den Benutzer eindeutig identifiziert

1.7.3 Prozess-Wörter

In den Anforderungen werden folgende Prozess-Wörter verwendet:

verwalten Erfassen, ändern, speichern und (wo sinnvoll resp. nicht anders spezifiziert) löschen.

erfassen/verwalten Synonym mit verwalten, dient der besseren Lesbarkeit für die Stakeholder.

http://www.geoinformatik.uni-rostock.de/einzel.asp?ID=-381491132

http://www.geoinformatik.uni-rostock.de/einzel.asp?ID=-381491132



erzeugen Ausgelöst durch eine Schaltfläche oder eine Menü-Option wird eine Tabelle, Liste oder ein Dokument auf dem Bildschirm erzeugt.

drucken Eine Liste, ein Dokument auf dem Standard-Drucker ausdrucken

Liste Tabelle auf Papier, als PDF, als HTML, als XML etc., eine Liste ist formatiert und mit Listenkopf, Listenkörper und Listenfuss gemäss Muster/Vorgabe der Firma MegaSport gestaltet.

Tabelle Tabelle in einer Bildschirmmaske.

Eingeben Das System erwartet einen Input von einem Benutzer. Dabei ist zu beachten, dass in diesem Dokument nicht vorgeschrieben ist, wie z.B. ein Datum vom Benutzer abgefragt wird, d.h. ob dies ein einfaches Textfeld oder eine Date-Picker-Komponente ist. Dem Benutzer sollte aber „beste Usability“ geboten werden!

freigeschaltet Wird vor allem in Zusammenhang mit Angeboten benutzt und bedeutet, dass ein Angebot ab diesem Zeitpunkt gebucht oder gekauft werden kann.

1.7.4 Logische Operatoren

Mit logischen Operatoren können Bedingungen beliebig verknüpft werden und liefern immer den Wert 0 (falsch) oder 1 (wahr) als Resultat zurück.

Im Projekt PYT werden explizit die englischen Bezeichnungen verwendet. So ist eine Verwechslung mit „und“, „oder“ nicht möglich.

Begriff Beschreibung

AND-Bedingung Alle Bedingungen müssen erfüllt sein, damit das Resultat wahr ist.

OR-Bedingung Mindestens ein Wert der Bedingung muss erfüllt sein, damit das Resultat wahr ist.

XOR-Bedingung Nur ein Wert der Bedingung darf erfüllt sein, damit das Resultat wahr ist.

NOT-Bedingung Der Wert darf nicht erfüllt sein, damit das Resultat wahr ist.

1.7.5 Raster für UseCases

UC-<Nummer> Titel

Kurzbeschreibung

Akteure

Auslöser

Ergebnis(se)

Eingehende Daten



Vorbedingungen

Nachbedingungen

Essenzielle Schritte

Offene Punkte

Im Prototyp ja teilweise nein

Änderungshistorie wann wer neuer Status was

Sonstiges, Anmerkungen

keine

1.7.5.1 Legende

<Nummer> 4-stellige Nummer des UseCases

1.7.6 Raster für Anforderungen

A<Typ>-<Nummer> Titel

Beschreibung

Details

Regeln

Kommentar

Status in Bearbeitung freigegeben gelöscht

Priorität hoch mittel tief

Quelle

Referenz

Im Prototyp ja nein

Version Datum Vers.Nr. Autor Änderung



1.7.6.1 Legende

<Typ> Typ der Anforderung (G=Generell / F=Funktional / N=Nichtfunktional)

<Nummer> 4-stellige Nummer der Anforderung

1.8 Masseinheiten

Absichtlich leer.

1.9 Referenzen

Quelle der Vorlage der SRS: IEEE 830-1998, ISBN 0-7381-0448-5, The Institute of Electrical and Electronics Engineers

1.10 Übersicht über die folgenden Kapitel der SRS

Diese SRS wurde gemäss IEEE 830-1998 ausgestaltet.

Das Kapitel 2 beschreibt das ganze System aus einer übergeordneten Sicht und soll das Verständnis für das ganze Projekt schaffen. Dieses Kapitel beinhaltet keine spezifischen Anforderungen.

Die spezifischen Anforderungen sind in den Kapitel 3, 4 und 5 beschrieben.

Das Kapitel 3 beinhaltet die allgemeinen und generellen Anforderungen

Das Kapitel 4 beinhaltet die Funktionalen Anforderungen.

Das Kapitel 5 beinhaltet die Nicht-Funktionalen Anforderungen.

Im Kapitel 6 sind die Projekt-Randbedingungen beschrieben.

2 Gesamt-Übersicht

2.1 Produkt-Umfeld

Bereits heute gibt es Tourismusportale mit Webcam Ansichten und Wetterinformationen. Ebenso gibt es Hotelportale, die meist wenig zielgruppenorientiert ausgerichtet sind. Der Online-Bergführer soll spezifisch auf den Bergtourismus zugeschnitten sein und dabei Personen ansprechen, die ambitionierte Bergtouren durchführen möchten. Diese Kunden sollen in einer einzigen Webapplikation eine passende Bergtour nach verschiedenen Suchkriterien finden können. Anschliessend sollen die notwendigen Ressourcen (Bergführer, Kletterpartner, Bergausrüstung, Sportzubehör, Hotel, Berghütte, Transport, Versicherung) gebucht werden können.

Heute gibt es keine solche Möglichkeit, übersichtlich an einer einzigen Quelle die notwendigen Ressourcen zu finden und buchen. Dies zeigen die Fälle der ausländischen Bergsteiger, die gerettet werden müssen, weil sie nicht über die passende Vorbereitung und Ausrüstung verfügen. Besonders für solche Kunden, die nicht über das nötige lokale Wissen verfügen, kann diese Applikation sehr wertvoll sein.



Das Umfeld von “PlanYourTour” bietet eine grosse Anzahl von Ausbaumöglichkeiten:

ergänzende Informationen (Wetter, weitere Sport- und Freizeitaktivitäten, kulturelle Angebote im Ort)

Bewertungen der Touren durch die Kunden bezüglich Schwierigkeitsgrad, Aussicht, Spassfaktor

Bewertung von Dienstleistungsanbietern durch die Kunden, die das Angebot gebucht haben

Forum zum Austausch zwischen dem interessierten Zielpublikum

Ausweitung der Planungsdienstleistungen von Bergtouren auf Skitouren

2.1.1 System-Schnittstelle

Absichtlich leer

2.1.2 Benutzer-Schnittstelle

Webapplikation mit Web-GUI.

2.1.3 Hardware-Schnittstelle

Absichtlich leer

2.1.4 Software-Schnittstelle

2.1.4.1 Bezahlung mit Kreditkarte

Es muss zudem eine Kreditkartenschnittstelle zur Kreditkartengesellschaft gebaut werden.

2.1.4.2 Google Maps

Es wird eine Schnittstelle zu Google Maps realisiert, um Kartendaten zu verwenden und diese grafisch aufzubereiten. Die Informationen zur Lizenzierung können unter https://developers.google.com/maps/licensing?hl=de nachgelesen werden.

Für das vorliegende Projekt werden nur die kostenlosen Services verwendet. Falls später die Bedingungen für eine kostenlose Nutzung überschritten werden, muss ein Vertrag ausgehandelt werden oder eine Migration auf Open Street Map (http://www.openstreetmap.org/) in Betracht gezogen werden.

https://developers.google.com/maps/licensing?hl=de

http://www.openstreetmap.org/



2.1.5 Kommunikations-Schnittstelle

Typ der Schnittstelle Kommunikationspartner Beschreibung

Benutzer Berggänger Kommunikation erfolgt über Webapplikation, E-Mail, Benachrichtigungen und erzeugte Kundendokumente

Bergführer Webapplikation, E-Mail Benachrichtigung

Hüttenwart Webapplikation, E-Mail Benachrichtigung

Weitere Dienstleistungsanbieter

Webapplikation, E-Mail Benachrichtigung

Service Kreditkartengesellschaft Elektronische Schnittstelle

Google Maps Einbindung mittels API

2.1.6 Betriebssystem-Plattform

Geeignete Betriebssystem-Plattform für den JEE6-Full-Profile Applikationsserver. In der Regel wird dazu Linux verwendet.

2.1.7 Speicher-Beschränkungen

Keine besonderen Beschränkungen

2.1.8 Operationen

Absichtlich leer.

2.1.9 Standort-spezifische Anforderungen

Absichtlich leer.

2.2 Produkt-Funktionalität

Die Webapplikation PlanYourTour soll ein attraktives und übersichtliches Tool sein, um Bergtouren planen zu können. Der Benutzer soll in verschiedener Weise den Einstieg in die Planung seiner Tour finden:

Landkarte, die dem Kunden einen geografischen Überblick verschafft und von wo aus er sich den passenden Berg aussuchen kann

Auswahl eines Bergs direkt mittels Namen (z.B. mit Dropdown-Auswahl)

Suche eines passenden Bergs bzw. einer passenden Bergtour durch Eingabe der Kundenpräferenzen. Hier können Faktoren wie Schwierigkeitsgrad, Routenlänge (Zeit oder Distanz), Aussicht, Erlebnisfaktor, Unterkunftskomfort eingegeben werden. Das System soll dem Benutzer die passenden Berge mit den dazugehörigen Tourenmöglichkeiten vorschlagen.



Sobald der passende Berg ausgesucht wurde, muss die Applikation die wesentlichen Informationen des betroffenen Berggebiets anzeigen: Basisdaten, Routen, Anforderungen. Ebenso werden die angebotenen Dienstleistungen wie Unterkünfte, Bergführer, Berghütten, Sportgeschäft, Vermietung von Ausrüstungsgegenständen, Abschluss von Unfall- und Annullationskostenversicherung in das Angebot integriert.

Besonders an der geplanten Applikation soll sein, dass die Kunden sich das benötigte Dienstleistungspaket zusammenstellen und buchen können. Als Vision könnte dies in einer späteren Version so erfolgen, dass der Kunde ein Profil seiner Kletterkenntnisse und anderer Präferenzen erstellt und darauf abgestimmt die Empfehlung für das passende Dienstleistungspaket erfolgt. Für den hier beschriebenen Projektantrag ist dies aber “out of scope”.

Die Dienstleistungsanbieter sollen sich in der Applikation mit ihrem Angebot registrieren können. Es soll ihnen ermöglicht werden, einfach mit ihrem Angebot auf den Online-Markt zu gehen und Buchungen zu erhalten. Hüttenwarte oder Bergführer, die heute nur “offline” gebucht werden können, können sich so einen neuen Markt schaffen. Für die Dienstleistung müssen sie eine Kommission bezahlen, die neben der aufgeschalteten Werbung die Haupteinnahmequelle für den Betreiber der Online-Bergtourenplanung ist.

2.3 Abgrenzung

PlanYourTour soll mit zusätzlichen Funktionen erweiterbar sein. Nachfolgende Abgrenzung zeigt die Funktionalitäten, die nicht im Projektumfang enthalten sind:

Mehrsprachenfähigkeit

Fremdwährungen

Steuern und Kurtaxen

Planung und Dienstleistungen für Skitouren

Detaillierte Analyse und Umsetzung der Buchhaltung und Zahlungsflüsse

Realisierung der zukünftigen Ausbaumöglichkeiten gemäss Auflistung am Ende des Kapitels 2.1 “Produkt-Umfeld”. Je nach zur Verfügung stehenden Projektressourcen werden einzelne ausgewählte Elemente während des Projekts in den Projektumfang aufgenommen.

2.4 Mengengerüst, Periodizitäten

Folgendes Mengengerüst und Periodizität ist gegeben:

Endprodukt Prototyp

Anzahl erfasste Berge in PYT 50 5

Anzahl angebotene Routen in PYT 150 5

Anzahl verkaufter Touren pro Jahr durch MegaSport 200 5

Anzahl Hütten in PYT 50 5

Anzahl Betten in PYT 500 50

Anzahl registrierte Bergführer in PYT 20 3

Anzahl registrierte Berggänger in PYT 500 5



2.5 Benutzer-Charakteristika

Es gibt folgende Benutzergruppen der Applikation “PlanYourTour”:

Nicht angemeldeter Benutzer der Applikation: Er will schnell und intuitiv durch die Webapplikation navigieren können und Informationen zu Touren und Berge finden.

Bergführer: Er kann sich einloggen und auf eine einfache Weise Touren auf der Plattform für von ihm definierten Daten anbieten. Falls er als Führer für eine Tour gebucht wird, will er sofort darüber informiert werden.

Berggänger: Der Berggänger kann sich einloggen und sich eine Tour zusammenstellen. Auf der Plattform kann er eine Route und den Bergführer auswählen und die Tour buchen.

Hüttenwart: Der Hüttenwart stellt ein gewisses Kontingent an Betten zur Verfügung. Er will einerseits informiert werden, wenn Übernachtungen gebucht werden und andererseits, wenn bis zu einem von ihm definierten Zeitpunkt Betten frei bleiben.

Anbieter von Dienstleistungen: Hier handelt es sich um Anbieter von weiteren Dienstleistungen (neben Bergführern und Berghütten). Ihr Ziel es ist, ihre Dienstleistungen über die Applikation verkaufen zu können. Beispiel: Mietausrüstungen für Bergtouren (Seile, Funkgeräte).

Administrator der Firma “MegaSport”: Der Administrator kann sich einloggen und Routen zu bestimmten Bergen erfassen. Er kennt die Branche sehr gut und ist fähig, Routen beschreiben und bewerten zu können.

2.6 Randbedingungen

Die Webapplikation soll einfach beginnen und später ausbaubar sein. Aus Gründen der Klarheit wird nachfolgend definiert, was für diesen Projektantrag im, respektive ausserhalb des Projektscope ist.

Im Projektumfang enthalten (wovon im Prototyp nur eine Teilmenge umgesetzt wird):

Anzeige von Basisinformationen zu Bergen und Bergtouren im gewählten Gebiet

Planung und Dienstleistungen im Zusammenhang mit Bergtouren

Login für Administrator der Webapplikation zur Erfassung der Stammdaten (Berge und Routen)

Login für Endkunden (d.h. für die Berggänger)

Login für Dienstleistungsanbieter, beschränkt auf Bergführer und Hüttenwart

Ausgearbeitete Online-Buchungsmöglichkeit für Bergführer und Berghütten. Die Buchung der weiteren Dienstleistungen wie Unterkünfte, Vermietung von Ausrüstungsgegenständen aus Sportgeschäften, Abschluss von Unfall- und Annullationskostenversicherung wird nur oberflächlich ausgearbeitet.

Währung: nur CHF

2.7 Annahmen und Abhängigkeiten

Folgende Annahmen werden getroffen:

Jede Tour ist genau einem Berg zugewiesen.

Eine Tour ist nur buchbar, wenn der Bergführer für den gewünschten Zeitpunkt verfügbar ist.



Ein Bergführer kann gleichzeitig mehrere Touren für den gleichen Tag anbieten, d.h. er kann sich provisorisch überbuchen.

Nur registrierte Berggänger können eine Tour buchen

Wird eine Tour gebucht die länger als einen Tag dauert, so ist zwingend eine Übernachtung in einer Hütte zu buchen.

2.8 Realisierungs-Verschiebung

Aktuell gibt es keine Hinweise auf eine mögliche Verschiebung der Realisierung.

3 Spezifische Anforderungen

3.1 Externe Schnittstellen

3.1.1 User Interfaces

Das User Interface muss den heutigen Standards entsprechen. Da es sich um ein User Interface innerhalb eines Web Browsers handelt, soll der HTML5 Standard unterstützt werden. Für die Umsetzung des User Interfaces wird PrimeFaces verwendet (http://www.primefaces.org/), dieses bietet eine grosse Auswahl an Komponenten an und hat sich schon in anderen Projekten bewährt.

Der Projektumfang ist auf eine einsprachige Benutzeroberfläche beschränkt.

3.1.2 Hardware Interfaces

Das System beinhaltet keine Hardware Interfaces.

3.1.3 Software Interfaces

Das System beinhaltet eine Schnittstelle zu Google Maps. Mithilfe dieser Schnittstelle kann das System Landkarten grafisch anzeigen.

3.1.4 Kommunikations-Interfaces

Absichtlich leer.

http://www.primefaces.org/



3.2 Generelle Anforderungen

3.2.1 Gesamtüberblick in Form einer Mind Map

Abbildung 2 – Funktionalitäten PYT



3.2.2 Fachliche Entitäten

In der folgenden Grafik sind die wichtigsten fachlichen Entitäten und ihre Zusammenhänge aufgezeigt. Die Grafik ist aus Sicht Business zu verstehen und soll die Basis für das bessere Verständnis der UseCases und der funktionalen Anforderungen bilden.

Abbildung 3 – Zusammenhänge fachliche Entitäten



3.2.3 Fehlerbehandlungen

Absichtlich leer.

3.2.4 Plausibilitäten

Das System muss die Plausibilitäten gemäss folgender Tabelle prüfen. Prio 1 = hoch, Prio 2 = mittel, Prio 3 = niedrig.

Inhalt der Plausibilitätsprüfung Priorität Im Prototyp enthalten?

Dauer einer vom Bergführer definierten Tour <= 5 Tage 1 ja

Gleicher Berggänger kann nicht am gleichen Tag an mehreren Touren teilnehmen

1 nein

Gleicher Bergführer kann nicht am gleichen Tag mehrere Touren führen

1 nein

Anzahl der Betten in einer Berghütte < 100 2 nein

Länge einer Bergtour pro Tag < 20 Kilometer 3 nein

Anzahl Personen auf einer Bergtour pro Bergführer < 20 2 nein

Fixpreis pro Bergführer pro Tag < CHF 5000 2 nein

3.2.5 Layout und Formate der Masken

Absichtlich leer.

3.3 Funktionale Anforderungen

3.3.1 Use Cases

Die Identifizierten Use Cases wurden grob in drei Gruppen eingeteilt:

Business Use Cases, die den eigentlichen Mehrwert für das Business bieten.

Verwaltung Use Cases, die zur Verwaltung der aus den Business Use Cases generierten Daten identifiziert wurden.

Administration Stammdaten Use Cases, die zur Pflege der Stammdaten nötig sind.

Um die Aktivitätsdiagramme möglichst nicht zu überladen, werden die Abhängigkeiten zwischen den Akteuren in den folgenden Diagrammen weggelassen. Die Abhängigkeiten werden dann im Rollenkonzept unter 3.5.2.3.1 aufgezeigt.

3.3.1.1 Business

In Abbildung 4 sind die identifizierten Anwendungsfälle dargestellt, welche wichtig für das Business sind und den eigentlichen Mehrwert bieten.



Abbildung 4 – UseCase Diagramm Business

UC-0001 Tour buchen

Kurzbeschreibung Ein Berggänger bucht eine Tour.

Akteure Berggänger

Auslöser Ein Berggänger will einen Berg besteigen.

Ergebnis(se) Der Berggänger hat eine Tour gebucht.

Eingehende Daten Daten zu einer Tour

Vorbedingungen Der Benutzer ist eingeloggt AND der Benutzer hat die Rolle Berggänger.

Nachbedingungen Das System hat die Tour mit allen Dienstleistungen gebucht.




Offene Punkte -





22.06.2013 II In Bearbeitung Entwurf

26.06.2013 II Freigegeben Nummer der Anforderungen eingefügt


keine

UC-0002 Route auswählen

Kurzbeschreibung Ein Benutzer sucht eine Route und wählt diese aus.

Akteure Benutzer

Auslöser Ein Benutzer will eine Route auswählen.

Ergebnis(se) Der Benutzer hat die gewünschte Route ausgewählt.

Eingehende Daten Daten der Routen, welche zum im System vermerkten Berg gehören.

Vorbedingungen UC-0003 „Berg auswählen“ wurde durchgeführt AND im System ist ein Berg vermerkt

Nachbedingungen Das System hat sich die gewünschte Route vermerkt.

Essenzielle Schritte Das System zeigt die Routen an

Der Benutzer sucht eine Route

Das System zeigt dem Benutzer Details über eine Route an (AF-1030)

Der Benutzer wählt eine Route aus

Das System merkt sich die Route

Offene Punkte keine




26.03.2013 II In Bearbeitung Nummer der Anforderungen eingefügt

28.06.2013 II Freigegeben Grafik durch Text ersetzt


keine

UC-0003 Berg auswählen

Kurzbeschreibung Ein Benutzer sucht einen Berg und wählt diesen aus.



Akteure Benutzer

Auslöser Ein Benutzer will einen Berg auswählen.

Ergebnis(se) Der Benutzer hat den gewünschten Berg ausgewählt.

Eingehende Daten Daten der Berge

Vorbedingungen Keine

Nachbedingungen Das System hat den ausgewählten Berg vermerkt.

Essenzielle Schritte Das System zeigt die Berge an

Der Benutzer sucht einen Berg

Das System zeigt dem Benutzer Details über einen Berg an (AF-1030)

Der Benutzer wählt einen Berg aus

Das System merkt sich den Berg

Offene Punkte keine






keine

UC-0004 Tour anbieten

Kurzbeschreibung Ein Bergführer bietet eine Tour an.

Akteure Bergführer

Auslöser Ein Bergführer will eine Tour anbieten.

Ergebnis(se) Der Bergführer hat eine Tour im System erfasst.

Eingehende Daten Der im System vermerkte Berg AND die im System vermerkte Route

Vorbedingungen Der Benutzer ist eingeloggt AND der Benutzer hat die Rolle Bergführer AND der UC-0003 „Berg auswählen“ wurde durchgeführt AND der UC-0002 „Route auswählen“ wurde durchgeführt

Nachbedingungen Das System hat die erfassten Tourendaten in der Datenbank gespeichert und



das Angebot freigeschaltet.


Offene Punkte keine




26.06.2013 II Freigegeben Überarbeitung Diagramm

Sonstiges, keine



Anmerkungen

UC-0005 Dienstleistung auswählen

Kurzbeschreibung Ein Berggänger sucht eine Dienstleistung und wählt diese aus.

Akteure Berggänger

Auslöser Ein Berggänger will eine Dienstleistung auswählen.

Ergebnis(se) Der Berggänger hat eine Dienstleistung ausgewählt.

Eingehende Daten Stammdaten der Dienstleistungen

Vorbedingungen Der Benutzer ist am System angemeldet AND der Benutzer hat die Rolle Berggänger

Nachbedingungen Das System hat sich die gewünschte Dienstleistung vermerkt.

Essenzielle Schritte Das System zeigt die Dienstleistungen an

Der Benutzer sucht eine Dienstleistung

Das System zeigt dem Benutzer Details über eine Dienstleistung an (AF-1030)

Der Benutzer wählt eine Dienstleistung aus

Das System merkt sich die Dienstleistung

Offene Punkte keine




28.06.2013 Freigegeben Grafik durch Text ersetzt


keine

UC-0006 Dienstleistung anbieten

Kurzbeschreibung Ein Dienstleister bietet eine Dienstleistung an.

Akteure Dienstleister

Auslöser Ein Dienstleister will eine Dienstleistung anbieten.

Ergebnis(se) Der Dienstleister hat eine Dienstleistung im System erfasst.



Eingehende Daten Der im System vermerkte Berg AND die im System vermerkte Route

Vorbedingungen Der Benutzer ist eingeloggt AND der Benutzer hat die Rolle Dienstleister

Nachbedingungen Das System hat die erfassten Dienstleistungsdaten in der Datenbank gespeichert und das Angebot freigeschaltet.


Offene Punkte keine




28.06.2013 II Freigegeben -

Sonstiges, keine



Anmerkungen

UC-0007 Hütte auswählen

Kurzbeschreibung Ein Hüttenwart sucht eine Hütte und wählt diese aus.

Akteure Hüttenwart

Auslöser Ein Hüttenwart will eine Hütte auswählen.

Ergebnis(se) Der Hüttenwart hat eine Hütte ausgewählt.

Eingehende Daten Daten der Hütten

Vorbedingungen Der Benutzer ist am System angemeldet AND der Benutzer hat die Rolle Hüttenwart

Nachbedingungen Das System hat sich die gewünschte Hütte vermerkt.

Essenzielle Schritte Das System zeigt die Hütten an

Der Benutzer sucht eine Hütte

Das System zeigt dem Benutzer Details über eine Hütte an (AF-1030)

Der Benutzer wählt eine Hütte aus

Das System merkt sich die Hütte

Offene Punkte Muss der Benutzer als Vorbedingung erst einen Berg und eine Route ausgewählt haben damit er die Hütte auswählen kann?

o Es könnte sein, dass eine Hütte zu mehreren Routen gehört!






keine

UC-0008 Betten anbieten

Kurzbeschreibung Ein Hüttenwart bietet ein Bett an.

Akteure Hüttenwart

Auslöser Ein Hüttenwart will ein Bett anbieten.

Ergebnis(se) Der Hüttenwart hat ein Bett im System erfasst.



Eingehende Daten Daten der Hütten

Vorbedingungen Der Benutzer ist eingeloggt. Der Benutzer hat die Rolle Hüttenwart.

Nachbedingungen Das System hat das erfasste Bett in der Datenbank gespeichert AND das Bett im Status „frei“ freigeschaltet.


Offene Punkte keine






keine



3.3.1.2 Verwaltung

In Abbildung 5 sind die identifizierten Anwendungsfälle dargestellt, welche eine Verwaltung der aus den Business-UseCases generierten Daten ermöglichen.

Abbildung 5 – UseCase Diagramm Verwaltung

UC-0020 Buchungen verwalten

Kurzbeschreibung Der Benutzer sieht sich seine Buchung an oder storniert eine Buchung.

Akteure Berggänger oder Administrator

Auslöser Ein Benutzer will eine Buchung ändern

Ergebnis(se) Aktualisierter Status einer Buchung

Eingehende Daten Daten zu Buchungen des aktuell angemeldeten Benutzers

Vorbedingungen Der Benutzer ist eingeloggt AND [der Benutzer hat die Rolle Berggänger OR Administrator]

Nachbedingungen Keine

Essenzielle Schritte Das System zeigt alle Buchungen des aktuell angemeldeten Benutzers an.

Der Benutzer wählt eine Buchung aus.

Der Benutzer storniert die Buchung.

Das System zeigt eine Warnung an.

Der Benutzer bestätigt die Warnung.



Das System setzt den Status der Buchung auf „storniert“.

Das System storniert alle zur Buchung gehörenden Ressourcen (Betten, Dienstleistungen, etc.).

Das System benachrichtigt alle zur Buchung gehörenden Anbieter (Bergführer, Hüttenwart, Dienstleister, etc.).

Offene Punkte Keine






In einer ersten Version ist es nur möglich, eine Buchung komplett zu stornieren!

UC-0021 Touren verwalten

Kurzbeschreibung Der Benutzer sieht sich seine angebotenen Touren an oder sagt eine angebotene Tour ab.

Akteure Bergführer oder Administrator

Auslöser Ein Benutzer will eine Tour ändern

Ergebnis(se) Aktualisierter Status einer Tour

Eingehende Daten Daten zu angebotenen Touren des aktuell eingeloggten Benutzers

Vorbedingungen Der Benutzer ist eingeloggt AND [der Benutzer hat die Rolle Bergführer OR Administrator]


Essenzielle Schritte Das System zeigt alle angebotenen Touren des aktuell angemeldeten Benutzers an.

Der Benutzer wählt eine Tour aus.

Der Benutzer sagt die Tour ab.

Das System zeigt eine Warnung an.

Der Benutzer bestätigt die Absage.

Das System setzt den Status der angebotenen Tour auf „abgesagt“.

Das System storniert alle zur Tour gehörenden Ressourcen (Betten, Dienstleistungen, etc. ).

Das System benachrichtigt alle zur Tour gehörenden Anbieter und Teilnehmer (Berggänger, Hüttenwart, Dienstleister, etc. ).



Offene Punkte Keine






In einer ersten Version ist es nur möglich, eine Tour komplett abzusagen!

UC-0022 Betten verwalten

Kurzbeschreibung Der Benutzer sieht sich seine angebotenen Betten an oder aktualisiert den Status eines angebotenen Bettes.

Akteure Hüttenwart oder Administrator

Auslöser Ein Benutzer will den Status eines Bettes ändern

Ergebnis(se) Aktualisierter Status des Bettes

Eingehende Daten Daten zu angebotenen Betten des aktuell eingeloggten Benutzers

Vorbedingungen Der Benutzer ist eingeloggt AND [der Benutzer hat die Rolle Hüttenwart OR Administrator]


Essenzielle Schritte Das System zeigt alle angebotenen Betten des aktuell angemeldeten Benutzers an.

Der Benutzer wählt ein Bett aus.

Der Benutzer ändert den Status des Bettes

Das System setzt den Status des angebotenen Bettes auf den ausgewählten Status.

Offene Punkte Keine





Sonstiges,



Anmerkungen

UC-0023 Dienstleistungen verwalten

Kurzbeschreibung Der Benutzer sieht sich seine angebotenen Dienstleistungen an, ändert oder löscht eine angebotene Dienstleistung.

Akteure Dienstleister oder Administrator

Auslöser Ein Benutzer will eine angebotene Dienstleistung verwalten.

Ergebnis(se) Eine Dienstleistung wurde geändert.

Eingehende Daten Daten zu den Dienstleistungen des aktuell angemeldeten Benutzers.

Vorbedingungen Der Benutzer ist am System angemeldet AND [der Benutzer hat die Rolle Dienstleister OR Administrator]

Nachbedingungen Das System hat die Änderungen in der Datenbank gespeichert.

Essenzielle Schritte Das System zeigt alle angebotenen Dienstleistungen des aktuell angemeldeten Benutzers an.

Der Benutzer wählt eine Dienstleistung aus.

Der Benutzer ändert oder löscht die Dienstleistung.

Das System speichert die Änderungen in der Datenbank.

Offene Punkte Keine






keine

3.3.1.3 Administration Stammdaten

In der Abbildung 6 sind die identifizierten Anwendungsfälle dargestellt, welche die Verwaltung der Stammdaten ermöglichen.



Abbildung 6 – UseCase Diagramm Stammdaten

UC-0040 Berge verwalten

Kurzbeschreibung Der Benutzer fügt einen Berg hinzu, löscht einen Berg oder ändert Informationen zu einem Berg.

Akteure Administrator

Auslöser Ein Benutzer will die Stammdaten der Berge ändern.

Ergebnis(se) Stammdaten der Berge wurden geändert.

Eingehende Daten Aktuelle Stammdaten der Berge

Vorbedingungen Der Benutzer ist eingeloggt AND der Benutzer hat die Rolle Administrator

Nachbedingungen Das System hat die aktualisierten Stammdaten in der Datenbank gespeichert.

Essenzielle Schritte Ablauf A

Der Benutzer wählt den Berg aus

Der Benutzer wählt die Aktion löschen

Das System löscht den Berg aus den Stammdaten Ablauf B


Der Benutzer wählt die Aktion ändern

Das System zeigt ein Formular mit den vorhandenen Daten an

Der Benutzer ändert die gewünschten Daten

Der Benutzer bestätigt die Änderungen

Das System speichert die Daten



Ablauf C

Der Benutzer wählt die Aktion neu

Das System zeigt ein leeres Formular an

Der Benutzer füllt das Formular aus

Der Benutzer bestätigt die Eingaben


Offene Punkte Keine






keine

UC-0041 Berghütten verwalten

Kurzbeschreibung Der Benutzer fügt eine Berghütte hinzu, löscht eine Berghütte oder ändert Informationen zu einer Berghütte.


Auslöser Ein Benutzer will die Stammdaten der Berghütten ändern.

Ergebnis(se) Stammdaten der Berghütten wurden geändert.

Eingehende Daten Aktuelle Stammdaten der Berghütten

Vorbedingungen Der Benutzer ist eingeloggt. Der Benutzer hat die Rolle Administrator.



Der Benutzer wählt die Berghütte aus


Das System löscht die Berghütte aus den Stammdaten Ablauf B

Der Benutzer wählt die Berghütte aus





Das System speichert die Daten Ablauf C




Der Benutzer wählt die Route aus

Der Benutzer wählt die Aktion neue Berghütte





Offene Punkte Keine






keine

UC-0042 Routen verwalten

Kurzbeschreibung Der Benutzer fügt eine Route hinzu, löscht eine Route oder ändert Informationen zu einer Route.


Auslöser Ein Benutzer will die Stammdaten der Routen ändern.

Ergebnis(se) Stammdaten der Routen wurden geändert.

Eingehende Daten Aktuelle Stammdaten der Routen






Das System löscht die Route aus den Stammdaten Ablauf B









Ablauf C


Der Benutzer wählt die Aktion neue Route





Offene Punkte Keine






keine

UC-0043 Benutzer und Rollen verwalten

Kurzbeschreibung Der Benutzer fügt einen Benutzer oder eine Rolle hinzu, löscht einen Benutzer oder eine Rolle oder ändert Informationen zu einem Benutzer oder einer Rolle.


Auslöser Ein Benutzer will einen Benutzer oder eine Rolle ändern.

Ergebnis(se) Benutzer oder Rolle wurde geändert.

Eingehende Daten Aktuelle Informationen über Benutzer und Rollen


Nachbedingungen Das System hat die aktualisierten Informationen der Benutzer oder Rollen in der Datenbank gespeichert.

Essenzielle Schritte Die Schritte werden hier nicht weiter beschrieben. Es wird erwartet, dass eine technische Umsetzung erfolgt, die ein flexibles Verwalten von Benutzern, Rollen und Berechtigungen ermöglicht.

Offene Punkte Keine








keine



3.3.2 Tabellarische Auflistung der funktionalen Anforderungen

AG-0010 Webapplikation

Beschreibung Das System muss einem Benutzer zur Interaktion ein Web-Interface anbieten AND das System muss Mozilla Firefox ab Version 22 OR Google Chrome ab Version 27 unterstützen.

Details -

Regeln -

Kommentar -



Quelle Projektauftrag

Referenz -

Im Prototyp ja nein


15.06.2013 0.1 NA Initial

26.06.2013 0.2 II Präzisierung

AG-0020 Formal falsche Benutzereingaben

Beschreibung Das System muss formal falsche Benutzereingaben verhindern können.

Details Als “formal falsch” gelten Inhalte spezieller Datenfelder, die nicht den formalen Vorgaben entsprechen. Es handelt sich um die folgenden Daten:

Telefonnummern (formale Vorgabe: müssen numerisch AND maximal 15-stellig sein)

Datum (formale Vorgabe: TT.MM.YYYY) Wenn der Benutzer in ein Datenfeld formal falsche Daten eingibt, muss das System den Benutzer informieren.

Regeln -

Kommentar -





Quelle Projektteamsitzung 11.06.2013

Referenz -

Im Prototyp ja nein


15.06.2013 0.1 NA Initial


AG-0030 Webapplikation

Beschreibung Das System wird einen Benutzer warnen, wenn eingegebene Daten nicht gespeichert wurden.

Details Wenn ein Benutzer Mutationen vorgenommen hat AND ein Fenster verlassen werden soll, dann wird das System eine Warnung ausgeben AND dem Benutzer die Möglichkeit bieten, die Mutationen zu verwerfen oder zu speichern.

Regeln -

Kommentar -




Referenz -

Im Prototyp ja nein


15.06.2013 0.1 NA Initial


AG-0040 Benutzerregistrierung



Beschreibung Das System sollte einem Benutzer die Möglichkeit bieten, sich am System zu registrieren AND das System sollte dem Benutzer bei einer Registrierung mindestens die Rollen Berggänger und Bergführer anbieten.

Details

Regeln -

Kommentar -




Referenz Kapitel 2.5: Benutzerrollen

Im Prototyp ja nein


15.06.2013 0.1 NA Initial


AG-0050 An- und Abmelden

Beschreibung Das System muss einem Benutzer die Möglichkeit bieten, sich am System anzumelden AND sich am System abzumelden.

Details -

Regeln -

Kommentar -







Im Prototyp ja nein


15.06.2013 0.1 NA Initial


AG-0060 Dynamische Berechnungen in Formularen

Beschreibung Das System sollte bei Änderungen von Benutzereingaben an einem Formular dynamisch abhängige Attribute neu berechnen und dem Benutzer direkt anzeigen.

Details -

Regeln -

Kommentar Diese Anforderung betrifft vor allem Eingabeformulare, welche zum Beispiel Preise anzeigen. Falls der Benutzer zum Beispiel eine neue Dienstleistung hinzufügt, kann das System den Gesamtbetrag aktualisieren.





Im Prototyp ja nein


15.06.2013 0.1 NA Initial


AG-0070 Beibehalten von Benutzereingaben

Beschreibung Falls der Benutzer in einem Formular nicht korrekte Daten eingibt, sollte das System die eingegebenen Benutzereingaben beibehalten.



Details Das System sollte beim Einfordern von Daten diese auch prüfen AND falls die Prüfung nicht erfolgreich war, sollte das System den Benutzer erneut zu einer Eingabe auffordern AND das System sollte alle vom Benutzer schon einmal eingegebenen Daten im Formular beibehalten und anzeigen.

Regeln -

Kommentar Diese Anforderung soll mehr Komfort bringen, damit der Benutzer nicht immer alle Daten erneut eingeben muss, falls irgendeine ungültige Eingabe gemacht wurde.





Im Prototyp ja nein


15.06.2013 0.1 NA Initial


AF-1010 Basisdaten

Beschreibung Das System sollte es einem angemeldeten Benutzer mit der Rolle Administrator ermöglichen, Basisdaten zu Bergen, Routen und Berghütten zu erfassen.

Details -

Regeln -

Kommentar -






Referenz -

Im Prototyp ja nein


15.06.2013 0.1 NA Initial


AF-1020 Berge auf Landkarte

Beschreibung Das System muss einem Benutzer die Position der Berge mit einer Markierung auf einer Landkarte anzeigen.

Details -

Regeln -

Kommentar -




Referenz -

Im Prototyp ja nein


15.06.2013 0.1 NA Initial


AF-1030 Abrufen von Informationen

Beschreibung Das System muss einem Benutzer Informationen über Berge, Routen, Berghütten und Touren anzeigen.

Details Das System muss dem Benutzer das Abrufen von Informationen über Berge,



Routen, Berghütten und Touren auf einfache Art ermöglichen.

Regeln -

Kommentar -




Referenz -

Im Prototyp ja nein


15.06.2013 0.1 NA Initial


AF-1040 Tour anbieten

Beschreibung Das System muss es einem angemeldeten Benutzer mit der Rolle Bergführer ermöglichen, eine Tour anzubieten.

Details Das System muss den Benutzer zur Auswahl folgender Informationen auffordern

Berg

AND Route

AND Startdatum mit Startzeit

AND Enddatum mit Endzeit

AND Maximale Anzahl Teilnehmer AND WENN es eine mehrtägige Tour ist, muss das System prüfen, ob eine Berghütte auf der Route verfügbar ist AND das System muss prüfen, ob genügend freie Betten verfügbar sind AND das System muss eine Tour erst als buchbar freischalten, wenn eine Tour durch einen Bergführer angeboten wurde. AND das System muss den Benutzer auffordern, einen Festpreis für die angebotene Tour einzugeben. Der Festpreis für eine Tour ist unabhängig von der Anzahl Teilnehmer.



Regeln -

Kommentar -



Quelle Erarbeitetes Aktivitätsdiagramm aus Projektteamsitzung 11.06.2013

Referenz Aktivitätsdiagramm 3.3.2.1 “Bergführer bietet eine Tour an”

Im Prototyp ja nein


15.06.2013 0.1 NA Initial


AF-1050 Tour buchen

Beschreibung Das System muss es einem angemeldeten Benutzer mit der Rolle Berggänger ermöglichen eine Tour zu buchen.

Details Das System muss den Benutzer während des Buchungsvorgangs zur Eingabe folgender Informationen auffordern

Anzahl Teilnehmer

AND Name

AND Vorname

AND Wohnort

AND Kreditkarten Informationen AND das System muss dem Benutzer die Möglichkeit geben eine Dienstleistung zur Tour hinzuzufügen AND das System muss dem Benutzer am Schluss der Buchung den berechneten Gesamtpreis anzeigen AND das System muss den Gesamtpreis vom Benutzer bestätigen lassen AND direkt einen Zahlungsvorgang auslösen AND das System muss die Kreditkarten Informationen prüfen AND wenn die Kreditkarten Informationen ungültig sind, muss das System den Benutzer erneut zur Eingabe der Kreditkarten Informationen auffordern



AND das System muss den Gesamtpreis einer Buchung mit folgender Formel berechnen: Festpreis des Bergführers + (Anzahl Teilnehmer * Anzahl Nächte * Bettenpreis pro Nacht) AND WENN die Tour mehr als einen Tag dauert, muss das System die vorreservierten Betten buchen AND WENN die Anzahl Teilnehmer kleiner als die maximale Teilnehmerzahl ist, muss das System die übrigen, vorreservierten Betten wieder freigeben AND WENN durch die Buchung eine andere Tour zu wenig vorreservierte Betten mehr hat, muss das System die maximale Teilnehmerzahl der anderen Tour kürzen AND den Bergführer der anderen Tour informieren.

Regeln -

Kommentar -



Quelle Erarbeitetes Aktivitätsdiagramm aus Projektteamsitzung 11.06.2013

Referenz Aktivitätsdiagramm 3.3.2.2 “Berggänger bucht eine Tour”

Im Prototyp ja nein


15.06.2013 0.1 NA Initial


AF-1055 Buchungsbestätigung

Beschreibung Das System sollte dem Benutzer nach einer erfolgreich ausgeführten Buchung eine Buchungsbestätigung anzeigen.

Details Das System sollte auf der Buchungsbestätigung mindestens die folgenden Informationen aufführen:

Berg

Route



Bergführer

Startdatum und Startzeit

Enddatum und Endzeit

Anzahl Teilnehmer

Allfällige Berghütte

Anzahl gebuchte Betten

Anzahl Teilnehmer

Gesamtbetrag

Regeln -

Kommentar -



Quelle -

Referenz -

Im Prototyp ja nein


26.06.2013 0.1 II Initial

AF-1057 Angebotsbestätigung

Beschreibung Das System wird dem Benutzer nach einem erfolgreichen Angebot eine Angebotsbestätigung anzeigen.

Details Das System wird auf der Angebotsbestätigung eine Zusammenfassung der angebotenen Dienstleistungen auflisten.

Regeln -

Kommentar -





Quelle -

Referenz -

Im Prototyp ja nein


26.06.2013 0.1 II Initial

AF-1060 Bett anbieten

Beschreibung Das System muss einem angemeldeten Benutzer mit der Rolle Hüttenwart ermöglichen ein Bett in einer Berghütte anzubieten.

Details Das System muss den Benutzer zur Auswahl folgender Informationen auffordern

Berg

AND Route

AND Berghütte AND das System muss prüfen ob der Benutzer für die ausgewählte Berghütte berechtigt ist AND das System muss den Benutzer zur Eingabe folgender Informationen auffordern

Anzahl Betten

AND Preis pro Nacht In einem Bett kann nur eine Person schlafen.

Regeln -

Kommentar -




Referenz -

Im Prototyp ja nein




15.06.2013 0.1 NA Initial


AF-1070 Dienstleistung anbieten

Beschreibung Das System wird es einem angemeldeten Benutzer mit der Rolle Dienstleister ermöglichen, einen Dienst auf PYT anzubieten und zu verkaufen.

Details Das System wird es ermöglichen, weitere Dienstleistungen wie zum Beispiel die Folgenden anzubieten

Vermietung von Ausrüstungsgegenständen

Verkauf von Sportartikeln

Abschluss von Unfall- und Annullationskostenversicherung

Gemäss Projektauftrag soll das Anbieten solcher zusätzlichen Dienstleistungen nur oberflächlich erarbeitet werden. Deshalb wird auf eine detaillierte Ausarbeitung verzichtet.

Regeln -

Kommentar -




Referenz -

Im Prototyp ja nein


22.06.2013 0.1 NA Initial


AF-1080 Benachrichtigungen bei Statusänderungen

Beschreibung Das System wird bei Statusänderungen von Touren automatisch eine



Benachrichtigung per Email versenden.

Details Wenn eine Tour gebucht wurde, wird das System eine Benachrichtigung per Email an den Bergführer senden AND wenn einer Tour nicht mehr genügend vorreservierte Betten zur Verfügung stehen, wird das System eine Benachrichtigung per Email an den Bergführer senden AND wenn ein Bett seinen Status von vorreserviert auf gebucht ändert, wird das System eine Benachrichtigung per Email an den Hüttenwart senden

Regeln -

Kommentar -




Referenz -

Im Prototyp ja nein


15.06.2013 0.1 NA Initial


AF-1090 Tagesendverarbeitung

Beschreibung Das System wird zeitgesteuert jede Nacht um 02:00 Uhr eine Tagesendverarbeitung durchführen.

Details Das System wird die folgenden Aufgaben bei der Tagesendverarbeitung prüfen und durchführen

Falls Touren nicht mindestens 48h vor dem Startdatum und Startzeit gebucht sind, wird das System die betroffenen Touren stornieren AND das System wird dem betroffenen Bergführer eine Benachrichtigung per Email senden

AND wenn Betten zur betroffenen Tour vorreserviert sind, wird das System diese wieder freigeben AND das System wird dem betroffenen Hüttenwart eine Benachrichtigung per Email senden

Regeln -



Kommentar -




Referenz -

Im Prototyp ja nein


15.06.2013 0.1 NA Initial


AF-1100 Kreditkarten Informationen prüfen

Beschreibung Das System muss die vom Benutzer eingegebenen Kreditkarteninformationen auf ihre Gültigkeit prüfen.

Details -

Regeln -

Kommentar -




Referenz -

Im Prototyp ja nein


15.06.2013 0.1 NA Initial




3.4 Weitere Anforderungen

Absichtlich leer.

3.5 Nicht-Funktionale Anforderungen

3.5.1 Anforderungen an das Grafische User-Interface

AN-5010 Publikum

Beschreibung Das System muss über ein modernes und übersichtliches GUI verfügen.

Details Das System muss die Menüstruktur in maximal 2 Hierarchieebenen darstellen AND das System muss sinnvolle Piktogramme anstelle einer textuellen Beschreibung anzeigen

Regeln

Kommentar Die Applikation wird sowohl durch firmeninterne Benutzer als auch durch externe Anwender benutzt. Bedingt durch diesen breiten Benutzerkreis muss das System über ein modernes und übersichtliches GUI verfügen.



Quelle -

Referenz -

Im Prototyp ja nein


27.06.2013 0.1 II Überführung ins Raster

AN-5020 Corporate Design

Beschreibung Das System wird über eine Benutzeroberfläche verfügen, die sich an den Corporate Design Vorgaben von MegaSport orientiert

AND die erzeugten Schriftdokumente werden den Corporate Design Vorgaben für Kundendokumente von MegaSport entsprechen.



Details -

Regeln -

Kommentar -



Quelle -

Referenz Corporate Design Vorgaben von MegaSport

Im Prototyp ja nein



AN-5030 Mehrsprachigkeit

Beschreibung Das System wird nur in Deutsch realisiert.

Details -

Regeln -

Kommentar Vorerst wird keine Mehrsprachigkeit unterstützt.



Quelle -

Referenz -

Im Prototyp ja nein





3.5.1.1 Benutzbarkeit

AN-5100 Systemverständlichkeit

Beschreibung Das System wird für alle Funktionalitäten verständliche Bezeichnungen verwenden, welche die gebräuchlichen Bezeichnungen von MegaSport verwenden.

Details -

Regeln -

Kommentar -



Quelle -

Referenz -

Im Prototyp ja nein



AN-5110 Systembedienbarkeit

Beschreibung Die Webapplikation sollte sich bezüglich der Fensterdarstellung am Standard einer modernen Buchungsapplikation ausrichten. Die Fenster sollten in gebräuchlichen Darstellungen gestaltet werden, z.B. für die Kalender- und Menüauswahl.

Details -

Regeln -

Kommentar -



Quelle -



Referenz -

Im Prototyp ja nein



3.5.2 Zugriffsschutz- und Sicherheits-Anforderungen

3.5.2.1 Unauthorisierter Zugriff

Das System muss den unautorisierten Zugriff auf die Daten verhindern, soweit dies technisch möglich ist. Das System muss für anonyme Benutzer die Funktionalität so einschränken, dass diese nur Informationen über Berge, Routen und Berghütten (Berghütten nicht im Prototyp enthalten) abrufen können, aber keine Mutationen, Buchungen oder Datendownloads vornehmen können.

Das System muss weitergehende Funktionalitäten auf authentifizierten Benutzern gemäss ihrem Berechtigungsprofil einschränken.

3.5.2.2 Authentifizierung

Das System muss die Authentifizierung durch die Eingabe einer Benutzer-UID in Kombination mit einem Passwort durchführen. Das System muss die Anzahl Login-Versuche am gleichen Tag auf 10 beschränken, so dass keine Wörterbuch-Attacken durchgeführt werden können (nicht im Prototyp).

3.5.2.3 Rollenkonzept

3.5.2.3.1 Usergruppen

Das System muss dem Administrator die Möglichkeit bieten, User in verschiedene Rollen einteilen zu können. Es sollen folgende Rollen hinterlegt werden, zu denen dann die einzelnen User zugeordnet werden:

Administrator

Berggänger

Bergführer

Hüttenwart (nicht im Prototyp)

Anbieter weiterer Dienstleistungen (nicht im Prototyp)

In der folgenden Grafik ist aufgezeigt wie die Rollen voneinander erben:



Abbildung 7 – Rollenvererbung

3.5.2.3.2 Gruppenrechte

Das System muss dem Systemadministrator die Möglichkeit bieten, für die definierten Usergruppen jeweils die Berechtigungen pro Gruppe separat einzurichten. Dass System muss es ermöglichen, die Berechtigungen jeweils pro Hauptfunktion einstellen zu können. Die detaillierte Berechtigungsmatrix ist nicht Gegenstand dieser SRS.

3.5.2.3.3 Prüfung der Rechte

Das System muss vor der Ausführung einer Aktion prüfen, ob der angemeldete Benutzer über die notwendigen Berechtigungen für die Aktion verfügt. Falls er über ungenügende Rechte verfügt, muss das System eine entsprechende Meldung ausgeben und darf den gesperrten Vorgang nicht durchführen.

3.5.3 Performanz-Anforderungen

3.5.3.1 Effizienz

3.5.3.1.1 Zeitverhalten

Das System muss folgende maximalen Antwortzeiten sicherstellen:

80 % der Aktionen müssen innerhalb von 3 Sekunden Antwortzeit abgeschlossen sein

100 % der Aktionen müssen innerhalb von 5 Sekunden Antwortzeit abgeschlossen sein

3.5.3.1.2 Verbrauchsverhalten

Das System muss folgende Anforderungen an das Verbrauchsverhalten erfüllen:

Das System darf auf dem Webapplikationsserver maximal 4 GB RAM belegen

Die Prozessorauslastung auf einem Standard Web-Server (Intel i7) darf in der Spitze nicht mehr als 50 % betragen, im Ruhebetrieb nicht mehr als 2 %

Das System darf auf dem Server pro Buchung nicht mehr als 1 KB Daten speichern

Das System darf auf dem Server pro Monat nicht mehr als 50 MB Logfiles erzeugen

3.5.4 Design- und Implementations-Anforderungen

3.5.4.1 Zuverlässigkeit

3.5.4.1.1 Systemwiederherstellbarkeit

Das System muss nach Beendigung jeder Transaktion die Daten auf der Datenbank in einem konsistenten Zustand hinterlassen, der mittels Datenbank Backup und Restore in einem Notfall



wiederhergestellt werden kann. Die globalen Systemparameter müssen ebenfalls auf dieser Datenbank abgespeichert werden.

3.5.4.1.2 Systemreife

Der Reifegrad des Systems muss vor der Produktivsetzung durch ein Testprotokoll aller Hauptfunktionalitäten nachgewiesen werden.

3.5.4.1.3 Systemfehlertoleranz

Das System muss Benutzereingaben auf Plausibilität hinsichtlich der Datentypen und möglichen Wertebereiche prüfen. Fehleingaben dürfen in keinem Fall zum Programmstillstand oder –absturz führen, sondern müssen mit dem Benutzer mit einem Warnhinweis respektive einer Fehlermeldung angezeigt werden.

3.5.4.2 Systeminstallierbarkeit

Für die Installation des Clients muss eine Installationsanleitung erstellt werden. Die Serverinstallation auf einem Linux-Server muss durch einen zertifizierten Systemadministrator innerhalb von 4 Stunden erfolgen können.

3.5.4.3 Änderbarkeit

3.5.4.3.1 Analysierbarkeit

Alle Programmquelltexte müssen sauber strukturiert und ausreichend kommentiert sein, damit ein aussenstehender Programmierer sich innerhalb von 5 Arbeitstagen vollständig einlesen kann und alle wesentlichen Programmteile und Datenfelder versteht.

3.5.4.3.2 Stabilität

Das Laufzeitverhalten der Applikation muss so stabil sein, dass ein kompletter Testzyklus über alle wesentlichen Funktionen ohne Programmabsturz und Datenfehler durchgeführt werden kann. Im produktiven Betrieb darf höchstens 1 Mal pro Monat ein unvorhergesehener Programmstopp erfolgen.

3.5.4.3.3 Prüfbarkeit

Die Programmquelltexte müssen so verständlich und dokumentiert sein, dass sie im Bedarfsfall durch externe Auditoren innerhalb von 3 Arbeitstagen überprüft werden können.

3.5.5 Rechtliche Anforderungen

Es gilt das Schweizer Recht.

3.5.6 Lizenzen

Die Applikation wird speziell für MegaSport programmiert und ist ihr Eigentum. Es sind keine weiteren Lizenzen notwendig.

4 Projekt-Randbedingungen

4.1 Technische Randbedingungen

4.1.1 Betriebssystem



Das System muss als Webapplikation umgesetzt werden. Für die Betriebssystem-Anforderungen gilt folgendes:

Server

Das Betriebssystem muss den Betrieb eines JEE6-Full-Profile Applikationsserver unterstützen. In der Regel wird dafür ein Linux Server verwendet, ist aber nicht zwingende Voraussetzung.

Client

Für den Betrieb der Clients ist nur ein gängiger moderner Webbrowser erforderlich (Firefox, Chrome, Safari, Internet Explorer, Opera). Dies bedeutet, dass keine Einschränkungen bezüglich Betriebssystem für die Clients bestehen.

4.1.2 Datenbank-Engine

Für den Serverbetrieb ist eine Datenbank-Engine notwendig. Im echten Produktionsbetrieb wird MySQL verwendet. Für den Prototyp wird die In-Memory Datenbank Apache Derby genutzt.

4.2 Dokumentation

4.2.1 Benutzer-Dokumentation

Für das System muss eine Betriebsanleitung in deutscher Sprache geliefert werden.

4.2.2 System-Dokumentation

Es müssen folgende Dokumente erstellt und abgeliefert werden:

Beschreibung der Betriebsvoraussetzungen

Installationshandbuch

Installationsskripts für die Datenbank

Ausgewählte wichtige Analyse- und Design-Dokumente in UML

Datenkatalog

ER-Diagramm der Datenbank

4.3 Zeitplan

Die folgenden Meilensteine sind im Rahmen des BFH-Integrationsprojekts vorgegeben:

Abgabe SRS und Projektaudit 04.07.2013

Ablieferung aller Lieferergebnisse inklusive Prototyp

03.10.2013

Abschlusspräsentation 03.10.2013

Nachbesprechung 24.10.2013



4.3.1 Gantt-Chart

Das nachfolgende Gantt-Chart zeigt eine Übersicht der Projektplanung. Basis des Projektvorgehensmodells bildet das Hermes 5 Szenario „IT-Individualanwendung“.



Die Begründung der Wahl des Projektvorgehensmodell, sowie die detaillierte Beschreibung, wie weit die Hermes 5 Vorgaben im Rahmen von PYT angewendet werden, sind in der separaten Aktennotiz „2013-06-11_Wahl_des_Projektvorgehensmodells“ auf der Google Docs Ablage des Projektteams festgehalten und werden im Rahmen des Projekthandbuchs weiter ausgebaut. Diese Dokumente sind nicht Bestandteil des Lieferobjekts SRS, sondern werden am Schluss des Integrationsprojekts im Gesamtpaket mit allen Projektmanagementunterlagen abgegeben.

4.4 Kosten

Alle zu leistenden Arbeiten werden durch vier Studierende der Berner Fachhochschule im Rahmen ihres Integrationsprojekts geleistet. Die Berechnung der Kosten erfolgt wie folgt:

In der detaillierten Projektplanung wurden sämtliche Lieferobjekte definiert

Für jedes Lieferobjekt wurde eine zeitliche Aufwandschätzung in Stunden vorgenommen

Für die Kostenplanung wird die Aufwandschätzung in Stunden mit einem Kostensatz von CHF 50 pro Stunde multipliziert

Die folgende Tabelle zeigt einen Zusammenzug der Zeitaufwand- und Kostenschätzungen.

Hauptlieferobjekt Zeitliche Aufwandschätzung (in Stunden)

Daraus berechnete Kostenschätzung in CHF

Lastenheft und Auditpräsentation 53 2‘650

Unterlagen zu Projektmanagement und Testen

58 2‘900

OO-Analyse 31 1‘550

OO-Synthese 20 1‘000

OO-Design 25 1‘250

Prototyp 76 3‘800

Fertigstellung, Schlusspräsentation 20 1‘000

Teamsitzungen, Projektleitung 60 3‘000

Total 343 17‘150

Für die Systementwicklung und den Betrieb des Prototypen wird nur kostenfreie Open Source Software eingesetzt. Deshalb fallen keine Lizenzkosten an.

4.5 Datenschutz

Der Datenschutz muss mit einer Berechtigungssteuerung im System sichergestellt werden.

Öffentliche Daten

Die Basisdaten der Berge, die Routen sowie die pro Route angebotenen Dienstleistungen sind öffentlich und werden auch unregistrierten Benutzern als Suchergebnis, respektive Information angezeigt.

Schützenswerte Daten

Die Personendaten der registrierten Benutzer (Berggänger und Dienstleister) müssen mittels Berechtigungssteuerung geschützt werden. Nur der Administrator hat uneingeschränkten Zugang auf



alle im System vorhandenen Daten. Für die registrierten Berggänger und Dienstleister gilt das Prinzip, dass sie nur auf die jeweils für ihre Aktivität unmittelbar benötigten Daten Zugang haben dürfen.

4.6 Offene Punkte

Für spätere Versionen vorstellbar:

● Einführung weiterer Stati. So könnte z.B. ermöglicht werden, dass beim Buchungsvorgang nicht eine sofortige Zahlung erfolgen muss.

4.7 Lieferumfang

Es müssen dem Auftraggeber auf einem Datenträger in elektronischer Form folgende Ergebnisse abgeliefert werden:

lauffähiges Programm

Programm-Quelltexte

Dokumentation gemäss Kapitel 4.2

Ein Papierausdruck der Dokumente ist nicht notwendig.

Online-Bergtourenplanung - sws.bfh.ch · SRS Anforderungsspezifikation (Software Requirements...

Documents

Transcript of Online-Bergtourenplanung - sws.bfh.ch · SRS Anforderungsspezifikation (Software Requirements...