search

Lammer-FH / academy-boutique-hotel-technikum-2024-team-a

2024-ws-academy-academy-boutique-hotel-technikum-2024-Academy-Template-WEBF created by GitHub Classroom
0 stars 0 forks source link

readme

Review Assignment Due Date

Projekt: Hotel Buchungsoberfläche

Team A: Feher-Lehrner Maria Kogler Paul Stefanie Bäuchler Hofbauer Lisa

Kontext und Einordnung

Unser Team wurde beauftragt eine Buchungsapp zu entwickeln, die Benutzer auf dem Smartphone und dem Desktop verwenden werden. Es werden bis zu 100 Besucher pro Tag erwartet, d.h. die bestehende Infrastruktur reicht für die Performance anforderungen aus. Besonders Augenmerk, soll auf die moderne und nachhaltige Umsetzung der App gelegt werden, da diese in den kommenden Jahren mit weiteren Features erweitert werden soll. Wesentlich ist dem Auftraggeber auch ein roter Faden in der Usability und im Stylingkonzept.

Das Backend wurde bereits von unserem PhP Team umgesetzt und steht unter https://boutique-hotel.helmuth-lammer.at zur verfügung. Die Dokumentation findet sich in diesem Dokument.

Es besteht die Aufgabe eine Hotelbuchungsapp für das Boutique-Hotel Technikum umzusetzen. Dabei soll es den Gästen möglich sein Hotelzimmer für einen bestimmten Zeitraum zu buchen, wenn es die entsprechende Auslastung zulässt. Die Gäste können sich auch registrieren um für zukünftige ihre Personenangaben wiederzuverwenden oder Ihre Buchungen einzusehen.

Das Projekt wird mit Trainings (Lehreinheiten) begleitet, um eventuelle Knowhow lücken am Weg zum Projektziel zu schließen.

Technische Anforderungen

Die App soll mit vue-js (Version 3) umgesetzt werden und mithilfe des Frameworks vue-bootstrap (Oder gleichwertig) rasch umgesetzt werden. Die Library Axios soll für API Calls verwendet werden. Für ein modernes State-Handling wird Pinia zu verwenden sein.

Die Anwendung wird besonders für Mobile Endgeräte entwickelt, soll aber auch am Desktop bedienbar sein.

API Spezifikation

GET rooms

https://boutique-hotel.helmuth-lammer.at/api/v1/rooms

Example Result

  [
    { 
      "id": 1,
      "roomNumber":  11,
      "roomName": "Junior Suite",
      "beds": 3,
      "pricePerNight": 120,
      "extras": {
        "bathRoom": true,
        "minibar": true,
        "television": true,
        "aircondition": true
      }
    },
    {
     ...
    }
  ]

GET available rooms

https://boutique-hotel.helmuth-lammer.at/api/v1/room/{roomId}/from/{from-date}/to/{to-date}

Check availability

Example Call: https://boutique-hotel.helmuth-lammer.at/api/v1/room/2/from/2022-12-10/to/2022-12-14

Example Result

{
  "state": 200
}

POST book room

https://boutique-hotel.helmuth-lammer.at/api/v1/room/{roomId}/from/{from-date}/to/{to-date}

Book Room

Example Call: https://boutique-hotel.helmuth-lammer.at/api/v1/room/2/from/2022-12-10/to/2022-12-14

Data:

{
    "firstname": "Franz",
    "lastname": "Xaver",
    "email": "franz@example.com",
    "birthdate": "1999-10-04"
}

Example Result

{
  "id": 1234
}

POST register user

https://boutique-hotel.helmuth-lammer.at/api/v1/register

Zu übertragen


{
  "firstname": String,
  "lastname": String,
  "email": String,
  "username": String,
  "password": String
}

Example Result (reiner Text)

1|PzId1xtCY3myLtqLAfSNKBtMsppVBB08b2FMYhq5

GET user with bookings

https://boutique-hotel.helmuth-lammer.at/api/v1/user/

Authentication token mit übertragen: api/use

    Authorization: Bearer {token}
    Accept: Application/json
{
  "firstname": String,
  "lastname": String,
  "email": String,
  "birthdate": String (Format: YYYY-MM-DD),
  "username": String,
  "bookings": [
    {
      "roomId": Number,
      "startDate": Date,
      "endDate": Date
    },
    {
      ...
    }
  ]
}

GET bookings history

https://boutique-hotel.helmuth-lammer.at/api/v1/user/bookings

Voraussetzung: gültiger Token wurde im Header übertragen

    Authorization: Bearer {token}
    Accept: Application/json

Example Result

  [
  {
    "booking": {
      "id": 1234,
      "from": "YYYY-MM-DD",
      "to": "YYYY-MM-DD"
    },
    "room": {
      "id": 1,
      "roomNumber": 11,
      "roomName": "Junior Suite",
      "beds": 3,
      "pricePerNight": 120,
      "extras": {
        "bathRoom": true,
        "minibar": true,
        "television": true,
        "aircondition": true
      }
    }
  },
  {
    ...
  }
]

POST login as user

https://boutique-hotel.helmuth-lammer.at/api/v1/login

zu Übertrage

{
  "clientId": String (E-Mail Address),
  "secret": String (Passowrd)
}

Antwort ist ein JWT oder ein Fehler

Authentication Configuration

...
    header: {
        Authorization: Bearer <token>
        Accept: Applilcation/json
    }

TestLinks:

User Stories

U1: Hotelwebsite

Als Gast möchte ich in Form einer Website das Hotel präsentiert bekommen um mich darüber zu informieren.

Details

Die Single Page Application enthält neben den Funktionen zur Buchung und Verwaltung auch statische Seiten, die den Besucher einerseits einladen das Hotel genauer anzusehen und andererseits solche Informationen bereitstellen, dass der Besucher weiß, was ihn vor, während und nach erfolgreicher Buchung erwartet.

Recommended Approach

Definition of Done

U2: Hotelzimmer Auswahl

Als Gast möchte ich eine Übersicht über Hotelzimmer und die zugehörigen Details sehen können, um mir nach meinen Vorstellungen ein Zimmer auszusuchen.

Details

Es besteht eine API Schnittstelle über die Informationen zu den Zimmern abgerufen werden können. Diese ist in der API Dokumentation zu finden. Im Ordner images/rooms des Repositories finden sich Bilder. Die Dateinamen entsprechen der jeweiligen Zimmer id. Es kann sein, dass die Bilder nicht alle gleich groß sind. Finden Sie auch dafür eine Lösung. Zu den Extras sollen Aussagekräftige Icons gestellt werden, damit der Benutzer sich gut zurechtfindet. Es sollen beim ersten Laden maximal 5 Hotelzimmer angezeigt werden. Das heißt, es bedarf einer Lösung, wie man eine ungerade Zahl an Zimmern gut darstellt und wie man auf Seite 2 (und später evtl. 3 und 4 - ein Zubau von Zimmern ist für das kommende Jahr geplant) wechseln kann.

Recommended Approach

Definition of Done

U3: Verfügbarkeit prüfen

Als Gast möchte ich überprüfen ob ein bestimmtes Zimmer zum meinem gewünschten Reisezeitraum verfügbar ist, um festzustellen, ob ich das Zimmer werde buchen können.

Details

Es besteht eine API Schnittstelle über die Informationen zu den Zimmern abgerufen werden können. Diese ist in der API Dokumentation zu finden. Der Benutzer soll in der Oberfläche die Möglichkeit haben, seinen Buchungszeitraum zu definieren. Sie haben hier freie Hand, wie sie das dem Benutzer am besten darstellen. Denken Sie innovativ und out of the box dabei.

Recommended Approach

Definition of Done

U4: Hotelzimmer reservieren

Als Gast möchte ich zu einem ausgewählten Zeitraum ein ausgewähltes Zimmer buchen um eine Unterkunft in meinem Urlaub zu haben.

Details

Es besteht eine API Schnittstelle um eine Buchung zu einem Zimmer durchführen zu können. Diese ist in der API Dokumentation zu finden. Nachdem der Benutzer ein verfügbares Zimmer gefunden hat, soll er es Buchen können. Er muss dazu folgende Daten angeben:

Er soll vor dem endgültigen Absenden, nochmal die Möglichkeit haben, seine Buchungsdaten (inkl. Buchungszeitraum und Zimmerwahl) zu überprüfen und ggf. zu bearbeiten. Nach erfolgter Buchung muss dem Benutzer eine Bestätigung angezeigt werden.

Recommended Approach

Definition of Done

U5: Reservierungsbestätigung verbessern

Als Gast möchte ich nach der Buchung erfahren, ob diese erfolgreich oder fehlerhaft war um zu wissen ob ich meinen Prozess beenden kann, oder weitere Schritte nötig sind.

Details

Die in U4 angesprochene Buchungsbestätigung soll erweitert werden, um den Benutzer ausführlich über alle Details zu informieren und ihm die Anreise und das Einchecken zu erleichtern. Die Details der Buchung sollen anzeigt werden:

Recommended Approach

Important Comment

Diese Userstory markiert (wenn 1-4 auch erledigt sind) den ersten Milestone und damit ersten Release. Wir erreichen damit V1.0.0

Definition of Done

U6: Registrierung

Als Gast möchte ich mich registrieren können, damit ich meine Daten wieder verwenden kann und meine Buchungshistorie aufrufen kann.

Details

Es besteht eine API Schnittstelle um eine Registrierung durchführen zu können. Diese ist in der API Dokumentation zu finden. Der Benutzer soll, während, vor oder nach der Buchung die Möglichkeit haben sich zu registrieren. Dies ermöglicht es ihm in späterer Folge

Zur Registrierung benötigen wir folgende Daten

Er wird dadurch also ins Kundenregister aufgenommen. Für die Registrierung erhält er eine Bestätigung (Bildschirm Anzeige reicht. E-Mail nicht notwendig).

Recommended Approach

Definition of Done

U7: Login

Als registrierter Gast möchte ich mich am Portal anmelden können, damit ich bei einer erneuten Buchung, meine Daten nicht mehr eingeben muss und meine Buchungen anzeigen kann.

Details

Es besteht eine API Schnittstelle um sich anmelden zu können. Diese ist in der API Dokumentation zu finden. Sie erhalten von dieser Schnittstelle einen JWT, welcher ab dann bei jedem Request zu übertragen ist.

Dem Benutzer soll sichtbar gemacht werden, ob er angemeldet ist oder nicht.

Recommended Approach

Definition of Done

U8: Buchungs-Historie Anzeigen (Optional)

Als registrierter Gast möchte ich meine vergangenen und aktuellen Buchungen ansehen können, um einen Überblick zu haben, welche Zimmer ich früher hier gebucht hatte.

Details

Es besteht eine API Schnittstelle, um als autorisierter Benutzer Buchungen zu lesen. Diese ist in der API Dokumentation zu finden. Der Benutzer, wenn er angemeldet ist, soll eine Liste seiner vergangenen und aktuellen Buchungen sehen können. Dabei soll darauf geachtet werden, dass für den Benutzer klar ist, welche vergangen und welche zukünftig sind und welches Zimmer in welchem Zeitraum gebucht war.

Diese Userstory markiert (wenn 1-7 auch erledigt sind) den zweiten Milestone und damit den zweiten Release. Wir erreichen damit V2.0.0

Recommended Approach

Definition of Done

Milestones und Deadlines

Es sind drei Milestones definiert. Diese sind in der Tabelle unten beschrieben.

Milestone Tasks Deadline Peer Review
1 Paperprototype, U1 bis LE4 Ja
2 U2-U4 bis LE6 Ja
3 U5-U7 +1 Woche nach LV Ende Nein