Download CSV

Nonsense

Inconsistent / irrelevant / very brief

Confusing / redundant / severe formal flaws / quite brief

A bit superficial / slightly inconsistent / quite short / visible formal flaws

Good, but ... a bit short / minor formal flaws

Comprehensive, well defined, formally fine

       

Use Case »Barrierefreiheit« (UC-4)

Enthalten in Use-Case-Diagramm
Use-Case-Diagramm zu funktionaler Anforderung »Barrierefreiheit« (UCD-5)
Zugrundeliegende funktionale Anforderung
FR-18: Barrierefreiheit
History
(v1)   2021-07-21 - initially created
(v2)   2021-07-31 - fix todo

Use-Case-Header

Titel
Barrierefreiheit
Beschreibung
Ein User kann die Form der Barrierefreiheit einstellen
Primärer Aktor
STR-10: Studierende*r
Auslöser
Der User ruft die Einstellung für Barrierefreiheit auf
Vorbedingung
Der Nutzer leidet an einer Form der Farbschwäche
Nachbedingung
Farben sind aus dem System verschwunden und werden durch Symbole/Text ersetzt

Als User zählt bei diesem Usecase jeder Stakeholder, der mit diesem System interagiert und seine visuellen Settings anpassen möchte.

Dieser UC ist vom UC Branding deutlich abzugrenzen. Hierbei geht es ausschließlich um das Aktivieren/Deaktivieren von einer Barrierefreien Ansicht. Diese ist vom System vorgegeben und nicht durch Einstellung der Uni änderbar. Vor Augen kann man sich das besonders gut führen, wenn man einmal die Barrierefreiheit und Branding in eine Kano-Klassifikation übernimmt. Barrierefreiheit ist hier eindeutig ein Basismerkmal, wohingegen Branding, je nach Szenario, ein Leistungs- oder Begeisterungsmerkmal ist.

Hauptszenario

Alternativszenario

Ausnahmeszenario

Bei korrekter Implementierung der Barrierefreiheit visuallisierung kann es zu keinem Ausnahmeszenario kommen.

Andere Nachbedingung: Der Student kann plötzlich wieder Farben erkennen?