Systemspec - Verbesserungen

[bschroedhtl]

Ab dem Unterkapitler 2.2 sollten der Reihe nach alle Use cases im Detail ausspezifiziert werden, mit einem Unterkapitel für jeden Use Case aus dem UCD - jeder Usecase bekommt ein eigenes UI-Design und eine Beschreibung des Ablaufs (idealerweise mit ACD). D.h. die Anzahl der Unterkapitel ab 2.2 (2.3, 2.4, ...) entspricht der Anzahl der Use Cases in Ihrem UCD, mit ordentlichen UC-Benennungen.

• [x] Spiel spielen: Etwas sehr grob, aber eigentlich gehts nur um das neue Feature des Speichern des Spielstandes, diesen UC als extends zu modellieren ist grundsätzlich nicht falsch, weil es ja nur eine Option ist - allerdings nur möglich wenn man sich als User anmeldet oder? Das kommt aus dem UCD nicht hervor, dafür würde ich einen zweiten Aktor hinzufügen, der "Logged in user" oder so ähnlich heißt, und der kann dann auch Spiel speichern ausführen - aber nur der, der normale User nicht.
• [x] Wie ist das dann mit den gespeicherten Spielständen - dafür fehlt mir ein Use Case, um diese anzusehen und eines dieser Spiele dann fortzusetzen. Wiederum nur mit Account möglich, also nur mit dem logged-in-user verknüpft! Kann man gespeicherte Spielstände auch löschen? Welche Spiele kann ich als nicht angemeldeter User spielen, gibts da auch eine Liste von "public" Spielen, aus dem ich eines auswähle, aber dann keinen Spielstand dafür speichern kann, d.h. ich fange mit dem dann immer wieder von vorne an ... ist das überhaupt gut so, brauchen Sie das oder soll nicht gleich jeder user einen account haben, um überhaupt spielen zu können? Überlegen Sie das nochmal durch. Es wäre ja auch denkbar, das Account-Management vorerst wegzulassen und alle Spiele sind automatisch für jeden spielbar und jeder kann neue Spiele erstellen oder bestehende Spiele ändern ...
• [x] Einloggen und Erstellen eines Accounts sollten nicht vermischt werden, das sind zwei grundsätzlich unterschiedliche Use Cases -> auf 2 UCs aufteilen. Sie sind nur meistens aus der selben View heraus aufrufbar.

Spiel erstellen: Das ist das neue Hauptfeature, das haben Sie auch gut gemacht, dass Sie dafür ein weiteres UCD gemacht haben, um dieses große Feature in kleinere Use Cases zu zerlegen. Allerdings verstehe ich das UCD für Erstellen nicht:

• [x] Gibt es Szenen ohne Entscheidung? Geht es dann einfach bei der nächsten Szene weiter?
• [x] Bei Szenen mit Entscheidung - gibt es genau zwei mögliche Optionen? Wie werden diese Optionen mit der entsprechenden Nachfolgeszene verknüpft? Im GUI-Design gibts einen Button "Make decision" - wie soll das ablaufen? Da entsteht ja dann eine wilde Baumstruktur, jedenfalls nichts was man in einer sequentiellen Liste leicht unterbringen kann. Ich habe das Gefühl, da müssen Sie sich mal grundsätzlich eine gute Darstellung für einen Szenenbaum überlegen - diesen brauchen Sie ja auch für das Feature, dass man während eines aktiven Spiels sich die bisher gespielten Szenen anschauen kann. Auch diese Ansicht wird eher baumartig sein vermutlich, und das fehlt im übrigen noch im UCD.
• [x] Soll man Szenen nicht auch löschen können?
• [x] Welchen Sinn hat es, ein Spiel zu erstellen und Szenen hinzuzufügen, es dann aber nicht auf der Website zu speichern? Dann hat man ja alles umsonst gemacht? Also das Speichern ist meiner Meinung da zwingend notwendig und muss automatisch immer gemacht werden => kein expliziter Use Case da keine User-Tätigkeit dafür notwendig.

Überarbeiten Sie das mal insbesondere die Kapitel-Struktur ab 2.2 und dann schau ich nochmal drüber. Es sind jedenfalls schon sehr viele Überlegungen da :-)

[bschroedhtl]

Die Kapitelstruktur ist noch falsch: 2.2 Spiel erstellen 2.3 Entscheidung einbauen 2.4 Spiel spielen etc.... Und genaue diese Unterkapitel müssten 1:1 mit den Use Cases aus dem UCD matchen, tun sie aber nicht ... Der Navigationsbaum ist auch noch nicht fertiggedacht finde ich (Entscheidungs-Verzweigungen).