1. Pflichtenheft

1.1. Projektteam

  • Gruber Lorenz (4AHITM)

  • Simon Ittensammer (4AHITM)

  • Simon Zweimüller (4AHITM)

1.2. Ausgangssituation

Die HTL Leonding ist eine HTL im oö. Zentralraum mit ca. 1000 Schülern und den Fachabteilungen Medientechnik, Informatik, Medizintechnik und Elektronik.

1.3. Istzustand

An der HTL in Leonding gibt es ein sogenanntes "RoboLab". Dieses kann von Schülern und Lehrern zum Arbeiten genutzt werden. Im RoboLab werden zahlreiche und unter anderem auch teure Werkzeuge und Materialien zur Verfügung gestellt.

1.4. Problemstellung

Da das RoboLab jederzeit von Personen in der HTL benutzt werden kann, kann es zu Fällen von Vandalismus und Diebstahl kommen. Durch die große Schüleranzahl weiß man nicht genau wer und wann das RoboLab betreten und verlassen hat.

1.5. Aufgabenstellung

1.5.1. Funktionale Anforderungen

Es ist ein Softwaresystem zu entwickeln, welches es ermöglicht Personen, die das RoboLab betreten und verlassen, zu sehen und zu protokollieren. Der User kann sich jederzeit am Rechner oder Smartphone die Livestreams seiner Kameras ansehen. Betritt eine Person das RoboLab, wird ein Foto oder ein kurzer Videoclip gespeichert. Wenn gewünscht, kann auch eine e-mail an den User gesendet werden. Diese gespeicherten Medien, kann sich der User jederzeit im Nachhinein ansehen. Auch ist es möglich seine Videostreams anzupassen. Es können Logos, Texte, die Uhrzeit usw. eingeblendet werden.

1.5.2. Nichtfunktionale Anforderungen

Das System soll unabhängig vom Typ der Kamera bzw. des Streams funktionieren. Auch soll es nutzerfreundlich und leicht zu bedienen sein. Ein Fehler bei der Übertragung des Videostreams soll keinesfalls das System zum Absturz und auch nicht zu Performanceproblemen führen.

1.6. Ziele

Vorbeugen bzw. Aufklären von Diebstahl und Vandalismus im RoboLab.

1.7. Mengengerüst

  • Für den Server an sich werden ca. 1,5-2 GB gebraucht werden.

  • Die Website an sich hat rund 15-20 MB.

  • Pro Videostream wird in der Datenbank eine Zeile angelegt. Die gebrauchten Daten sind daher nur einige kB groß.

  • Pro personalisiertem Element, welches kein Bild ist, wird eine Zeile in der DB angelegt. Das entspricht wiederum nur einigen kB.

  • Pro eingefügtem Bild wird ebenfalls eine Zeile angelegt. Das Bild an sich als Base64 String in der DB gespeichert und hat ca. 0,5-3 MB.

  • Pro gespeichertem Bild wird eine Zeile in der DB angelegt und das Bild am als Base64 String in der DB gespeichert. Das Bild hat ca. 3-5 MB.

  • Pro gespeichertem Video wird auch eine Zeile in der DB angelegt und das Video im Filesystem am Server gespeichert. Das Video hat eine größe von ca. 20 MB umfassen.

1.8. Rahmenbedingungen

Das System ist bis mitte Juni fertigzustellen. Bezüglich Technologien wurde nichts spezielles vom Auftraggeber vorgegeben.

2. Entwurf

2.1. Systemarchitektur

component diagram

2.2. Use-Case Diagramm

usecase diagram

Table 1. Use Cases
Use Case Beschreibung Ziel des UseCases Auslösendes Ereignis

View live video-stream

Anzeigen des Live-Bilds der ausgewählten Kamera

Beobachtung des Raumes, ohne anwesend sein zu müssen

Auswählen einer Kamera auf der Website

Configure overlay-objects

Hinzufügen von Text-, Bild- oder Zeit-Objekten welche im gewünschten Stream angezeigt werden

Personalisierung des Streams und Anzeigen von Informationen

 — 

Receive notification

Man erhält eine Nachricht auf Telegram mit einem aktuellen Bild des Streams

Der Benutzer soll benachrichtigt werden, ohne die Website aufrufen zu müssen

Erkennung einer Bewegung im Stream oder auf Anfrage des Benutzers

View recordings

Anzeigen von Bildern und kurzen Clips

Man soll vergangene Ereignisse nochmal ansehen können

Erkennung einer Bewegung im Stream

2.3. Design

design