$Log: Pflichtenheft.1.html,v $ Revision 1.1 1999/05/21 12:56:52 lammers Initial revision
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.
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 solltenauch Formeln eingegeben werden können.
Nach vorgenommenen Änderungen sollte die html-Vollversion automatisch aktualisiert werden.
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. Produkteinsatz Der Anwendungsbereich ist primär das Intranet des FB 15 (Mathematik/Informatik) der WWU Münster. Zielgruppe für die Erstellung des kVV ist der Kreis der wissenschaftlichen Mitarbeiter des FB 15, die einen Account zugewiesen bekommen. Die Zielgruppe f r das Fertiggestellte kVV ist nicht eingeschränkt. 3 Produktumgebung 1. Software - Server (Apache) - Java 1.2 - Betriebssystem (Unix) - Browser (mit html 4) (Wir sichern den einwandfreien Betrieb für den Netscape Communicator 4.5 zu) 2. Hardware - Benutzer (User, Erstellen) - Die User müssen über einen internettauglichen PC verfügen - Arbeitsplatzrechner am FB 15 - Ersteller (Firma Ach.com) - zur Verfügung steht ein hinreichend ausgestatteter Server entsprechend des Mathematik-Servers. - evtl. 32-bit-system tauglicher Rechner) 3. Orgware - Datenbank (PostgreSQL, Version 6.4) - Protokolle und Vernetzungen f r das Intranet und Internet 4. Schnittstellen - Datenbank-Server (CGI) evtl. Jdbc - Server-Arbeitsplatz (CGI) 4. Produktfunktionen /F10/ Es müssen über ein Web-Formular Accoutdaten eingegeben und gelöscht werden können. /F20/ Passwörter können durch den User und den Mentor über ein Web-Formular geändert werden. /F30/ Jede Person mit dem Account-Level n darf Accounts des Levels n+m einrichten und löschen. /F40/ Bevor eine Vorlesung eingegeben oder geändert wird, wird über ein besonderes HTML das Passwort des Benutzers abgefragt und damit seine Zugriffsberechtigung geprueft. /F50/ Bevor ein Account eingerichtet oder geloescht wird, wird ueber ein besonderes HTML das Passwort des Benutzers abgefragt und damit seine Zugriffsberechtigung geprüft. /F60/ Jeder Benutzer, der für das Lesen/ Eingeben/ Modifizieren/ Löschen einer Veranstaltung freigegeben ist, darf diese Funktionen ueber ein Web-Formular ausführen /F70/ Für sämtliche Funktionen des Users werden Web-Formulare bereitgestellt, die über einen Browser aufgerufen werden können. /F80/ Die Daten, die in dem Eingabe-Formular editiert wurden, werden über ein CGI-Skript in die Datenbank transferiert /F90/ Für das Lesen und Modifizieren bestehender Daten werden diese über ein CGI-Skript aus der Datenbank in die entsprechenden Felder eines Web-Formulars transferiert. /F100/ Der direkte Zugriff auf die Datenbank ist nur den dafür vorgesehenen Verwaltungspersonen gestattet. /F110/ Sämtliche Vorlesungsdaten, die älter sind als 5 Semester, werden als HTML-Seiten archiviert und und über Web-formulare lesbar gemacht. Sie werden jedoch automatisch aus der Datenbank gelöscht. /F115w/ Die vor Inbetriebnahme des Programms erstellten kVV`s sollen, sofern sie als HTML-Version vorliegen ebenfalls archiviert werden. /F120/ Die Veranstaltungen der letzten 5 Semester werden über ein Web-formular als PDF-Dateien bereitgestellt. /F130/ Die Veranstaltungsdaten der letzten 5 Semester werden aus der Datenbank über ein CGI-Skript ausgegeben und als HTML-Seiten bereitgestellt. /F140/ Für die Editierung einzelner Veranstaltungen werden folgende Suchkriterien zugelassen: Belegnummer, Name des Dozenten, Stichwort im Thema, alle Veranstaltungen mit Freigabe für seinen Account in Abhängigkeit vom Semester. /F150w/ Als Erweiterung von /F80/ können die Daten anderer Veranstaltungen (älterer Semeste) übernommen und in modifizierter Form als HTML-Seiten gespeichert werden. /F160/ Für das Lesen einzelner Veranstaltungsdaten der etzten 5 Semester werden folgende Ordnungskriterien zugelassen: Name des Dozenten, Thema, Zuordnung/Hörerkreis /F170/ Für das Lesen einzelner Veranstaltungsdaten der letzten 5 Semester werden folgende Suchkriterien zugelassen: Name des Dozenten, Stichwort im Thema, Belegnummer, Zuordnung/Hörerkreis, evtl. Zeit /F180/ 2 Wochen vor Ablauf einer Deadline generiert das Programm e-Mails zur Erinnerung der Fertigstellung der Veranstaltungsdaten und versendet diese an die unter den Accountdaten gespeicherten e-Mail-adressen. 5. Produktdaten /D100/: Accountdaten: - Benutzer-Id (eindeutiger Benutzername) - Vorname - Nachname - Geburtsdatum - Paßwort - Mentor - Level - e-Mail-Adresse - Homepage des Professors /D200/: Veranstaltungshinweise Bei den Veranstalungshinweisen wird zwischen a) Verwaltungsdaten und b) für den Leser sichtbare Daten unterteilt: - ID (a) - Vorname (a,b) - Nachname (a,b) - Semester (a,b) - Titel (a,b) - Zeit/Ort (a,b) - Beginn (a,b) - Belegnummer (a,b) - Zuordnung (a,b) - Hörerkreis (a,b) - Adressaten (a,b) - Interessenten (a,b) - Inhalt (a,b) - Vorkenntnisse (a,b) - Übnungsschein (a,b) - Leistungsnachweis (a,b) - Seminarschein (a,b) - Anschlußveranstaltung (a,b) - Anmeldung (a,b) - Vorbesprechung (a,b) - Literatur (a,b) - Links zur Vorlesung (a,b) - Homepage des Professors (URL für den Dozenten)(a,b) - Mitarbeiter (a,b) - Sprechstunde (a,b) - Semester (a,b) - Änderungsberechtigt (a) - Löschberechtigt (a) - Leseberechtigt (a) - letzte Änderung (a) - letzter Änderer(a) /D300/ Zusatzinformationen - ID-Nummer - Einrichter - Semester - Inhalt - Titel - letzte Änderung - letzter Änderer - Semester - Änderungsberechtigt - löschberechtigt - leseberechtigt /D400/ Deadline 6. Leistungen /L10/ Formeleditor /L20/ Die Anwendung muß eine Datenmenge von mindestens 500 Accounts und 10000 Veranstaltungshinweise bzw. Zusatzinformationen verwalten können /L30/ Sämtliche Transfers von Daten zwischen Datenbank und Web-Formular darf max. 60 sec. dauern. 7. Benutzeroberfläche Die Benutzeroberflächen sind die eigentlichen HTML-Formulare. Das Aussehen der Anwendung kann in Abhängigkeit des Betriebssystems bzw. des Browsers variieren. Generell ist zu unterscheiden zwischen den Web-Formularen a) bei der Erstellung eines kVVs und b) bei dem Lesen eines fertigen kVVs. Der Zugang zu den Formularen für a) bedarf eines entsprechenden Accounts. 8. Qualitätsziele Bedienerfreundlichkeit + Erweiterbarkeit +- Zuverlässigkeit ++ Portabilität + Effizienz +- Funktionalität +- 9. Testszenarien Die bislang durchgeführten Tests waren ausschließlich auf einzelne Komponenten wie Apache-Server, HTML-Seiten oder PostgreSQL beschränkt. 10. Entwicklungsumgebung a) Software: - JdK 1.2 (Sun) - Editor für das Erstellen der HTML-Dokumente 11. Ergänzungen Viele Grüsse die Firma Ach-Com