software requirements specification - florian feuerstein · smash it! version: software...

FH-Gießen-Friedberg

Smash It!Software Requirements Specification

Version <1.1>

Smash It! Version: <1.1>Software Requirements Specification Date: <25.08.2011>

Revision HistoryDate Version Description Author

31.05.2009 1.0 Erste Version der SRS Florian Feuerstein

15.06.2009 1.1 Überarbeitung nach erstem Review Florian Feuerstein

24.09.2009 1.2 Überarbeitung nach Implementation Florian Feuerstein

-vertraulich- FH-Gießen-Friedberg, 2011


Index Einführung 4

1.1 Ziel 4 1.2 Umfang 4 Definitionen, Akronyme und Abkürzungen 4 Referenzen 4

Übergreifende Darstellung 5 Use-Case Model Übersicht 5

Genaue Anforderungen 6 Use-Case Beschreibungen 6

1.2.1 Multiplayerspiel spielen 6 1.2.2 Bewegen 7 1.2.3 Item einsammeln 7 1.2.4 Gegnerisches Leben nehmen 8 1.2.5 Lokales Spiel eröffnen 8 1.2.6 Spieler auswählen 9 1.2.7 Map auswählen 9 1.2.8 Optionen auswählen 10 1.2.9 Netzwerkspiel eröffnen 10 1.2.10 Spieler hinzufügen 10 1.2.11 Netzwerkspiel beitreten 10 1.2.12 Eigene Map kreieren 10 1.2.13 Map laden 11 1.2.14 Map speichern 12 1.2.15 Element platzieren 12 1.2.16 Element löschen 12 1.2.17 Alle Elemente löschen 12 1.2.18 Hintergrundbild ändern 12 1.2.19 In die Highscoreliste eintragen 12 1.2.20 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



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



Übergreifende Darstellung

Use-Case Model Übersicht



Genaue Anforderungen

Use-Case Beschreibungen

1.2.1 Multiplayerspiel spielen

1.2.1.1 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.

1.2.1.2 Flow of Events

1.2.1.2.1 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.

1.2.1.2.2 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.



1.2.1.3 User Interface Prototype

1.2.2 Bewegen


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.

1.2.3 Item einsammeln


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



1.2.4 Gegnerisches Leben nehmen


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.

1.2.5 Lokales Spiel eröffnen


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.



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.


Eine alternative Möglichkeit ein lokales Spiel zu starten ist nicht nötig. Es können jedoch immer die Einstellungen variiert werden.




1.2.6 Spieler auswählen


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.

1.2.7 Map auswählen


Dieser Use Case erlaubt es dem Benutzer die Map für das folgende Spiel auszuwählen.



1.2.8 Optionen auswählen


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

1.2.9 Netzwerkspiel eröffnen


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).

1.2.10 Spieler hinzufügen


Dieser Use Case erlaubt es dem Netzwerkspieleröffner das Spiel freizugeben und andere Spieler hinzuzufügen beizutreten.

1.2.11 Netzwerkspiel beitreten


Dieser Use Case erlaubt es dem Benutzer sich auf ein bereits freigegebenes Netzwerkspiel zu verbinden.

1.2.12 Eigene Map kreieren


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.





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.


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.


1.2.13 Map laden




Dieser Use Case erlaubt es dem Benutzer eine bereits existierende Map in den Mapeditor zu laden um diese zu bearbeiten.

1.2.14 Map speichern


Dieser Use Case ermöglicht es dem Benutzer seine Map im Editor auf die Festplatte zu speichern, damit sie ihm zur Verfügung steht.

1.2.15 Element platzieren


Dieser Use Case erlaubt es dem Benutzer ein Element auszuwählen und im Mapeditorraster an einer ganz bestimmten Stelle zu platzieren.

1.2.16 Element löschen


Dieser Use Case erlaubt es dem Benutzer ein bereits platziertes Element auf der Map mit einem Rechtsklick zu löschen.

1.2.17 Alle Elemente löschen


Dieser Use Case erlaubt es dem Benutzer alle platzierten Elemente auf der Map zu löschen.

1.2.18 Hintergrundbild ändern


Dieser Use Case erlaubt es dem Benutzer das Hintergrundbild der Map zu wählen oder zu ändern.

1.2.19 In die Highscoreliste eintragen




Dieser Use Case erlaubt es einem Spieler die Ergebnisse des letzten Spiels in die Highscoreliste einzutragen.

1.2.20 Highscore anschauen


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



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.

Leistung

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.



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



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.


software requirements specification - florian feuerstein · smash it! version: software...

Documents