FH-Gießen-Friedberg. Smash It! Software Requirements Specification. Version <1.1>

Transkript

1 FH-Gießen-Friedberg Smash It! Software Requirements Specification Version <1.1>

2 Revision History Date Version Description Author Erste Version der SRS Florian Feuerstein Überarbeitung nach erstem Review Florian Feuerstein Überarbeitung nach Implementation Florian Feuerstein -vertraulich- FH-Gießen-Friedberg, 2011 Page 2

3 Index Einführung Ziel Umfang 4 Definitionen, Akronyme und Abkürzungen 4 Referenzen 4 Übergreifende Darstellung 5 Use-Case Model Übersicht 5 Genaue Anforderungen 6 Use-Case Beschreibungen Multiplayerspiel spielen Bewegen Item einsammeln Gegnerisches Leben nehmen Lokales Spiel eröffnen Spieler auswählen Map auswählen Optionen auswählen Netzwerkspiel eröffnen Spieler hinzufügen Netzwerkspiel beitreten Eigene Map kreieren Map laden Map speichern Element platzieren Element löschen Alle Elemente löschen Hintergrundbild ändern In die Highscoreliste eintragen Highscore anschauen 13 Zusätzliche Anforderungen 13 Funktionalität 13 Benutzbarkeit 13 Leistung 14 Instandhaltung 14 Verwaltungsbedingung 14 Designbedingungen 15 Benutzerdokumentations- und Hilfesystem-Anforderungen 15 -vertraulich- FH-Gießen-Friedberg, 2011 Page 3

4 Software Requirements Specification Einführung 1.1 Ziel Die SRS beschreibt das äußere Verhalten des 2D-Multiplayer-Spiels, sowie nichtfunktionelle Anforderungen, Gestaltungsgrenzen und andere Faktoren, die nötig sind um eine komplette und verständliche Beschreibung der Anforderungen für die Software bereitzustellen. 1.2 Umfang Diese SRS befasst sich mit allen Use Cases und zusätzlichen Anforderungen des 2D-Multiplayer-Spiels. Definitionen, Akronyme und Abkürzungen Siehe Glossar [3]. Referenzen Geeignete Referenzen sind: [1] Vision [2] MSProject Iteration Plan Inception1 [3] Glossary -vertraulich- FH-Gießen-Friedberg, 2011 Page 4

5 Übergreifende Darstellung Use-Case Model Übersicht -vertraulich- FH-Gießen-Friedberg, 2011 Page 5

6 Genaue Anforderungen Use-Case Beschreibungen Multiplayerspiel spielen Kurze Beschreibung Dieser Use Case erlaubt es gegen andere Mitspieler im Spiel anzutreten. Jeder Mitspieler hat dabei eine bestimmte Anzahl an Leben, die vorher beim Anlegen des Spiels (siehe Lokales Spiel eröffnen) festgelegt worden sind. Ziel ist es, durch Springen auf einen Gegner diesem ein Leben zu nehmen bis er keines mehr hat und als letzter Charakter auf der Map zu stehen Flow of Events Basic Flow Der Use Case beginnt, wenn ein Spiel eröffnet wurde (siehe Lokales Spiel eröffnen) und zeigt nun die Map, die Spieler und das HUD (Head-Up-Display) an (siehe User Interface Prototype). Der Spieler steuert seinen Charakter nun mit den zugewiesenen Tasten durch die Map, sammelt Items ein (siehe Items einsammeln), die ihn für eine bestimmte Zeit verbessern oder auch verschlechtern, und springt auf seine Gegner, um ihnen ein Leben zu nehmen (siehe Gegnerisches Leben nehmen). Der Spieler ist so gut, dass er als letztes überlebt, am meisten Punkte hat und das Spiel gewinnt. Das Spiel wird geschlossen und eine Auswertung der Ergebnisse wird angezeigt Alternative Flows Der Use Case beginnt mit den gleichen Ereignissen wie im Basic Flow. Der Spieler ist aber nicht so gut und verliert all seine Leben. Darauf ist er aus dem Spiel geschieden und sein Charakter verschwindet von der Anzeige. Der Spieler muss so lange warten bis das Spiel beendet ist und sich die Ergebnisanzeige öffnet. In der nächsten Runde kann wieder jeder Teilnehmer mitspielen. -vertraulich- FH-Gießen-Friedberg, 2011 Page 6

7 User Interface Prototype Bewegen Kurze Beschreibung Dieser Use Case erlaubt es einem Spieler seinen Charakter mit den zugewiesenen Tasten zu steuern. Man kann einen Charakter nach links und rechts steuern und ihm den Befehl zum Springen geben. Das Fallen ist ebenfalls eine Bewegung, auf die man aber keinen Einfluss nehmen kann Item einsammeln Kurze Beschreibung Dieser Use Case erlaubt es einem Spieler ein Item einzusammeln, welches für einen bestimmten Zeitraum einen positiven oder negativen Einfluss auf dessen Charakter ausübt. Ein Spieler kann immer nur ein Item zur selben Zeit besitzen. Man sammelt ein Item auf, in dem man darüber läuft. Ein paar Beispiele für positive und negative Einflüsse sind: - Charakter kann doppelt so hoch springen / Charakter kann gar nicht springen - Charakter läuft doppelt so schnell / Charakter läuft halb so schnell -vertraulich- FH-Gießen-Friedberg, 2011 Page 7

8 1.2.4 Gegnerisches Leben nehmen Kurze Beschreibung Dieser Use Case erlaubt es dem Spieler einen anderen Spieler ein Leben zu nehmen, in dem er auf den gegnerischen Spieler springt. Dieser verliert danach ein Leben, bis er keine mehr hat. Dann scheidet er aus dem Spiel Lokales Spiel eröffnen Kurze Beschreibung Dieser Use Case ermöglicht es einem Benutzer ein lokales Spiel auf einem Computer zu eröffnen, in dem zwei bis vier Spieler insgesamt teilnehmen können. Bei einem lokalen Spiel agieren alle Mitspieler an einem Computer, dass heißt an einer Tastatur Flow of Events Basic Flow Der Use Case beginnt wenn im Hauptmenü die Option Lokales Spiel gewählt wird. Darauf erscheint eine Anzeige (siehe User Interface Prototype) zum Einstellen aller Spieler (siehe Spieler auswählen), der Map (siehe Map auswählen) und der zusätzlichen Optionen (siehe Optionen auswählen). Der Benutzer legt nun insgesamt 4 Spieler mit Namen und Charakter an, wählt eine Map und andere Optionen, wie Musik an und 6 Leben, aus und drückt auf den Startbutton. Dann startet das Spiel mit den entsprechenden Einstellungen Alternative Flows Eine alternative Möglichkeit ein lokales Spiel zu starten ist nicht nötig. Es können jedoch immer die Einstellungen variiert werden. -vertraulich- FH-Gießen-Friedberg, 2011 Page 8

9 User Interface Prototype Spieler auswählen Kurze Beschreibung Dieser Use Case erlaubt es dem Benutzer die Einstellungen für alle Spieler auszuwählen. Man kann verschiedene Tastaturbelegungen wählen, die Charakterfarbe und den Namen Map auswählen Kurze Beschreibung Dieser Use Case erlaubt es dem Benutzer die Map für das folgende Spiel auszuwählen. -vertraulich- FH-Gießen-Friedberg, 2011 Page 9

10 1.2.8 Optionen auswählen Kurze Beschreibung Dieser Use Case ermöglicht es dem Benutzer die zusätzlichen Optionen für ein Spiel einzustellen. Zu diesen gehören zum Beispiel: - Musik an/aus - Items - Anzahl der Leben Netzwerkspiel eröffnen Kurze Beschreibung Dieser Use Case erlaubt es dem Benutzer ein Netzwerkspiel zu eröffnen, in dem mehrere Spieler an jeweils einem Computer mitspielen können. Das Netzwerkspiel wird wie das lokale Spiel eröffnet, nur dass die Mitspieler sich selbst in das Spiel einklinken müssen (siehe Spiel beitreten) Spieler hinzufügen Kurze Beschreibung Dieser Use Case erlaubt es dem Netzwerkspieleröffner das Spiel freizugeben und andere Spieler hinzuzufügen beizutreten Netzwerkspiel beitreten Kurze Beschreibung Dieser Use Case erlaubt es dem Benutzer sich auf ein bereits freigegebenes Netzwerkspiel zu verbinden Eigene Map kreieren Kurze Beschreibung Dieser Use Case erlaubt es dem Benutzer eine eigene Map im Mapeditor zu schaffen, die später jeder Spieler, der die Map besitzt, benutzen kann Flow of Events Basic Flow -vertraulich- FH-Gießen-Friedberg, 2011 Page 10

11 Der Use Case beginnt wenn im Hauptmenü die Option Mapeditor gewählt wird, worauf dieser nun im Fenster angezeigt wird (siehe User Interface Prototype). Der Mapeditor hat automatisch eine leere Map geladen. Der Benutzer wählt zu erst ein passendes Hintergrundbild (siehe Hintergrundbild ändern) und danach ein Element in der Leiste und klickt im Raster der Map auf die Stelle an der das Element erscheinen soll (siehe Element platzieren). Diesen Vorgang wiederholt er so lange bis er mit seiner eigenen Map zufrieden ist. Als letztes speichert er seine neue Map ab (siehe Map speichern), um auf ihr spielen zu können Alternative Flows Der Use Case beginnt mit den gleichen Ereignissen wie im Basic Flow. Der Benutzer will eine alte Map bearbeiten und lädt diese in den Editor (siehe Map laden). Er löscht einige Elemente (siehe Elemente löschen) und setzt ein paar neue Elemente. Zuletzt speichert er die veränderte Map ab User Interface Prototype Map laden Kurze Beschreibung -vertraulich- FH-Gießen-Friedberg, 2011 Page 11

12 Dieser Use Case erlaubt es dem Benutzer eine bereits existierende Map in den Mapeditor zu laden um diese zu bearbeiten Map speichern Kurze Beschreibung Dieser Use Case ermöglicht es dem Benutzer seine Map im Editor auf die Festplatte zu speichern, damit sie ihm zur Verfügung steht Element platzieren Kurze Beschreibung Dieser Use Case erlaubt es dem Benutzer ein Element auszuwählen und im Mapeditorraster an einer ganz bestimmten Stelle zu platzieren Element löschen Kurze Beschreibung Dieser Use Case erlaubt es dem Benutzer ein bereits platziertes Element auf der Map mit einem Rechtsklick zu löschen Alle Elemente löschen Kurze Beschreibung Dieser Use Case erlaubt es dem Benutzer alle platzierten Elemente auf der Map zu löschen Hintergrundbild ändern Kurze Beschreibung Dieser Use Case erlaubt es dem Benutzer das Hintergrundbild der Map zu wählen oder zu ändern In die Highscoreliste eintragen Kurze Beschreibung -vertraulich- FH-Gießen-Friedberg, 2011 Page 12

13 Dieser Use Case erlaubt es einem Spieler die Ergebnisse des letzten Spiels in die Highscoreliste einzutragen Highscore anschauen Kurze Beschreibung Dieser Use Case erlaubt es dem Benutzer die Weltrangliste dieses Spiels im Internet anzuschauen. In die Bewertung eines Spielers gehen folgende Daten ein: - Genommene Leben - Verlorene Leben - Spieleranzahl - Zeit Zusätzliche Anforderungen Funktionalität This section lists functional requirements that are common to more than one use case. Fehleraufzeichnung Alle Systemfehler sollen aufgezeichnet werden. Fatale Systemfehler sollen zu einem sicheren Herunterfahren des Systems führen, um einen Datenverlust zu vermeiden Fehlermeldungen sollen neben einer Fehlerbeschreibung auch einen Fehlercode enthalten. Zudem soll erkennbar sein, wer Auslöser des Fehlers war. Alle Fehler sollen in einer Logdatei festgehalten werden. Benutzbarkeit Wartbarkeit Das System soll einfach zu warten sein. Windows Kompatibilität Das Spiel soll ab Windows XP laufen. Einfache Bedienung -vertraulich- FH-Gießen-Friedberg, 2011 Page 13

14 Leistung Das Spiel soll einfach zu bedienen und damit barrierefrei sein. Es soll intuitiv gespielt werden können, ohne eine Einweisung in das Spiel zu bekommen. Schneller Dateizugriff Der Speicher- bzw. Ladevorgang darf nicht länger als 5 Sekunden dauern. Auch das Laden neuer Maps darf max. 5 Sekunden in Anspruch nehmen. Hardwareanforderungen Das Spiel soll auf einem PC mit 1.3 Ghz oder mehr laufen. Es soll nicht mehr als 128 MB Arbeitsspeicher und 50 MB Festspeicher benötigen. Das Spiel soll unter Microsoft Windows XP und Windows Vista funktionieren. Netzwerkanforderungen Für den Multiplayer-Modus soll das Spiel an mindestens zwei PCs funktionieren, die über ein Netzwerk verbunden sind. Im Internetmodus dürfen die Anforderungen eine DSL-Verbindung mit 1 MBit/sec nicht überschreiten. Softwareanforderung Für eine fehlerfreie Nutzung soll Java 5 installiert sein. Instandhaltung Richtlinien der Programmierung Die Implementierung ist konform zu den Java Programmierrichtlinien. Verwaltungsbedingung Kosten Aufgrund von Finanzierungsbeschränkungen, dürfen keine Kosten entstehen. -vertraulich- FH-Gießen-Friedberg, 2011 Page 14

15 Lieferdatum Das Lieferdatum für die Grundfunktion darf das Semesterende nicht überschreiten. Designbedingungen Plattformunabhängigkeit Es muss plattformunabhängig und portabel sein. Java soll für die Implementierung genutzt werden. Die Swing Bibliotheken soll für die grafische Oberfläche genutzt werden. Der Software-Entwicklungsprozess soll konform zu RUP (Rational Unified Process) sein. Schnittstelle zu existierenden Systemen Es gibt keinen Bedarf an Schnittstellen zu existierenden Systemen. Benutzung von bekannten Technologien Hauptsächlich Nutzung von Java basierenden Technologien. Dadurch wird die Akzeptanz der Programmierer erhöht und das Auftreten von Fehler verringert. Benutzerdokumentations- und Hilfesystem-Anforderungen Benutzerhandbuch Das Benutzerhandbuch soll die Nutzung aus Sicht des Spielers beschreiben. Es soll beinhalten: Minimale Systemanforderungen Installation des Spiels am PC Spielprinzip Bedienungsanleitung Starten des Spiels Beenden des Spiels Benutzen des Mapeditors Alle Systemfunktionen -vertraulich- FH-Gießen-Friedberg, 2011 Page 15

16 Das Benutzerhandbuch soll als PDF vorliegen Installationsanweisungen, Konfigurationen und Read Me Datei Die Installationsanweisung soll beinhalten: Minimale Systemanforderungen Schrittweise Anweisungen Konfiguration spezifischer Paramater Die Read Me Datei soll enthalten: Versionsnummer Neue Funktionen Bekannte Fehler und Fehlerbehebung Beschriftung und Verpackung Da es sich bei der Software um ein Hochschulprojekt handelt, wird das Spiel nur in begrenzter Auflage gebrannt. Im Normalfall wird das Spiel zum Download bereitgestellt und benötigt daher weder Beschriftung noch Verpackung. -vertraulich- FH-Gießen-Friedberg, 2011 Page 16