Changes for page Anforderungen Software
Last modified by mgrawunder on 2025/09/29 10:00
From 7.1 to 6.2
From 10.1 to 9.2
From version 9.2
edited by mgrawunder
on 2025/09/29 09:58
on 2025/09/29 09:58
Change comment:
There is no comment for this version
To version 7.1
edited by mgrawunder
on 2025/09/11 13:13
on 2025/09/11 13:13
Change comment:
There is no comment for this version
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -59,9 +59,6 @@ 59 59 * Neue Nutzer sollen sich für das Spiel registrieren können. 60 60 * Registrierte Nutzer sollen sich am Spiel anmelden können. 61 61 * Die Nutzer sollen nach dem Einloggen in das Hauptmenü gelangen und dort alle Nutzer sehen, die auch eingeloggt sind. 62 -* Es soll eine Liste aller verfügbaren Lobbies angezeigt werden. 63 -* Man soll neue Lobbies mit einem Namen anlegen können 64 -* Man soll existierenden Lobbies beitreten können (ohne die Lobbies selber anzuzeigen 65 65 66 66 {{success}} 67 67 **Hinweis:** ... ... @@ -107,11 +107,11 @@ 107 107 108 108 * Eine allgemeine Einleitung für das Dokument. Worum geht es und wie ist das Dokument aufgebaut. 109 109 * Grundsätzlich sollte jeder Abschnitt kurz eingeleitet werden und jeden Kapitel sollte eine kurze Zusammenfassung bekommen. 110 -* Quellen müssen ange gebenen werden, also z.B. nicht einfach Text von einer Web-Seite kopieren. Das kann u.U. als Plagiat ausgelegt werden...107 +* Quellen müssen angebenen werden, also z.B. nicht einfach Text von einer Web-Seite kopieren. Das kann u.U. als Plagiat ausgelegt werden... 111 111 * Eine Darstellung der ermittelten Anforderungen. 112 112 ** Dies umfasst mindestens die umgesetzten User-Stories (Sinnvoll: Die Akzeptanzkriterien für eine User-Story mit angeben.). Idealerweise werden die UserStories (siehe [[User-Stories>>doc:Main.Scrum.WebHome||anchor="HUserStories"]]) noch durch Anwendungsfälle unterstützt. 113 113 ** Ggf. eine Darstellung/Auflistung nicht umgesetzter User Stories. Die kann noch einmal zeigen, welche kreativen Ideen zeitlich nicht mehr umgesetzt wurden 114 -** Die Stories sollten möglichst gruppiert (z.B. nach Nutzerverwaltung, Hauptmen ü/Lobby, etc.) werden.111 +** Die Stories sollten möglichst gruppiert (z.B. nach Nutzerverwaltung, Hauptmenue/Lobby, etc.) werden. 115 115 * Darstellung der Realisierung 116 116 ** Allgemeine/Übergreifende Konzepte, z.B. wie wurde MVP realisiert 117 117 *** Darstellung der Architektur und Aufteilung des Gesamtsystems in Module ... ... @@ -128,7 +128,6 @@ 128 128 **** Nicht immer ist offensichtlich, warum eine Lösung gewählt wurde. In diesem Fall sollten (Entwurfs-)Entscheidungen begründet/motiviert werden. Es ist grundsätzlich eine gute Idee, Dinge nicht nur „mitzuteilen“, sondern zu „erklären“. 129 129 **** Wenn man komplexere Algorithmen darstellen möchte, kann es besser sein, die Darstellung mit Pseudocode vorzunehmen. 130 130 *** Diagramme sollten an den Stellen im Text sein, an denen sie erläutert werden. Es muss vom Text aus auf die Diagramme verwiesen ("siehe Abb. X.Y") werden. Einfach alle im Anhang aufzulisten, macht keinen Sinn. 131 -*** Hinweise: Man kann Diagramme in Gitlab auch textuell erzeugen: [[https:~~/~~/docs.gitlab.com/user/markdown/#diagrams-and-flowcharts>>https://docs.gitlab.com/user/markdown/#diagrams-and-flowcharts]] Macht es u.U. gerade bei komplexen Diagrammen einfacher. 132 132 ** Bei Spiel: Regelabweichungen darstellen und begründen 133 133 ** (Java-)Quellcode im Text möglichst vermeiden. Pseudocode kann für die Beschreibung von komplexeren Algorithmen verwendet werden. 134 134 ** **ACHTUNG**! Die Konzepte bitte so darstellen, als wenn sie nicht iterativ entstanden wären. Also keine "Verteilung" des Konzeptes auf Sprints. Wichtig ist, was am Ende herausgekommen ist. ... ... @@ -160,7 +160,7 @@ 160 160 * Glossar mit Begriffen des Gegenstandes/Spiels 161 161 * Index (Falls Dokument mit LaTeX erstellt) 162 162 163 -Ich werde immer wieder gefragt, wie 159 +Ich werde immer wieder gefragt, wieviele Seiten die Dokumentation haben muss. Das lässt sich so pauschal leider nicht sagen, denn das hängt zum einen natürlich massiv von der verwendeten Vorlage ab, zum anderen aber auch davon, welches die aktuelle Aufgaben gewesen ist. Zur Orientierung kann man jedoch sagen, dass die typische (gelungene) (LaTeX-basierte-)Dokumentation in den letzten Jahren immer so in dem Bereich von 80 bis 100 Seiten (inkl. Anhängen und Bildern) gelegen hat. Es macht nun aber keinen Sinn, die Seitenanzahl künstlich durch "unnötigen" Inhalt aufzublähen. Ich schaue schon sehr genau darauf, wie gelungen und vollständig die oben genannten Punkte abgehandelt werden. 164 164 165 165 Zum Produkt selber noch notwendig: 166 166 ... ... @@ -175,7 +175,7 @@ 175 175 * Falls es Widersprüche zwischen der Vorlage und dem Text hier im Wiki gibt, bitte eine kurze Nachricht. Im Zweifelsfall zählt der Inhalt aus dem Wiki. 176 176 * Falls etwas nicht korrekt funktioniert, bitte auch eine kurze Nachricht. Ich kümmere mich. 177 177 * Gruppen, die ihre Dokumentation auch im Git pflegen wollen, können mir einen Nachricht schicken und ich richte das Repo dann passend ein. 178 -* [[https:~~/~~/git lab.swl.informatik.uni-oldenburg.de/SPB/dokumentation>>https://gitlab.swl.informatik.uni-oldenburg.de/SPB/dokumentation]]174 +* [[https:~~/~~/git.swl.informatik.uni-oldenburg.de/projects/SPB/repos/dokumentation/browse/>>url:https://git.swl.informatik.uni-oldenburg.de/projects/SPB/repos/dokumentation/browse/]] 179 179 {{/success}} 180 180 181 181 = Anforderungen: Nutzung von KI Tools =