P F L I C H T E N H E F T ========================== Produkt : WVZ ("WWW-basiertes VorlesungsverZeichnis") Hersteller : inComPeTent (TM) Kunde : Westfälische Wilhelms-Universität Münster Fachbereich Mathematik und Informatik 1) Zielbestimmung ------------------ 1. Mußbestimmungen Das zu erstellende System muß es ermöglichen, am FB15 der WWU EDV-unterstützt ein kommentiertes Vorlesungsverzeichnis zu erstellen und zu verwalten. Ziel ist, aus den per WWW erfaßten Daten sowohl eine druckbare Vollversion in diversen sinnvollen Formaten (ps, pdf) als auch eine html-Vollversion zu erstellen, außerdem soll auf den aktuellen Daten eine parametrisierte Suche (Veranstalter, Termin, Zuordnung zu Studium etc.) möglich sein. Erstellt werden die Einträge von den Veranstaltungsanbietern, also i.a. Professoren oder deren Beauftragte, durch ausfüllen geeigneter WWW-Formulare. Es muß dabei möglich sein, einen Eintrag zunächst unvollständig einzugeben und später zu ergänzen. Nach außen sichtbar darf solch ein Eintrag erst dann sein, wenn er von einem entsprechend Berechtigten dazu freigegeben worden ist. Ein Eintrag kann durch mehrere vom Hauptverantwortlichen anzugebende Personen bearbeitet werden. Neben den reinen Vorlesungsdaten sind noch Zusatzinformationen wie Studienhinweise, Ferientermine etc. zu verwalten. Diese sollen im Prinzip wie Veranstaltungshinweise behandelt werden, nur sind hier sicher andere Personen verantwortlich. Änderungen nach Drucklegung sind an zentraler Stelle (Einstiegsseite) zu vermerken. Es wird jeweils eine html-Version des Zustandes bei Drucklegung, und eine aktuelle html-Version vorgehalten. Für fünf Semester sind die Daten im Vollzugriff zuhalten. Ältere Datenbestände werden in Form der Druckversion (pdf) und der letzten aktuellen html-Version archiviert, und sollten so immer noch zugreifbar sein. Um Mißbrauch zu vermeiden, ist zur Realisierung der vorigen Aufgaben eine geeignete Benutzerverwaltung zu verwirklichen. 2. Sollbestimmungen Bei Aufnahmen der Daten sollte ein Prüfung auf Konsistenz und Vollständigkeit (d.h. Vorhandensein der notwendigen Daten) erfolgen. Nicht vollständige Dokumente sollten bei Drucklegung nicht mehr existieren. Zur Unterstützung der Drucklegung sollten ein Deadline-Mechanismus mit automatischer Erinnerung implementiert werden. Im Titel und Beschreibungstext sollten auch Formeln eingegeben werden können. Nach vorgenommenen Änderungen sollte die html-Vollversion automatisch aktualisiert werden. 3. Muß-nicht-Bestimmungen Es muß nicht unbedingt auf Kompatibilität zu ähnlichen Systemen Rücksicht genommen werden. Insbesonderer braucht keine Datenaustauschformat definiert zu werden. Es muß keine spezialisierte Volltext-Suchmaschine (e.g. harvest) angeboten werden 2) Einsatz ----------- 1. Anwendungsbereiche : Das Produkt soll der WWW-gestützten Erstellung,Aufbereitung und Benutzung eines Vorlesungsverzeichnisses dienen, welches die Veranstaltungen am Fachbereich Mathematik und Informatik enthält. 2. Zielgruppen : -> das Dekanat (als Zentralstelle) -> die Dozenten des Fachbereichs und deren Mitarbeiter -> die Studenten des Fachbereichs 3. Betriebsbedingungen : Das Programm wird von einer EDV-Gruppe installiert und soll ohne Betreuung benutzbar sein. 3) Produktumgebung ------------------- 1. Software : - Browser - gegebenenfalls weitere Programme zum Anzeigen der veschiedenen Textformate z.B. Acrobatreader, Word... - Perl-Interpreter 2. Hardware : internetfähige PCs/Workstations/Web Terminals 3. Orgware : - Internet - Webserver - Datenbank 4. Schnittstellen : - HTML - TeX - Doc - PDF 4) Funktionen -------------- Folgende Kernfunktionen sind zu erfüllen: /LF10/ Erfassung, Änderung und Löschung der Daten, allerdings nur durch für die jeweilige Aktion berechtigte Benutzer: /LF11/ Erfassung, Änderung und Löschung der Veranstaltungsdaten durch die jeweiligen Professoren bzw. durch die von ihnen authorisierten Mitarbeiter. (Im Dokument wird vom Professor angegeben, welche Mitarbeiter dieses Dokument bearbeiten dürfen). Die anzugebenden Daten sind: - Thema - Zeit - Ort - Beginn - Belegnummer - [ÜbungsBelegnummer] - Zuordnung (GS, HS, GS und HS, reine Mathe, angewandte Mathe, Informatik, LA, Dipl, andere Fachbereiche) - Adressaten - Inhalt - Vorkenntnisse - Übungsschein - Leistungsnachweis - Seminarschein - [Anschlussveranstaltung] - [Anmeldung] - [Vorbesprechung] - Sprechstunde - [Sonstiges] - [Links] - Literatur - Dozent(en) - Mitarbeiter - Veranstaltungstyp (Vorlesung/Seminar/Vorlesung mit Übung) /LF12W/ Bei Erfassung, Änderung und Löschung der Daten soll es eine automatische Prüfung auf Vollständigkeit geben (die unter /LF11/ in [] angegebenen Punkte sind optional, alle anderen Punkte müssen angegeben werden) /LF13W/ In das unter /LF11/ aufgeführte Feld "Inhalt" sollen Formeln eingegeben werden können /LF14/ Erfassung der Zusatzinformationen durch die "Zentralstelle". /LF15/ Anlegen der einzelnen Veranstaltungen durch Eingabe von "Thema" und "Dozent" durch die Zentralstelle. /LF16/ Speicherung von unvollständigen Daten möglich. Die Daten werden erst sichtbar nach Freigabe durch einen dazu Berechtigten. /LF17/ Anlegen eines neuen Semesters durch die Zentralstelle. /LF20W/ Eingabe einer "Deadline" durch die "Zentralstelle", bis zu der die Dozenten alle Informationen zu ihren Vorlesungen übermittelt haben müssen; ggf. automatische Erinnerung vor Ablauf der Deadline. /LF30/ Überblick für die "Zentralstelle" -> über alle erfaßten Veranstaltungen -> über den Stand der von den jeweiligen Dozenten einzugebenden zusätzlichen Informationen dazu (nichts, unvollständig, ...) /LF40/ Aufbereitung der Informationen zu den Veranstaltungen zu verschiedenen Dateiformaten: -> HTML -> TEX -> DOC -> PDF /LF50/ Überblick für die einzelnen Dozenten -> über alle eigenen Veranstaltungen -> über den Stand der bereits eingegebenen Informationen (nichts, unvollständig, ...) -> über die einzuhaltende "Deadline" /LF60/ listenförmiger Überblick über alle angebotenen Veranstaltungen für die Studenten auf folgende Weise: /LF61/ HTML-Version des Zustandes bei Drucklegung /LF62/ aktuelle HTML-Version /LF63W/ Die aktuelle HTML-Version soll nach jeder Änderung automatisch aktualisiert werden. /LF64/ Änderungen nach Drucklegung werden auf der Einstiegsseite vermerkt. /LF70/ Beantwortung von Abfragen zu den angebotenen Veranstaltungen für die Studenten (aber auch alle anderen Interessierten), beispielsweise(!!!): -> alle Veranstaltungen des Grund-/Hauptstudiums -> alle Vorlesungen / Seminare / ... -> alle Veranstaltungen eines Dozenten -> alle Veranstaltungen zu bestimmten Zeiten -> alle Veranstaltungen in Reiner Mathematik / Angewandter Mathematik / Informatik / ... -> kombinierte Anfragen aus den obigen Bereichen /LF80/ hierarchisches Accounting: - Level n darf Passwörter für Level n+1 vergeben. - Level 0 : Dekan ("Zentralstelle") - Level 1 : Professoren - Level 2 : Mitarbeiter, Sekretärinnen 5) Daten --------- Folgende Daten sind zu speichern: /LD10/ Daten zu den Veranstaltungen: - Thema - Zeit - Ort - Beginn - Belegnummer - ÜbungsBelegnummer - Zuordnung (GS, HS, GS und HS, reine Mathe, angewandte Mathe, Informatik, LA, Dipl, andere Fachbereiche) - Adressaten - Inhalt - Vorkenntnisse - Übungsschein - Leistungsnachweis - Seminarschein - Anschlussveranstaltung - Anmeldung - Vorbesprechung - Sprechstunde - Sonstiges - Links - Literatur - Dozent(en) - Mitarbeiter - Veranstaltungstyp (Vorlesung/Seminar/Vorlesung mit Übung) /LD20/ "Deadline", bis zu welcher alle Informationen vorliegen müssen /LD30/ verschiedene Formulare; insbesondere zur Erfassung und Bearbeitung der unter /LF10/ aufgeführten Angaben /LD40/ Daten zum "Accounting": - Benutzerkennung - Accountinglevel - Mentor - e-mail-Adresse - Name /LD50/ Zusatzinformationen /LD60/ Zu jedem Dokument, das Veranstaltungsdaten oder Zusatzinformationen enthält, sind folgende Daten zu speichern: - Datum der letzten Änderung - Status: fertig/nicht fertig (nur fertige Dokumente sind nach außen hin sichtbar) - die Mitarbeiter, die dieses Dokument ändern dürfen - die Instanz, die dieses Dokument löschen darf ("Zentralstelle") - Verwalter des Dokuments (Professor) 6) Zusatzleistungen -------------------- Es müssen maximal 5000 Veranstaltungen und maximal 300 Zugangs- berechtigungen verwaltet werden. Es sind 5 Semester aktuell zu halten, bei noch älteren Semestern sind die Druckversion (pdf) und die letzte aktuelle html-Vollversion mit entsprechendem Zugriff als Archivdaten anzubieten. 7) Benutzeroberfläche ---------------------- Wird durch den Browser und die HTML-Seiten bestimmt. 8) Qualitätsanforderungen -------------------------- ++ + o - -- --- --- --- --- --- Funktionalität X Zuverlässigkeit X Benutzerfreundlichkeit X Effizienz X Änderbarkeit X Übertragbarkeit X - Bei Störungen im Netzwerk dürfen keine Daten verlorengehen. - Fehler in der Bedienung müssen abgefangen werden, sie dürfen nicht zu Datenverlusten führen. 9) Testfälle ------------- 1) Anlegen eines Accounts 2) Eingabe, Änderung, Löschung von Veranstaltungsdaten 3) Suche nach bestimmten Veranstaltungen 10) Entwicklungsumgebung ------------------------- 1. Software - HTML-Editor - Perl - Browser 2. Hardware - PCs/Sun-Workstations Orgware und Schnittstellen entsprechen Punkt 3) 11) Ergänzungen ---------------- - keine -