Master Thesis Ressourcen-Reservations-System (RRS) für das Gymnasium Neufeld Bern. Software Requirements Specification

Transkript

1 Master Thesis Ressourcen-Reservations-System (RRS) für das Gymnasium Neufeld Bern Abstract: Das Gymnasium Neufeld Bern bildet ca. 850 Lernende in diversen gymnasialen Maturitätslehrgängen aus. Um den Unterricht optimal gestalten zu können, sollen in Zukunft Spezialräume, -einrichtungen und -geräte über ein web-basiertes Ressourcen-Reservations- System (RRS) reserviert werden können. Keywords: Web-basierte Applikation, Java EE, GlassFish, Typo3, Integration Student: Klasse: Betreuer FH Bern: Markus Jordi Klaraweg 19 CH Bern MAS Stephan Fischli Berner Fachhochschule Wankdorffeldstr Bern Experte: Betreuer Betrieb: Thesis-Nr. MAS Version: 1.32 Status Genehmigt Datum: Rolf Lanz Berner Fachhochschule Wankdorffeldstr Bern Rolf Maurer Gymnasium Neufeld Bern Bremgartenstr Bern

2 Inhalt 1 ALLGEMEINES Sinn und Zweck Leserkreis Umfang und Anwendungsgebiet, Einsatzgebiet Vorgesehene Erweiterungen Definitionen und Abkürzungen Referenzen / Literaturverzeichnis ALLGEMEINE BESCHREIBUNG Übersicht Ausgangssituation Absicht Nutzen Abgrenzung des Umfeldes Beziehungen zu anderen Systemen Hardware Software Übersicht der Funktionen Benutzereigenschaften TECHNISCHE ANFORDERUNGEN Allgemeine Funktionen Installation System Setup Schulung Hilfesystem System-Start und System-Shutdown Verhalten bei Power-Fail Simulatoren, Testeinrichtungen Sprachen Detaillierte Funktionsbeschreibungen Modus 1: Standard-Benutzer Modus 2: Administrator Übersicht über Modi, Funktionen und Prioritäten Meldungen DATENBASIS EXTERNE SCHNITTSTELLEN Benutzeroberfläche Modus 1: Standard-Benutzer Modus 2: Administrator 23 2

3 5.2 Hardwareschnittstellen Java EE Host Web-Host Client Softwareschnittstellen Java EE Host Web-Host Client 25 6 LEISTUNGSANFORDERUNGEN KONTROLLFUNKTIONEN Fehlerprotokollierung ADAPTIONEN Java EE Host Clients SUPPORT UND WARTUNG TESTEN DER APPLIKATION Teststrategien Reviews Usability-Tests Unit-Tests System-Tests & Abnahme-Tests Testwerkzeuge Akzeptanzkriterien Testumgebungen Testausführung Reviews Usability-Tests Unit-Tests, System-Tests und Abnahme-Tests 29 3

4 1 Allgemeines 1.1 Sinn und Zweck Die vorliegende (SRS) hat zum Ziel, die Anforderungen an das zu erstellende Ressourcen-Reservations-System (RRS) zu beschreiben. Sie bildet die Grundlage für die Leistungsvereinbarung zwischen dem Auftraggeber Gymnasium Neufeld Bern, vertreten durch Herrn Rolf Maurer (Rektor) und dem internen Auftragnehmer Markus Jordi. Da das RRS im Rahmen der Master Thesis zum "Master of Advanced Studies in Information Technology" erstellt wird, bildet die SRS zudem die Leistungsvereinbarung zwischen der Berner Fachhochschule und Markus Jordi als Diplomanden. 1.2 Leserkreis Das Dokument richtet sich einerseits an das interne, projektbegleitende Team des Gymnasiums Neufeld Bern, sowie an den technischen Betreuer Dr. Stephan Fischli (FH Bern), den Experten Rolf Lanz (FH Bern) und Markus Jordi als Auftragnehmer / Diplomanden. Das Dokument ist in allgemein verständlicher Sprache abgefasst, so dass sowohl nur wenige fachliche, als auch technische Vorkenntnisse zu dessen Verständnis notwendig sind. Die verwendeten Schlüsselwörter und Abkürzungen sind im Kapitel "1.5 Definitionen und Abkürzungen" im Sinne eines Glossars zum Nachschlagen zusammengestellt. 1.3 Umfang und Anwendungsgebiet, Einsatzgebiet Das Gymnasium Neufeld Bern bildet ca. 850 Schülerinnen und Schüler in diversen gymnasialen Maturitätslehrgängen aus. Die Lehraufträge werden durch ca. 130 Lehrkräfte wahrgenommen. Dazu kommen ca. 30 Angestellte ohne Lehrauftrag, wie Assistenten und Assistentinnen, Rektoratsassistentinnen etc. Um den Unterricht optimal gestalten zu können, stehen neben den Standardräumen auch Spezialräume, -einrichtungen und -geräte zur Verfügung. Diese Ressourcen sollen in Zukunft über ein elektronisches Ressourcen-Reservations-System reserviert werden können. Die Reservationen sollen durch die Lehrpersonen und Angestellten über das Internet online vorgenommen, geändert und gelöscht werden können. 1.4 Vorgesehene Erweiterungen Die funktionalen Anforderungen sind im Kapitel "3.2 Detaillierte Funktionsbeschreibungen" zusammengestellt und nach den Prioritäten P1 bis P3 klassiert. P1 entspricht dabei der höchsten Priorität, d.h. so genannten "Muss"-Anforderungen, welche unter allen Umständen im Lieferumfang enthalten sein müssen. P2 entspricht mittlerer Priorität, d.h. so genannten "Soll"-Anforderungen, welche nach Möglichkeit (= bei ausreichendem (Zeit-)Budget) im Lieferumfang enthalten sein sollen. P3 schlussendlich entspricht der tiefsten Priorität, d.h. so genannten "Kann"- Anforderungen, welche allenfalls (= bei immer noch ausreichendem (Zeit-)Budget) auch noch im Lieferumfang enthalten sein können. Sämtliche in der Lieferung nicht enthaltenen, aber in dieser SRS beschriebenen Funktionen mit der Priorität P2 und P3 (siehe Kapitel 3.2) sind als mögliche Programmerweiterungen für zukünftige Entwicklungsschritte zu verstehen. 1.5 Definitionen und Abkürzungen Folgende Fachausdrücke und Abkürzungen werden in dieser SRS verwendet und sollen an dieser Stelle im Sinne eines Glossars definiert werden: Ausdruck / Abkürzung Administrator Anlass Anwendungsfall Definition Systemverwalter; Verwaltet Benutzer, Ressourcen, Semester, Reservationen, Drucke Während einer Reservation in bzw. mit der Ressource durchgeführte Veranstaltung engl. "Use Case"; Beschreibung der Interaktion mit einem System 4

5 Ausdruck / Abkürzung Belegungsplan Betriebssystem Blackbox-Test Client CMS Datenbankschema Einzel-Reservation Entität Fehlerprotokollierung Ferien Gültigkeitsbereich GUI-Prototyp Hardware Hosting IDE Input Integrität Klasse Komponente Konsistenz Modul Modus 1 Modus 2 Output P1 P2 P3 Parallelität Persistierung Power-Fail Provider Definition anhand eines zusammenhängenden Arbeitsablaufs Plan, welcher die zeitliche Belegung einer Ressource wiedergibt. Software, welche als Bindeglied zwischen der Hardware und den Anwendungen/Applikationen dient Tests, welche ohne Kenntnis des Programmcodes durchgeführt werden Ein Client kann einen Dienst bei einem Server anfordern, der diesen Dienst bereitstellt Content Management System; System zur Verwaltung von Inhalten z.b. einer Website Legt bei RDBMS die Tabellen und deren Attribute sowie die Integritätsbedingungen zur Sicherstellung der Konsistenz fest Reservation für einen einmaligen Anlass. Kann keine anderen Reservationen überschreiben, d.h. hat tiefste Belegungs-Priorität Eindeutig bestimmtes Objekt, welches Informationen speichert Aufzeichnung von Fehlern in einer Datei Unterrichtsfreie Zeit Bereich von Werten, innerhalb dessen ein Übergabewert oder ein Resultat gültig ist engl. "Graphical User Interface"; Prototyp der Benutzer- Schnittstelle Computerbestandteile, welche eine physikalische Ausprägung haben, d.h. angefasst werden können Übernahme von Installation und Betrieb einer Website auf einer Serverinfrastruktur engl. "Integrated Development Environment"; Integrierte Entwicklungsumgebung; Programm zur Entwicklung von Software Eingabewert eines Computerprogramms Einhaltung von Bedingungen, welche an die Daten eines RDBMS gestellt werden (Wertebereich, Abhängigkeiten, ) 1. Feste Gruppe von Schülern, mit gemeinsamem Unterricht 2. Programmeinheit in objektorientierten Programmiersprachen Bestandteil eines Softwaresystems; Grösser als Modul Widerspruchsfreiheit von Daten in einem RDBMS Baustein eines Softwaresystems; Kleiner als Komponente Programm-Modus für Standard-Benutzer Programm-Modus für Administrator Ausgabewert eines Computerprogramms Priorität 1; Höchste Priorität; entspricht "MUSS" Priorität 2; Mittlere Priorität; entspricht "SOLL" Priorität 3; Niedrige Priorität; entspricht "KANN" Umstand, dass mehrere Vorgänge (quasi) gleichzeitig, aber unabhängig voneinander stattfinden Dauerhafte Speicherung von Daten Stromausfall Anbieter von (Internet-)Dienstleistungen 5

6 Ausdruck / Abkürzung RDBMS Ressource Review RRS Semester Semester-Belegungsplan Semesterferien Semester-Reservation Server Software SRS Standard-Benutzer Stundenplan Szenario TCP/IP Trace Transaktion Transaktionsmanagement Typo3 Usability Use Case USV Web-Browser Webcontainer Webserver Website Whitebox-Test Windows Server Definition Relational Database Management System Materielles Gut, um einen Vorgang ablaufen zu lassen; Materielle Güter (Räume, Geräte, ) welche im RRS reserviert werden können Manuelle Überprüfung von Arbeitsergebnissen Ressourcen-Reservations-System Studienhalbjahr Belegungsplan mit Reservationen, welche sich während eines Semesters wöchentlich wiederholen. Enthält die Semester- Reservationen Unterrichtsfreie Zeit zwischen zwei Semestern Reservation, welche sich während einem Semester wöchentlich wiederholt. Erscheint im Semester-Belegungsplan. Computerprogramm, welches Dienste für Clients bereitstellt. Die Dienste können durch die Clients angefordert werden. Nichtphysische Funktionsbestandteile eines Computers Pflichtenheft () Normaler Benutzer; In der Regel Lehrperson oder Angestellte/r Regelt die gemeinsamen Termine von Lehrkraft und Lernenden zwecks Unterricht örtlich und zeitlich Konkrete Ausprägung eines Anwendungsfalls mit spezifischen Randbedingungen und entsprechenden erwarteten Resultaten Netzwerkprotokoll mit grosser Bedeutung für das Internet; Auch "Internetprotokoll" genannt Fehlerprotokollierung Feste Folge von Operationen, welche als eine logische Einheit betrachtet werden und entweder als Ganzes akzeptiert oder verworfen werden Verwaltung von Transaktionen zur Sicherstellung von Konsistenz und Integrität der Daten Content Management System, mit welchem die Website des Gymnasiums Neufeld entwickelt wurde und gepflegt wird Benutzerfreundlichkeit Siehe "Anwendungsfall" Unterbrechungsfreie Stromversorgung Computerprogramm zum Betrachten von Websites im World Wide Web Software zur Generierung von HTML-Dokumenten aus dynamischen Webpages Software, welche HTML-Dokumente an einen Web-Browser überträgt Projekt im World Wide Web, welches meist aus mehreren Webseiten und einer Navigationshierarchie besteht Tests, welche unter Kenntnis des Programmcodes durchgeführt werden Server Betriebssystem von Microsoft 6

7 1.6 Referenzen / Literaturverzeichnis Folgende Dokumente dienten als Grundlage für die Erstellung der vorliegenden SRS oder werden innerhalb der SRS referenziert: 1. The Institute of Electrical and Electronics Engineers, Inc. IEEE Recommended Practice for (IEEE Std ). New York, USA : IEEE, ISBN Bürgi, Othmar (Info Top AG). Hilfsmittel zur Erstellung von Technischen Lastenheften mit speziellem Augenmerk auf Software-Anforderungen. CH Scharans : Info Top AG, Version Allgemeine Beschreibung 2.1 Übersicht Ausgangssituation Das Gymnasium Neufeld Bern bildet ca. 850 Lernende in diversen gymnasialen Maturitätslehrgängen aus. Zur Unterstützung der Lehrpersonen stehen Ressourcen wie Spezialräume (Informatik, Aula, ), Notebook-, Beamer- und Video-Wagen zur Verfügung. Diese sind z.t. für eine Klasse bzw. eine Lehrperson während eines ganzen Semesters fest reserviert. In der übrigen Zeit, d.h. ausserhalb der festen Reservationen können z.zt. die erwähnten Ressourcen im Lehrpersonenarbeitsraum in einer Papieragenda reserviert werden. Dieses veraltete und rudimentäre Vorgehen zur Reservation von Ressourcen hat grosse Nachteile. Einerseits sind die Lehrpersonen verpflichtet, Reservationen im Lehrpersonenarbeitsraum vorzunehmen, andererseits ist nur an diesem Ort ersichtlich, ob Ressourcen für eine bestimmte Zeitspanne ausserhalb der fest im Belegungsplan vorgenommenen Reservationen noch verfügbar sind. Das in Auftrag gegebene Ressourcen-Reservations-System soll diese Nachteile möglichst eliminieren und die Eingabe von Reservationen bzw. die Überprüfung von Reservationsmöglichkeiten von der örtlichen Bindung an den Lehrpersonenarbeitsraum befreien Absicht Um den Unterricht optimal gestalten zu können, sollen in Zukunft Spezialräume, -einrichtungen und -geräte über ein web-basiertes Ressourcen-Reservations-System (RRS) reserviert werden können. Diese Lösung erlaubt den Lehrpersonen und Angestellten örtlich und zeitlich unabhängig auf das Ressourcen-Reservations-System zuzugreifen und Reservationen vorzunehmen oder schon getätigte Reservationen zu ändern bzw. zu annullieren. Zusätzlich sollen administrative Arbeiten, wie Benutzerverwaltung, Ressourcenverwaltung, Semesterverwaltung, Verwaltung von Semester- und Spezialreservationen, Drucken von Semester- und Wochen-Stundenplänen pro verwaltete Ressource, etc. über dasselbe webbasierte System erledigt werden können Nutzen Der hauptsächliche Nutzen der zu erstellenden Software besteht darin, dass Lehrpersonen und Angestellte Informationen über den Reservationsstand der verwalteten Ressourcen unabhängig vom Aufenthaltsort einsehen und Reservationen tätigen können. Dies stellt eine wesentliche Verbesserung gegenüber den zurzeit im Lehrpersonenarbeitsraum für Reservationen zur Verfügung gestellten Papieragenden dar Abgrenzung des Umfeldes Das Ressourcen-Reservations-System soll in die bestehende Website des Gymnasiums Neufeld Bern integriert werden, welche demzufolge als übergeordnetes System funktioniert. Die Website des Gymnasiums Neufeld wurde mit dem Content Management System (CMS) Typo3 erstellt und 7

8 wird damit auch weiterentwickelt und inhaltlich gepflegt. Die Benutzer-Schnittstellen des RRS müssen sich aufgrund dieser Ausgangslage ins CMS integrieren lassen. 2.2 Beziehungen zu anderen Systemen Das Ressourcen-Reservations-System hat folgende Beziehungen zu anderen Systemen: a. Integration in die bestehende Website des Gymnasiums Neufeld. Das Hosting der Website wird durch einen externen Partner wahrgenommen. Folgende Produkte kommen zum Einsatz: Windows Server Plattform mit Apache-Webserver und integriertem Webcontainer (Tomcat); Relationale Datenbank MySQL; CMS Typo3, basierend auf der Skriptsprache PHP. b. Das RRS wird auf einem über das Internet erreichbaren Rechner entwickelt und installiert. Dieser Rechner wird als Windows Server Plattform mit einem Web- oder bei Bedarf Applikationsserver betrieben. Zudem kommt die Relationale Datenbank MySQL zum Einsatz. c. Die Client-Rechner der Benutzer des RRS werden unter Windows, MacOS oder Linux betrieben. Die Benutzerschnittstelle zum RRS wird durch einen Webbrowser sichergestellt. Folgende Abbildung gibt die oben beschriebenen Beziehungen wieder: Abb. 1: Beziehungen zu andern Systemen 2.3 Hardware Das Ressourcen-Reservations-System kann auf derselben Hardware entwickelt werden, auf welcher es schlussendlich auch produktiv eingesetzt wird. Es handelt sich dabei um einen IBM eserver mit einem mit 3.4 GHz getakteten Intel Xeon Double Core Prozessor und 2Gb RAM Die Verbindung zum Internet erfolgt über eine 1Gbit/s Netzwerkkarte. Das Gymnasium Neufeld ist über das Mittelschulnetzwerk MANSekII ans Internet angebunden. Die Bandbreite des Internet- Anschlusses ist nicht genau bekannt, dürfte aber für das RRS sicher genügen. 2.4 Software Das RRS wird mit folgender Software entwickelt und danach auf dem Entwicklungsgerät (siehe Kapitel 2.4) auch produktiv betrieben: Betriebssystem: Windows Server 2003 Laufzeitumgebung: Java EE 5 Webserver/Applikationsserver: Sun Glassfish V2 Webcontainer: Apache Tomcat V6 Relationale Datenbank: MySQL V5 Als Entwicklungsumgebung wird Netbeans V6 verwendet 8

9 2.5 Übersicht der Funktionen Die funktionalen Anforderungen werden aufgeteilt nach Programm Modus. Modus 1 steht für alle Funktionalen Anforderungen des Standard-Benutzers. Modus 2 steht entsprechend für die funktionalen Anforderungen des Administrators. Die detaillierte Beschreibung der funktionalen Anforderungen findet sich im Kapitel "3.2 Detaillierte Funktionsbeschreibungen". Modus 1: Der Standard-Benutzer muss folgende Kategorien von Funktionalitäten zur Verfügung haben: Verwalten von eigenen Einzel-Reservationen, d.h. Reservationen für einen einmaligen Anlass. Einzel-Reservationen eines Standard-Benutzers können Semester-Reservationen (siehe Modus 2) und schon vorhandene Einzel-Reservationen von andern Standard- Benutzern nicht überschreiben. Anzeigen von Wochen- Belegungsplänen einer dem System bekannten Ressource. Modus 2: Der Administrator muss folgende Kategorien von Funktionalitäten zur Verfügung haben: Benutzerverwaltung; Das RRS wird mit einer eigenen, einfachen Benutzerverwaltung ausgestattet. Eine spätere Authentisierung über das Active Directory des Gymnasiums Neufeld ist geplant und muss in Entwicklung und Implementation von Beginn weg berücksichtigt werden. Ressourcenverwaltung, d.h. Verwaltung sämtlicher Räume und Einrichtungen, welche über das RRS reserviert werden können. Semesterverwaltung, d.h. Definition von Unterrichts-Semestern, während welchen Reservationen vorgenommen werden können. Verwaltung von Semester-Reservationen, d.h. Reservationen, welche sich während eines Semesters wöchentlich wiederholen. Verwaltung von Einzel-Reservationen für Standard-Benutzer oder, dem System unbekannte Personen; Diese Einzel-Reservationen können Semester-Reservationen überschreiben (z.b. während Woche mit Spezialstundenplan etc.). Drucken von verschiedenen Belegungsplänen. Nachfolgend werden die funktionalen Anforderungen der beiden Modi zum besseren Verständnis grafisch illustriert. Eine Farbe bedeutet dabei eine zusammengehörende Gruppe von Funktionalitäten (z.b. Ressourcenverwaltung, etc.): Abb. 2: Funktionale Anforderungen für Standard-Benutzer (Modus 1) 9

10 Abb. 3: Funktionale Anforderungen für den Administrator (Modus 2) 2.6 Benutzereigenschaften Die Anwendung wird von zwei verschiedenen Benutzertypen verwendet, welche das RRS je in einem eigenen Modus verwenden. a. Standard-Benutzer (Modus 1): Der Standard-Benutzer ist typischerweise eine Lehrperson oder eine Angestellte / ein Angestellter. Die Kenntnisse in der Informatik sind unterschiedlich, es kann aber davon ausgegangen werden, dass der Standard-Benutzer mit dem Browsen im Web einigermassen vertraut ist. Ebenso ist der Versand und Empfang von -nachrichten für diesen Benutzer mehr oder weniger Routinearbeit. b. Administrator (Modus 2): Der Administrator ist eine Person, welche sehr gute Kenntnisse in der Informatik, wenn möglich sogar in der Administration von Software aufweist. Er ist sich der Risiken und Gefahren seiner Arbeit bewusst. Er wird deshalb z.b. die Datensicherheit mittels täglichen Backups massiv zu erhöhen wissen. 10

11 3 Technische Anforderungen 3.1 Allgemeine Funktionen Installation Das Ressourcen-Reservations-System wird durch den Auftragnehmer auf dem Zielsystem installiert. Allfällige Updates und Erweiterungen werden ebenso durch den Auftragnehmer installiert. Die Installation kann vor Ort oder über eine (sichere) Netzwerkverbindung geschehen System Setup Vor der Installation des RRS muss auf dem Zielsystem die Laufzeitumgebung installiert und konfiguriert werden. Diese umfasst den Applikationsserver, sowie die relationale Datenbank. Diese Arbeiten werden durch den Auftragnehmer ausgeführt Schulung Die als Standard-Benutzer erfassten Lehrpersonen und Angestellten werden durch den Auftragnehmer bei Bedarf für die Benutzung des RRS geschult. Diese Schulung gehört nicht zum Leistungsumfang des aktuellen Auftrages. Der Administrator muss in nächster Zeit nicht geschult werden, da die Funktion nach Auslieferung des RRS vorderhand durch den Auftragnehmer des aktuellen Auftrags und somit Entwickler des RRS (Markus Jordi) wahrgenommen wird Hilfesystem Da das RRS web-basiert implementiert wird und die dem Standard-Benutzer zur Verfügung gestellten Funktionalitäten nicht sehr umfangreich sind, kann aus heutiger Sicht auf ein umfangreiches Hilfesystem verzichtet werden. An dessen Stelle wir während der unter erwähnten Schulung eine kurze Dokumentation über das RRS abgegeben. Diese Dokumentation kann im RRS online verfügbar gemacht werden. Das Verfassen der Dokumentation gehört nicht zum Leistungsumfang des aktuellen Auftrages System-Start und System-Shutdown Das Zielsystem muss so konfiguriert werden, dass es bei einem System-Shutdown korrekt, d.h. ohne Datenverlust beendet wird. Der Applikationsserver und die Relationale Datenbank müssen aus diesem Grund vor dem System-Shutdown beendet werden. Beim System-Start ist darauf zu achten, dass sowohl der Applikationsserver, als auch die relationale Datenbank automatisch starten und das RRS somit automatisch in Betriebsbereitschaft versetzt werden Verhalten bei Power-Fail Das Zielsystem des Gymnasiums Neufeld ist mit einer so genannten unterbrechungsfreien Stromversorgung (USV) vor Stromausfall geschützt. Die USV stellt die Überbrückung eines kurzen Stromunterbruchs sicher. Sollte die Stromversorgung nicht innerhalb der maximal möglichen Überbrückungszeit wieder sichergestellt sein, so wird das Zielsystem einen System-Shutdown gemäss Kapitel durchführen. Sobald nach dem System-Shutdown die Stromversorgung wieder sichergestellt ist, wird das Zielsystem einen System-Start gemäss Kapitel ausführen. Diese Massnahmen genügen zur Sicherstellung der Datensicherheit und integrität im Falle eines Power-Fails Simulatoren, Testeinrichtungen Da das RRS direkt auf dem Zielsystem entwickelt werden kann, ist keine Simulation der Zielumgebung notwendig. Aus dem gleichen Grund kann das Zielsystem direkt als Testumgebung verwendet werden. 11

12 3.1.8 Sprachen Das Ressourcen-Reservations-System wird in deutscher Sprache implementiert und ausgeliefert. Allerdings wird Mehrsprachigkeit während der Entwicklung und der Implementation vorgesehen, so dass zusätzliche Sprachversionen später auf einfache Art und Weise hinzugefügt werden können. 3.2 Detaillierte Funktionsbeschreibungen Die funktionalen Anforderungen werden aufgeteilt nach Programm Modus. Modus 1 steht für alle Funktionalen Anforderungen des Standard-Benutzers. Modus 2 steht entsprechend für die funktionalen Anforderungen des Administrators. Die funktionalen Anforderungen werden zudem nach Priorität klassiert. P1 entspricht dabei der höchsten Priorität, d.h. so genannten "Muss"-Anforderungen, welche unter allen Umständen im Lieferumfang enthalten sein müssen. P2 entspricht mittlerer Priorität, d.h. so genannten "Soll"- Anforderungen, welche nach Möglichkeit (= bei ausreichendem (Zeit-)Budget) im Lieferumfang enthalten sein sollen. P3 schlussendlich entspricht der tiefsten Priorität, d.h. so genannten "Kann"- Anforderungen, welche allenfalls (= bei immer noch ausreichendem (Zeit-)Budget) auch noch im Lieferumfang enthalten sein können Modus 1: Standard-Benutzer Sämtliche Lehrpersonen und Angestellte des Gymnasiums Neufeld sind Standard-Benutzer, fortan auch einfach Benutzer genannt, des Ressourcen-Reservations-Systems. F101 Benutzerkennung (P1) Das RRS muss dem Standard-Benutzer die Möglichkeit bieten, sich mit einer Benutzerkennung und einem Passwort am System an- und nach Abschluss der Arbeit wieder abzumelden. F102 Erfassen einer neuen Einzel-Reservation (P1) Falls der Benutzer angemeldet ist, muss das RRS die Möglichkeit bieten, eine dem System bekannte Ressource einmalig zu reservieren. Folgende Informationen müssen pro Reservation erfasst werden: a) Ressource, für welche die Reservation vorgenommen wird b) Semester, in welchem die Reservation zeitlich liegt (Defaultwert = "aktuelles Semester", während Semesterferien "nächstes Semester") c) Kalenderwoche, Wochentag und erste Lektion der Reservation (muss innerhalb des gewählten Semesters liegen) d) Gewünschte Dauer der Einzel-Reservation (Defaultwert = "1 Lektion"; Maximalwert entspricht der Dauer bis zur nächsten bestehenden Reservation, beziehungsweise bis zur letzten Lektion des gewählten Tages, falls keine nachfolgenden Reservationen für diesen Tag mehr bestehen; Reservationseinheit = Lektion) e) Anlass für welchen die Reservation vorgenommen wird (entweder unterrichtetes Fach oder Anlass wie "Lehrerkonferenz", "Orchesterprobe", "Workshop", etc.) f) Klasse, für welche die Reservation vorgenommen wird; Spezialeintrag falls keine Klasse g) Benutzer, welcher die Reservation vornimmt, inkl. -adresse für Rückfragen h) Kommentar zur Reservation (fakultativ) Falls sich die gewünschte Reservation für die gewählte Ressource mit einer Semester-Reservation oder einer früher getätigten Einzel-Reservation zeitlich überschneidet, muss das RRS die Aufnahme der neuen Einzel-Reservation im System verhindern. F103 Ändern einer bestehenden Einzel-Reservation (P3) Falls der Benutzer angemeldet ist, der Beginn der betroffenen Einzel-Reservation in der Zukunft liegt und die Reservation durch den Benutzer eingegeben wurde, muss das RRS die Möglichkeit bieten, die Reservation zu ändern. Folgende Änderungen müssen möglich sein: a) Kalenderwoche, Wochentag und erste Lektion der Reservation (muss innerhalb des bei der Erfassung gewählten Semesters liegen) b) Gewünschte Dauer der Einzel-Reservation (Defaultwert = "1 Lektion"; Maximalwert entspricht der Dauer bis zur nächsten bestehenden Reservation, beziehungsweise bis zur 12

13 letzten Lektion des gewählten Tages, falls keine nachfolgenden Reservationen für diesen Tag mehr bestehen; Reservationseinheit = Lektion) c) Anlass für welchen die Reservation vorgenommen wird (entweder unterrichtetes Fach oder Anlass wie "Lehrerkonferenz", "Orchesterprobe", "Workshop", etc.) d) Klasse, für welche die Reservation vorgenommen wird; Spezialeintrag falls keine Klasse e) Kommentar zur Reservation Falls sich die Änderung der Einzel-Reservation mit einer Semester-Reservation oder einer andern Einzel-Reservation zeitlich überschneidet, muss das RRS die Änderung der Einzel-Reservation verhindern. F104 Annullieren einer bestehenden Einzel-Reservation (P1) Falls der Benutzer angemeldet ist, der Beginn der betroffenen Einzel-Reservation in der Zukunft liegt und die Reservation durch den Benutzer eingegeben wurde, muss das RRS die Möglichkeit bieten, die Reservation zu annullieren und damit die Ressource für das reservierte Zeitfenster wieder freizugeben. F105 Anzeigen eines Wochen-Belegungsplans für eine Ressource (P1) Falls der Benutzer angemeldet ist, muss ihm das RRS die Möglichkeit bieten, in der Zukunft liegende Semester- und Einzel-Reservationen für eine bestimmte, dem System bekannte Ressource und eine, durch den Benutzer bestimmte, Kalenderwoche anzuzeigen. Folgende Informationen müssen angezeigt werden: a) Datum, Wochentag, erste Lektion und Dauer sämtlicher Reservationen innerhalb der gewählten Kalenderwoche b) Für sämtliche Reservationen: Klasse, für welche die Reservation vorgenommen wurde c) Für sämtliche Einzel-Reservationen: Kürzel der Person, welche die Ressource reserviert hat inkl. -adresse für Rückfragen. Für dem System nicht bekannte Personen werden der Name und der Vorname anstelle des Kürzels angezeigt. d) Für Semester-Reservationen: Kürzel der Lehrperson, welcher die Ressource zugeteilt wurde, inkl. -adresse für Rückfragen e) Für sämtliche Reservationen, falls vorhanden: Kommentar zur Reservation F106 Anzeigen von Einzel-Reservationen eines Benutzers (P1) Falls der Benutzer angemeldet ist, muss ihm das RRS die Möglichkeit bieten, durch ihn getätigte und in der Zukunft liegende Einzel-Reservationen für alle, dem System bekannten Ressourcen anzuzeigen. Folgende Informationen müssen angezeigt werden: a) Datum, Kalenderwoche, Wochentag, erste Lektion und Dauer jeder Reservation b) Klasse, für welche die Reservation vorgenommen wurde c) Kommentar zur Reservation Modus 2: Administrator Der Administrator ist ein spezieller Benutzer des Ressourcen-Reservations-Systems, welcher administrative Aufgaben wahrnehmen kann. F201 Benutzerkennung (P1) Das RRS muss dem Administrator die Möglichkeit bieten, sich mit einer Benutzerkennung und einem Passwort am System an- und nach Abschluss der Arbeit wieder abzumelden. F202 Erfassen eines neuen Benutzers (P2) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, einen neuen Benutzer zu erfassen. Folgende Informationen müssen pro Benutzer erfasst werden: a) Name und Vorname b) Kürzel gemäss Stundenplan (eindeutig) c) -adresse d) Kommentar zum Benutzer (fakultativ) e) Passwort f) Status des Benutzers: - aktiv: Funktionalitäten gem. Modus 1 (siehe Kap ) stehen zur Verfügung 13

14 - inaktiv: kein Zugriff auf das RRS - Defaultwert bei Erfassung eines neuen Benutzers: aktiv Falls das gewählte Kürzel im System schon vorhanden ist, muss das RRS die Aufnahme des neuen Benutzers im System verhindern F203 Ändern eines bestehenden Benutzers (P3) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, einen bestehenden Benutzer zu ändern. Folgende Änderungen müssen möglich sein: a) Name und Vorname b) Kürzel gemäss Stundenplan (eindeutig) c) -adresse d) Kommentar zum Benutzer (fakultativ) e) Passwort f) Status des Benutzers: - aktiv: Funktionalitäten gem. Modus 1 (siehe Kap ) stehen zur Verfügung - inaktiv: kein Zugriff auf das RRS Falls das geänderte Kürzel im System schon vorhanden ist, muss das RRS die Änderung des Benutzers verhindern. F204 Löschen eines bestehenden Benutzers (P3) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, einen bestehenden Benutzer zu löschen. Falls der Benutzer zum Zeitpunkt der Löschung noch in Zukunft liegende Reservationen vorgenommen hat, wird der Administrator vor der Löschung darüber informiert. Das RRS muss in dem Fall dem Administrator die Möglichkeit bieten, den Benutzer inkl. der in Zukunft liegenden Reservationen zu löschen, oder aber die Löschung abzubrechen. F205 Erfassen einer neuen Ressource (P1) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, eine neue Ressource zu erfassen. Folgende Informationen müssen pro Ressource erfasst werden: a) Bezeichnung der Ressource b) Raum-Nr. (der Ressource bei Räumen, bzw. des Abstellortes bei mobilen Ressourcen) c) Kurzbeschreibung der Ressource d) Beschreibung der Ressource in Form einer Datei (fakultativ, für spätere Erweiterung) e) Kürzel der verantwortlichen Lehrperson / der bzw. des verantwortlichen Angestellten (fakultativ) f) Globaler Status der Ressource: - aktiv: Ressource steht im Modus 1 (siehe Kap ) zur Verfügung - inaktiv: Ressource steht im Modus 1 (siehe Kap ) nicht zur Verfügung - Defaultwert bei Erfassung einer neuen Ressource: inaktiv Falls die gewählte Kombination von Bezeichnung und Raum-Nr. im System schon vorhanden ist, muss das RRS die Aufnahme der neuen Ressource im System verhindern. F206 Ändern einer bestehenden Ressource (P2) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, eine bestehende Ressource zu ändern. Folgende Änderungen müssen möglich sein: a) Bezeichnung der Ressource b) Raum-Nr. (der Ressource bei Räumen, bzw. des Abstellortes bei mobilen Ressourcen) c) Kurzbeschreibung der Ressource d) Beschreibung der Ressource in Form einer Datei e) Kürzel der verantwortlichen Lehrperson / der bzw. des verantwortlichen Angestellten f) Globaler Status der Ressource: - aktiv: Ressource steht im Modus 1 (siehe Kap ) zur Verfügung - inaktiv: Ressource steht im Modus 1 (siehe Kap ) nicht zur Verfügung Falls die geänderte Kombination von Bezeichnung und Raum-Nr. im System schon vorhanden ist, muss das RRS die Änderung der bestehenden Ressource verhindern. 14

15 Falls bei Deaktivierung der Ressource noch Reservationen nach dem aktuellen Datum bestehen, wird der Administrator darüber informiert. Das RRS muss in dem Fall dem Administrator die Möglichkeit bieten, die Änderung der Ressource fortzusetzen oder aber abzubrechen. F207 Löschen einer bestehenden Ressource (P1) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, eine bestehende Ressource zu löschen. Falls auf der Ressource zum Zeitpunkt der Löschung noch in Zukunft liegende Reservationen bestehen, wird der Administrator vor der Löschung darüber informiert. Das RRS muss in dem Fall dem Administrator die Möglichkeit bieten, die Ressource inkl. der in Zukunft liegenden Reservationen zu löschen, oder aber die Löschung abzubrechen. F208 Zeitlich limitiertes Deaktivieren einer Ressource (P3) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, eine Ressource für eine bestimmte Zeitdauer zu deaktivieren. Folgende Eingaben müssen für eine zeitliche Deaktivierung gemacht werden: a) Beginn: Datum und erste Lektion der Deaktivierung b) Ende: Datum und letzte Lektion der Deaktivierung (fakultativ, falls nicht eingegeben, zeitlich unbeschränkte Deaktivierung) Die deaktivierte Ressource kann ab sofort, für die Zeit zwischen eingegebenem Beginn und Ende der Deaktivierung nicht mehr reserviert werden. Falls zum Zeitpunkt der Deaktivierung schon Reservationen zwischen Beginn und Ende der Deaktivierung bestehen, wird der Administrator vor der Aufnahme der Deaktivierung darüber informiert. Das RRS muss in dem Fall dem Administrator die Möglichkeit bieten, die Deaktivierung trotzdem im System aufzunehmen oder aber abzubrechen. Das RRS muss die Möglichkeit bieten, mehrere zeitlich limitierte Deaktivierungen pro Ressource im System zu erfassen. F209 Erfassen eines neuen Semesters (P1) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, ein neues Semester zu erfassen. Folgende Informationen müssen pro Semester erfasst werden: a) Bezeichnung des Semesters b) Jahr und Kalenderwoche des Semesterbeginns c) Jahr und Kalenderwoche des Semesterendes d) Ferien (Erfassung Kalenderwochen Beginn und Ende der Ferien) e) Tage (Datum), an welchen der Semester-Belegungsplan nicht gültig ist (Spezial-Unterricht, Feiertage, ) f) Status des Semesters: - aktiv: Reservationen im Modus 1 (siehe Kap ) möglich - inaktiv: Reservationen im Modus 1 (siehe Kap ) nicht möglich - Defaultwert bei Erfassung eines neuen Semesters: inaktiv Falls sich das Semester mit einem bestehenden Semester zeitlich überschneidet, muss das RRS die Aufnahme im System verhindern. F210 Ändern eines bestehenden Semesters (P2) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, ein bestehendes Semester zu ändern. Folgende Änderungen müssen möglich sein: a) Bezeichnung des Semesters b) Jahr und Kalenderwoche des Semesterbeginns c) Jahr und Kalenderwoche des Semesterendes d) Ferien (Erfassung Kalenderwochen Beginn und Ende der Ferien) e) Tage (Datum), an welchen der Semester-Belegungsplan nicht gültig ist (Spezial-Unterricht, Feiertage, ) f) Status des Semesters: - aktiv: Reservationen im Modus 1 (siehe Kap ) möglich - inaktiv: Reservationen im Modus 1 (siehe Kap ) nicht möglich 15

16 Falls für das bestehende Semester schon Reservationen vor dem geänderten Semesterbeginn oder nach dem geänderten Semesterende bestehen, wird der Administrator darüber informiert. Das RRS muss dem Administrator in diesem Fall die Möglichkeit bieten, das Semester zu ändern und ausserhalb des Semesters liegende Reservationen zu löschen oder aber die Änderung abzubrechen. Falls bei Deaktivierung des bestehenden Semesters schon Reservationen innerhalb des Semesters bestehen, wird der Administrator darüber informiert. Das RRS muss dem Administrator in dem Fall die Möglichkeit bieten, die Änderung des Semesters fortzusetzen, oder aber abzubrechen. F211 Löschen eines bestehenden Semesters (P1) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, ein Semester zu löschen. Falls innerhalb des Semesters zum Zeitpunkt der Löschung schon Reservationen bestehen, wird der Administrator vor der Löschung darüber informiert. Das RRS muss in dem Fall dem Administrator die Möglichkeit bieten, das Semester inkl. der im Semester liegenden Reservationen zu löschen, oder aber die Löschung abzubrechen. F212 Erfassen einer neuen Semester-Reservation (P1) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, für eine, dem System bekannte Ressource eine neue, wöchentlich wiederkehrende Reservation für die Dauer eines Semesters (= Semester-Reservation) zu erfassen. Folgende Informationen müssen pro Semester-Reservation erfasst werden: a) Ressource, für welche die Semester-Reservation vorgenommen wird b) Semester, für welches die Semester-Reservation vorgenommen wird c) Wochentag und erste Lektion der Semester-Reservation d) Gewünschte Dauer der Semester-Reservation (Defaultwert = "1 Lektion"; Maximalwert entspricht der Dauer bis zur nächsten bestehenden Semester-Reservation, beziehungsweise bis zur letzten Lektion des gewählten Tages, falls keine nachfolgenden Semester- Reservationen für diesen Tag mehr bestehen; Reservationseinheit = Lektion) e) Anlass, für welchen die Reservation vorgenommen wird (entweder unterrichtetes Fach oder Anlass wie "Lehrerkonferenz", "Orchesterprobe", "Workshop", etc.) f) Klasse, für welche die Reservation vorgenommen wird; Spezialeintrag falls keine Klasse g) Kürzel der Lehrperson, welche die Klasse während der Semester-Reservation unterrichtet h) -adresse der Lehrperson, welche die Klasse während der Semester-Reservation unterrichtet i) Kommentar zur Semester-Reservation (fakultativ) Falls sich die Semester-Reservation zeitlich mit einer andern Semester-Reservation überschneidet, muss das RRS die Aufnahme der neuen Semester-Reservation im System verhindern. F213 Ändern einer bestehenden Semester-Reservation (P3) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, eine bestehende Semester-Reservation zu ändern. Folgende Änderungen müssen möglich sein: a) Ressource, für welche die Semester-Reservation vorgenommen wurde b) Semester, für welches die Semester-Reservation vorgenommen wurde c) Wochentag und erste Lektion der Semester-Reservation d) Gewünschte Dauer der Semester-Reservation (Defaultwert = "1 Lektion"; Maximalwert entspricht der Dauer bis zur nächsten bestehenden Semester-Reservation, beziehungsweise bis zur letzten Lektion des gewählten Tages, falls keine nachfolgenden Semester- Reservationen für diesen Tag mehr bestehen; Reservationseinheit = Lektion) e) Anlass für welchen die Reservation vorgenommen wird (entweder unterrichtetes Fach oder Anlass wie "Lehrerkonferenz", "Orchesterprobe", "Workshop", etc.) f) Klasse, für welche die Reservation vorgenommen wird; Spezialeintrag falls keine Klasse g) Kürzel der Lehrperson, welche die Klasse während der Semester-Reservation unterrichtet h) -adresse der Lehrperson, welche die Klasse während der Semester-Reservation unterrichtet 16

17 i) Kommentar zur Semester-Reservation Falls sich die geänderte Semester-Reservation zeitlich mit einer schon bestehenden Semester- Reservation überschneidet, muss das RRS die Änderung verhindern. Wird eine bestehende Semester-Reservation für das aktuell laufende Semester geändert, gilt die Änderung vom Änderungszeitpunkt an bis zum Semesterende. F214 Löschen einer bestehenden Semester-Reservation (P1) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, eine bestehende Semester-Reservation zu löschen. Wird eine bestehende Semester-Reservation für das aktuell laufende Semesters gelöscht, so gilt die Löschung vom aktuellen Zeitpunkt an bis zum Semesterende. F215 Zeitlich limitiertes Deaktivieren einer Semester-Reservation (P3) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, eine Semester- Reservation für eine bestimmte Zeitdauer zu deaktivieren. Folgende Eingaben müssen für eine zeitliche Deaktivierung gemacht werden: a) Beginn: Datum der Deaktivierung, frühestens Semesterbeginn b) Ende: Datum der Reaktivierung, spätestens Semesterende (fakultativ, falls nicht eingegeben, zeitlich unbeschränkte Deaktivierung bis zum Semesterende) Das RRS muss die Möglichkeit bieten, mehrere zeitlich limitierte Deaktivierungen pro Semester- Reservation im System zu erfassen. F216 Erfassen einer neuen Einzel-Reservation (P1) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, eine Einzel- Reservation für eine, dem System bekannte Ressource vorzunehmen. Diese Funktion entspricht der Funktion F102 des Modus 1 mit folgenden Unterschieden: a) Einzel-Reservationen des Administrators können bestehende Semester-Reservationen oder Einzel-Reservationen von Standard-Benutzern bei zeitlicher Überschneidung überschreiben. Der Administrator wird in dem Fall auf die zeitliche Überschneidung aufmerksam gemacht und kann die Erfassung fortsetzen oder abbrechen. b) Einzel-Reservationen des Administrators werden für eine andere Person (Standard- Benutzer oder dem System nicht bekannte Person) vorgenommen. c) Wird die Einzel-Reservation für einen, dem System bekannten Standard-Benutzer vorgenommen, so muss der entsprechende Benutzer erfasst (= ausgewählt) werden. d) Wird die Einzel-Reservation für eine, dem System nicht bekannte Person (Gastreferent, ) vorgenommen, so müssen Name, Vorname und -adresse erfasst werden. F217 Ändern einer bestehenden Einzel-Reservation (P3) Falls der Administrator angemeldet ist und der Beginn der betroffenen Einzel-Reservation in der Zukunft liegt, muss das RRS die Möglichkeit bieten, die Einzel-Reservation zu ändern. Diese Funktion entspricht der Funktion F103 des Modus 1 mit folgenden Unterschieden: a) Die geänderte Einzel-Reservation kann bestehende Semester-Reservationen oder Einzel- Reservationen von Standard-Benutzern bei zeitlicher Überschneidung überschreiben. Der Administrator wird in dem Fall auf die zeitliche Überschneidung aufmerksam gemacht und kann die Änderung fortsetzen oder abbrechen. b) Zusätzlich zu den im Modus 1 möglichen Änderungen, kann auch die Person, für welche die Reservation vorgenommen wird (Standard-Benutzer oder dem System nicht bekannte Person), geändert werden. F218 Annullieren einer bestehenden Einzel-Reservation (P1) Falls der Administrator angemeldet ist und der Beginn der betroffenen Einzel-Reservation in der Zukunft liegt, muss das RRS die Möglichkeit bieten, die Einzel-Reservation zu annullieren und damit die Ressource für das reservierte Zeitfenster wieder freizugeben. Der Administrator kann Einzel-Reservationen sämtlicher Personen (Standard-Benutzer, oder dem System unbekannte Person) löschen. 17

18 F219 Drucken eines Semester-Belegungsplans (P3) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, von einer, dem System bekannten Ressource einen Semester-Belegungsplan zu drucken. Der Semester- Belegungsplan enthält alle Semester-Reservationen mit Vermerk der allfälligen Deaktivierungen, nicht aber die Einzel-Reservationen. F220 Drucken eines Wochen-Belegungsplans (P2) Falls der Administrator angemeldet ist, muss das RRS die Möglichkeit bieten, von einer, dem System bekannten Ressource einen Wochen-Belegungsplan der vom Administrator bestimmten Woche (Jahr und Kalenderwoche) zu drucken. Wochenstundenpläne enthalten alle aktiven Semester-Reservationen, sowie die Einzel-Reservationen Übersicht über Modi, Funktionen und Prioritäten In nachfolgender Tabelle sind sämtliche, in den Kapiteln und definierten Funktionen mit ihren Implementations-Prioritäten als Übersicht zusammengestellt. Modus Priorität Funktion 1 2 P1 P2 P3 F101 Benutzerkennung (P1) F102 Erfassen einer neuen Einzel-Reservation (P1) F103 Ändern einer bestehenden Einzel-Reservation (P3) F104 Annullieren einer bestehenden Einzel-Reservation (P1) F105 Anzeigen eines Wochen-Belegungsplans für eine Ressource (P1) F106 Anzeigen von Einzel-Reservationen eines Benutzers (P1) F201 Benutzerkennung (P1) F202 Erfassen eines neuen Benutzers (P2) F203 Ändern eines bestehenden Benutzers (P3) F204 Löschen eines bestehenden Benutzers (P3) F205 Erfassen einer neuen Ressource (P1) F206 Ändern einer bestehenden Ressource (P2) F207 Löschen einer bestehenden Ressource (P1) F208 Zeitlich limitiertes Deaktivieren einer Ressource (P3) F209 Erfassen eines neuen Semesters (P1) F210 Ändern eines bestehenden Semesters (P2) F211 Löschen eines bestehenden Semesters (P1) F212 Erfassen einer neuen Semester-Reservation (P1) F213 Ändern einer bestehenden Semester-Reservation (P3) F214 Löschen einer bestehenden Semester-Reservation (P1) F215 Zeitlich limitiertes Deaktivieren einer Semester-Reservation (P3) F216 Erfassen einer neuen Einzel-Reservation (P1) F217 Ändern einer bestehenden Einzel-Reservation (P3) F218 Annullieren einer bestehenden Einzel-Reservation (P1) F219 Drucken eines Semester-Belegungsplans (P3) F220 Drucken eines Wochen-Belegungsplans (P2) 18

19 3.3 Meldungen Folgende Systemmeldungen werden durch das Ressourcen-Reservations-System am Bildschirm ausgegeben: a) Information Informationsmeldungen dienen zur Quittierung des Erfolgs einer durchgeführten Aktion zu Handen des Standard-Benutzers oder Administrators. b) Hinweis Hinweise dienen dazu, dem Standard-Benutzer oder Administrator Anweisungen für die korrekte Bedienung des RRS zu geben. Typischerweise wird auf falsche oder nicht eingegebene, aber zwingend notwendige Eingaben hingewiesen. c) Warnung Warnungen weisen den Standard-Benutzer oder Administrator darauf hin, dass die geplante Aktion, nach Bestätigung der Warnmeldung, dauerhafte und unwiederrufbare Auswirkungen auf das RRS haben wird. d) Fehlermeldung Fehlermeldungen dienen typischerweise zur Mitteilung des Misserfolgs einer durchgeführten Aktion zu Handen des Standard-Benutzers oder Administrators. In gewissen Fällen kann direkt die neuerliche Ausführung der gleichen Aktion eingeleitet werden. 4 Datenbasis Folgende Merkmale charakterisieren die Datenhaltung im Ressourcen-Reservations-System und geben einen ganz groben Überblick: Die Datenhaltung erfolgt grundsätzlich in einer relationalen Datenbank (MySQL). Da die Anwendung nicht auf einem bestehenden Datenbestand aufbauen muss, wird ein neues Datenbankschema entworfen und verwendet. Die Datenbestände von Ressourcen und Reservationen, sowie Hilfsentitäten wie Semestern, Kalenderwochen etc. werden in dieser Datenbank persistiert. Da das RRS von mehreren Benutzern gleichzeitig verwendet werden kann, ist zur Behandlung von parallelen Datenbank-Ereignissen ein geeignetes Transaktionsmanagement vorzusehen. Die Benutzerdaten werden in einer Datei (Properties-File) abgelegt. Es ist geplant, die Authentisierung der Benutzer und den Bezug der Benutzerdaten später direkt über das Active Directory des Gymnasiums Neufeld abzuwickeln. Da die Möglichkeit der Mehrsprachigkeit in der Entwicklung und der Implementation des RRS von Beginn weg berücksichtigt wird, werden Beschriftungen, Meldungen etc. in speziellen Dateien abgelegt. Dieser Ansatz erlaubt es, später auf einfache Art und Weise andere Sprachversionen des RRS zur Verfügung zu stellen. Die Datensicherheit wird durch tägliche Backups von Datenbank und Benutzerdaten im Rahmen der globalen Backup-Strategie des Gymnasiums Neufeld sichergestellt. 19

20 5 Externe Schnittstellen 5.1 Benutzeroberfläche In den folgenden Abschnitten wird ein Vorschlag für die Ausgestaltung der Benutzeroberfläche gemacht. Die abgebildeten Masken stellen einen GUI-Prototyp dar. Die definitiven Masken können, was das Aussehen und die Anordnung betrifft, davon abweichen. Der GUI-Prototyp dient hauptsächlich dazu, erste Entwürfe von Eingabemasken, welche die Implementation der in Kapitel 3.2. geforderten Funktionen ermöglichen, auf Usability zu testen. Die nachfolgend abgebildeten Masken sind als Beispiele zu verstehen. Es wurde versucht, die Masken mit der grössten Verwendungsfrequenz darzustellen. Die Masken zur Änderung einer Entität (Ressource, Reservation) werden grundsätzlich gleich oder sehr ähnlich aussehen, wie die entsprechenden Erfassungsmasken Modus 1: Standard-Benutzer "Meine Reservationen" Abb. 4 bildet die Hauptmaske des Standard-Benutzers. Sie wird direkt nach der Anmeldung am RRS angezeigt. Die Abbildung Abb. 5 dokumentiert die Erfassung einer neuen Einzel-Reservation. Diese wird jeweils schrittweise, nach Abschluss des vorhergehenden Schrittes, bis zur nächsten horizontalen Linie erweitert und damit der nächste Abschnitt von Eingaben eingeblendet. Diese Anordnung ermöglicht in idealer Art und Weise die Benutzerführung, indem immer nur die als nächste notwendigen Eingabefelder angezeigt und die entsprechenden Eingaben abgefragt werden. GUI101 Reservationsverwaltung (= Meine Reservationen) Abb. 4: Reservationsverwaltung (= "Meine Reservationen") 20

21 GUI102 Erfassen einer neuen Reservation Schritt 1 Schritt 2 Schritt 3 Schritt 4 Schritt 5 Abb. 5: Reservation erfassen 21

22 GUI103 Belegungsplan drucken Abb. 6: Belegungsplan drucken Der Standard-Benutzer kann Belegungspläne einer Ressource für eine bestimmte Kalenderwoche anzeigen und mit der entsprechenden Funktion des Web-Browsers auch drucken. 22