g3t3 [Main]
P1
Anforderungsanalyse
Szenario: Student meldet sich an
Der Student klickt auf der Startseite auf einen Link und gelangt zum Anmeldeformular. Dort gibt er seinen gewünschten Username sowie E-Mail-Adresse und Passwort ein (wie üblich zweimal, um Tippfehler zu verhindern). Aus einer Liste kann er darauf sein Studium wählen. Dann bestätigt er seine Angaben. Die Anmeldung wird durch einen Bestätigungslink, der an seine E-Mail-Adresse gesandt wird, abgeschlossen.
Szenario: Semesterplan erstellen
Der Student meldet sich mit seinem Passwort und seinem Benutzernamen an und gelangt auf eine Seite, in der die Lehrveranstaltungen für sein Studium aufgelistet sind. Er kann entweder das Semester wählen, wodurch alle Lehrveranstaltungen des gewählten Semesters ausgewählt werden, oder manuell Veranstaltungen, die er besuchen möchte wählen. Nachdem er seine Angabe bestätigt hat, gelangt er zu seinem Stundenplan. Bei Übungsgruppen mit alternativen Terminen bzw. Terminkonflikten wird er auf notwendige Änderungen aufmerksam gemacht. Schließlich kann er seinen Stundenplan speichern und exportieren (z.B. per PDF).
Szenario: Kontoinformationen ändern
Nach der Anmeldung erhält der User auf einer eigenen Seite die Möglichkeit, seine Kontoinformationen und Einstellungen zu ändern. Er kann Passwort und E-Mail-Adresse ändern, sowie zwischen verschiedenen Benachrichtigungsstufen wählen: Keine Benachrichtigung, Benachrichtigung bei Terminänderungen, Wöchentliche Erinnerung an Termine, Tägliche Erinnerung an Termine.
Weiters wurden durch einen Gruppenworkshop folgende Anforderungen ermittelt:
Das System soll für die User wichtige Daten verwalten, weshalb Datensicherheit sehr wichtig ist. Jede Eingabe des Benutzers soll daher bestätigt werden. Der Benutzer soll sicher sein, dass seine Eingabe gespeichert wird, indem er eine Bestätigung des Systems erhält. Bei Fehlern im System, soll der User informiert werden, dass seine Angaben nicht gespeichert werden konnte. In solchen Fällen sollen die betreffenden Log-Einträge an den Administrator des Systems gesendet werden.
Benutzer sollten außerdem andere Teilnehmer einer Lehrveranstaltung kontaktieren können, falls es von diesen erwünscht ist.
Außerdem sollte auf ein möglichst barrierefreies Design und valides Coding geachtet werden. Zu beachten sind dabei die WCAG des W3C.
Zielanalyse für das Projekt STUSS
- Abstrakte Ziele:Z1..erleichterte SemesterplanungZ2..erleichterte StudienfortschrittsübersichtZ3..Kalenderdarstellung
- Subziele:Z4..SemesterplananzeigeZ5..Automatische Übernahme von LVsZ6..Manuelle Übernahme von LVsZ7..Ansicht nach MonatZ8..Ansicht nach WocheZ9..Export als PDF und IcalZ10..BenachrichtigungenZ11…Import von Studien, Plänen, LVs…Z12..Verlinkung mit UIVISZ13..Anzeige offener/erledigter LVs
Funktionale Anforderungen
- Anzeige des aktuellen Lehrveranstaltungsverzeichnisses
- Wahl der gewünschten Vorlesungen
- Stundenplanübersicht
- Benutzerverwaltung
- Stundenplan-Export als PDF
- Kontakt zu anderen LVA-Teilnehmern
(Details auch unter "Hierarchische Übersicht".)
Nicht-Funktionale Anforderungen
- SicherheitDie Transaktionen werden vom System gehört. Weiters werden benutzerspezifische Daten durch Passwortabfragen geschützt.
- UsabilityDas Interface von STUSS ist möglichst benutzerfreundlich zu gestalten. Die entsprechenden Abschnitte ("Software") der EN ISO 9241 müssen erfüllt werden. Das System muss die WCAG des W3C beachten.
- PerformanceDas System muss vom Studenten angeforderte Seiten immer innerhalb von 2sec generieren. Der Import aller Daten via Webservice von der Uni Wien muss innerhalb von 15min laufen.
- WartungMaintenance Tätigkeiten werden ausschließlich von der GGT Gmbh durchgeführt.
- ZuverlässigkeitDas System (Hard- und Software bis zum Studenten) soll bis auf Wartungsarbeiten weitgehend, d.h. zu 99,5%, verfügbar sein. Weiters ist eine regelmäßige Synchronisation mit der LV Datenbank der Universitäten notwendig.
- SkalierbarkeitDie Anzahl der Benutzer und wählbaren Lehrveranstaltungen soll prinzipiell unbegrenzt sein.
- TechnikEs muss PHP 5(oder höher) mit mySql 5 (oder höher) verwendet werden.
Hierarchische Übersicht
UML Use Cases
Student meldet sich am System an
Student benutzt System
Betreiber verwaltet System
Letzte Änderung: 28.10.2009, 15:54 | 572 Worte