Professional Documents
Culture Documents
Software Requirements Specification: by Car'eless
Software Requirements Specification: by Car'eless
REQUIREMENTS
SPECIFICATION
by car'eless
İrfan DURMAZ
Gürkan SOLMAZ
Erkan ACUN
2009
Table of Contents
1. Purpose of the Document....................................................................................................................3
2. Project Introduction............................................................................................................................ 3
2.1 Project Background.............................................................................................................................................3
2.2 Project Definition................................................................................................................................................4
2.3 Project Goals and Scope......................................................................................................................................4
3. The Process.......................................................................................................................................... 4
3.1 Process Model................................................................................................................................................... 4
3.2 Team Organization............................................................................................................................................ 6
3.3 Project Constraints............................................................................................................................................ 6
3.3.1 Project Schedule..............................................................................................................................................6
3.3.2 User Interactivity/Controls Constraint.............................................................................................................7
3.3.3 Realistic Game Play.........................................................................................................................................7
3.3.4 Realistic Scenes................................................................................................................................................7
3.3.5 Client Server.....................................................................................................................................................7
4. Research............................................................................................................................................... 8
4.1 Literature Survey and Technical
Analysis ...........................................................................................................8
4.1.1 Graphics...........................................................................................................................................................8
4.1.2 Sound............................................................................................................................................................... 9
4.1.3 Network......................................................................................................................................................... 10
4.1.4 Other Tools.................................................................................................................................................... 11
4.2 Existing System Analysis................................................................................................................................. 11
4.2.1 Quake Live.................................................................................................................................................... 11
4.2.2 Unreal.............................................................................................................................................................12
5. Requirements Specification..............................................................................................................12
5.1 Functional Requirements..................................................................................................................................12
5.1.1 Menu Requirements.......................................................................................................................................12
5.2 Non-Functional Requirements......................................................................................................................... 15
5.2.1 Usability.........................................................................................................................................................15
5.2.2 Quality............................................................................................................................................................15
5.2.3 Documentation...............................................................................................................................................15
5.2.4 Platform Compatibility...................................................................................................................................15
5.2.5 Reliability and Robustness............................................................................................................................ 16
5.3 Hardware Requirements................................................................................................................................... 16
5.4 Software Requirements.................................................................................................................................... 16
6. System Analysis and Modeling..........................................................................................................17
6.1 Structured Analysis and Functional Modeling................................................................................................. 17
6.1.1 Level-0 of Data Flow Diagram..................................................................................................................... 17
6.1.2 Level-1 of Data Flow Diagram(Client Side)..................................................................................................18
6.1.3 Level-1 of Data Flow Diagram(Server Side)................................................................................................ 20
6.2 Use Case Diagrams...........................................................................................................................................22
6.2.1 Start Menu Use Case ................................................................................................ ....................................22
6.2.1 Pause Menu Use Case................................................................................................................................... 23
7. Project Scheduling.............................................................................................................................24
7.1 Project Schedule .............................................................................................................................................. 24
7.2 Gantt Chart ...................................................................................................................................................... 25
8. Risk Management..............................................................................................................................26
8.1 Project Risks ................................................................................................................................................... 26
9.References...............................................................................................................................................
28
1. Purpose of the Document
Starting with introducing the project idea, presenting research on the idea and explaining the game
scenario, the document investigates functionality required in an implementation of the project, t
technical details to implement the project, flow of data and use cases. Estimated tasks and an expected
time-line for executing the tasks conclude the report.
2. Project Introduction
This chapter introduces the reader to the multiplayer online first-person shooter game for Linux
Project. A background to the project topic to put the idea into perspective is followed by project
definition. Then we explain why such an idea appeals us. Chapter is concluded by a discussion of what
is in scope
and what is not.
Networking among computer systems provides many opportunities for computer application. Internet is
the most massive and brilliant example of what networking can bring in. The advent of Internet has
radically changed the human society. Internet has become a component of some of the most basic
things we do. Information priorly restricted to few has been available to all. Communication became
cheap, time-efficient and available in more ways. Very structures of societies have been reshaped,
people are befriending and communicating with other people they have never seen, or could never see
in the old ways. Entertainment is enhanced and became more social in its own way. Internet is a huge
social phenomenon. Nevertheless it is a thing of technology based on networking hardware and
computer power. Its functionality is directly related to features and capacity of the technology.
Pioneering systems of the Internet used text based communication. More bandwidth, improved network
hardware, more CPU/GPU power and practically more of everything in later years meant more
information could be passed on and processed. This, of course, meant yet newer and more appealing
applications could be produced. Applications where hundreds, thousands or millions of users interact
doing various things. Games are no exception to the Internet effect. Multiplayer games have always
been present throughout computing history, but everything became greater in scale and more
diverse in players. Multiplayer FPS games are one of the most popular ones.
First Person Shooter (FPS) is a video game genre which centers the gameplay around gun- and
projectile weapon-based combat through the first person perspective; i.e., the player experiences the
action through the eyes of a protagonist. Generally speaking, the first-person shooter shares common
traits with other shooter games, which in turn fall under the heading action game. From the genre's
inception, advanced 3D or pseudo-3D graphics elements have challenged hardware development, and
multiplayer gaming has been integral.
Most first-person shooter games have multiplayer mode, where a lot of users play against other human
players. This mode is very popular in the world, because people usually find playing with boats boring.
Although there are some games with good artificial intelligence, multiplayer games are more enjoyable
and realistic, because human brain is still better than artificial intelligence. The increasing multiplayer
game trend caused developing a lot of fps games based on multiplayer feature by different game
companies.
The fundamental goal of this project is to build a multiplayer online game that:
is enjoyable.
is ready for commercial release.
has potential for commercial viability.
can support hundreds of players in a single environment. *
supports large maps.
offers 3D graphics.
offers a 3D environment.
has sound effects.
approximates physics in some aspects.
has a low server load.
has a low bandwidth requirement.
uses peer to peer network model as much as possible.
uses dynamic server side load distribution.
is well documented.
The project goals do not include:
cross-platform compatibility.
building a well defined framework.
to implement AI routines from scratch.
The implementation goal is:
* open-source multiplayer fps for Linux
to implement network functionality from ground up using low level tools.
to implement 3D graphics environment using a game engine.
to implement sound effects using a game engine.
client to other client's communication, interaction and positioning.
3. The Process
3.1Process Model
As we will do the project in the content of Ceng491 course, requirements and the design parts
of the project will be improved sequentially and they will be completed by the end of first
term.
Therefore, we cannot use any incremental or evolutionary model. Also, requirements are well‐defined
and reasonably stable so there will be limited number of new development efforts in the project. We
will try to make a realistic and safe requirements analysis so that we will have a robust design, which
will prevent us from returning back to design phase. Taking all of these into consideration, waterfall
process model is the most appropriate model for our project. However, there will be some
modifications in this model such that coding, testing‐debugging and integration will be performed
in one phase under the name ‘construction’, as seen in Figure 1.
Figure 1 ‐ Modified Waterfall Model
Our product is targeted to be used by people having no or very little knowledge of computers.
Therefore, there will be two modes of the simulation; one with limited interactions with the program
and one with very detailed interactions. In the first mode, user will perform his actions only
by microphone. On the second one, however, user will be making all his actions by directly interacting
with the program by keyboard.
Since we are developing a simulation environment, we need our program to be as realistic as possible.
Users should face real emergency situations, and should come up with solutions using their
limited resources as in real life. Simulating this on computer is not an easy task; both
graphically and conceptually. Also to not end up with mis-training and faulty evaluation of user
performances, we have to design the game play very carefully.
Quality of 3D graphics, models, textures, sound and animation will make our simulation look more
realistic, while costing a considerable amount of disk space and intensive processing.
3.3.5 Client-Server
data transfer between client and server will be optimized to fasten the communication.
secure client-server communication and system security.
4. Research
4.1 Literature Survey and Technical Analysis
To find the most suitable tools and environments for our application, we made an all‐round
research related to different fields of our application.
4.1.1. Graphics
We made a wide research with respect to graphics part, as it is thought to be the most
challenging and time consuming part of the project. We decided to use a graphics rendering engine for
modularity and ease of writing code. The engines chosen to be examined are given in details
in the following subsections.
4.1.1.1 Crystal Space
This is a framework rather than a simple rendering engine. It has modules for 2D and 3D
graphics, sound, collision detection and physics. However, it is not appropriate for our project
in two reasons. Firstly, its documentation and developer support is not very satisfactory. Secondly, an
all‐in‐one engine including all kind of features is not appropriate for our project’s needs. We thought it
would restrict us in terms of functionality. Instead, we intend to use different API's/engines specialized
in its own area.
4.1.1.2 Java 3D
As we had not decide about the programming language, we examined both kind of engines
written in C++ and Java. Java3D is one of the few rendering engines written in Java. Java3D
Project, running under Java Community Process, does not seem to be developed very
professionally. Its documentation is poor and the demos do not attract much. We also searched for the
games written in Java3D such as Law and Order 2, Pernica, Roboforge and Flying Guns. From those,
only Law and Order 2 made a considerable profit out of market. As Java3D does not seem to satisfy our
needs, we had to give up on it.
4.1.1.3 Ogre
Within all the graphics engines we have searched, Ogre was the most impressive one. It is a
scene‐oriented, hardware accelerated 3D engine. Ogre would be useful for us in many respects.
Firstly, it has an active community contributing to the project, in case of any problem with the engine
such as a bug, or a confusing way, one can easily get an answer to his questions from its
developers in the forums. Also, Ogre has quite a rich documentation including the Project
Ogre Wiki where one can find code, tutorials, art tutorials and many examples. Also the book
“Pro Ogre 3D Programming by Gregory Junker” is dedicated to teach new users the fundamentals of
using Ogre. Secondly, Ogre’s being scene‐graph‐based makes it very appropriate to develop a 3D
application rich in objects. Scene graph data structure makes it easier to arrange the logical
representation of a graphical scene. It helps the programmer to define logical relations between the
objects (entities) which correspond to the nodes in the graph.
Although Ogre is not an all‐in‐one solution in terms of game development or simulation, it is
compatible with many external add‐ons, tools and libraries. This gives freedom to us to use whatever
input, audio and scripting libraries we want.
4.1.1.4 Ogre4J
Ogre4J is a project that enables the use of Ogre libraries in Java applications. As Java is
considered as the alternative programming language, Ogre4J seemed quite appropriate at first
sight. However, it is a new project and it is strongly possible that it includes bugs which would be very
difficult for us to deal with in the process of implementing the project. As we cannot take
such kind of risk, Ogre4J is not suitable for this project.
4.1.2. Sound
Our criteria for sound libraries are: platform independency, free license, 3D audio, recording and
documentation support. Suitable sound libraries for our project are listed and briefly described
in subsections between 4.1.2.1 and 4.1.2.3.
4.1.2.1 OpenAL
It works on both Windows and Linux and mainly free under LGPL. It supports 3D audio and
suitable for game applications. Functions for recording sound also exist. OpenAL consists of
low‐level functions. Furthermore, there is a high‐level utility library called ALUT similar to
OpenGL‐GLUT.
Documentation of the library is sufficient and active forums exist. It is used by most of the well‐known
game engines such as Unreal Engine, Torque Engine, Delta3D Engine and Doom3 Engine.
4.1.2.2. FMOD
It is available for both Windows and Linux. It is commercial, but free for non‐commercial
use. FMOD supports 3D sound, and many audio formats such as midi, mp3, ogg vorbis. In
addition, it supports recording, Internet streaming and sound effects. Documentation is sufficient.
Furthermore, FMOD is actively developed, with regular releases of new features. Some famous game
companies like Blizzard, Microsoft, Activision and NVidia are in the customer list of FMOD.
Moreover, it has a sound manipulation tool called FMOD Designer. However, it is only available for
Windows.
4.1.2.3 jVoiceBridge
The voice bridge is software written in the Java Programming Language that handles Voice over IP
(VoIP) audio communication. Also, it mixes tasks such as conference calls, voice chat, speech
detection, and audio for 3D virtual environments. In addition, it can be used as a component of other
applications, i.e. Project Wonderland. It is available for both platforms – Windows and Linux‐ by
taking advantage of Java programming language. Negative aspect for this library is poor
documentation support.
4.1.3. Network
4.1.3.1 Raknet
It is suitable for Windows and Linux; free for non‐commercial use. It is Ogre‐compatible and
preferred in a quite number of Ogre projects. It is a networking API that is for reliable UDP and higher
level functionality. It allows any application to communicate with other applications on the
same computer, over a LAN, or over the Internet. It was developed specifically for development
of online games and the addition of multiplayer to single player games. It provides detailed
reference and tutorials.
4.1.3.2. ZoidCom Automated Network System
This library is also platform independent and free for non‐commercial use. It is a high‐level,
UDP‐based networking library providing features for automatic replication of game objects and
synchronization of their states over a network connection. The project has extensive documentation and
lots of example programs.
4.1.3.3. Project Darkstar
It is a developing project which is supported by Sun Microsystems and its aim is to develop a reliable,
scalable, and fault tolerant system for low‐latency, high‐interactivity online content. Its primary target
is Massively Multiplayer Online Game content but it is also used in small group online games. The
project is written in Java Programming language so it is system independent. It is a new project and it
develops actively. For this reason, it may be risky to use. However, it is used in Project Wonderland.
This project encapsulates many different disciplines. It is similar to games as it involves features
such as 3D programming, multiplayer playing, and audio communication between users. It is similar to
simulators as it involves an education purpose and simulates a real environment and a realistic scenario.
Therefore, we searched for both multiplayer games and simulators. The games and the simulations
examined are given in following sections.
4.2.2. Unreal
Unreal is a first‐person shooter game which is considered to be technically superior to most of the
games in market. It has multiplayer support with strong network architecture. Due to its technical
capabilities and developer support, we examined it as a model for the project. Unreal is considered to
be the pioneer in many areas in game development. It has strong graphics capabilities and very efficient
network architecture. In the network architecture, generalized client server architecture is used rather
than monolithic server architecture used in other games such as Quake and Ultima Online. Unreal
implements a more efficient way for the network architecture with the help of game state concept. In
this concept, clients’ game engines also deal with the game logic instead of just sending the input to
network and getting the output from network. Also its network architecture has an intelligent side as it
makes predictions about the coordinates of the objects with the help of current coordinates and
trajectories.
5. Requirements Specification
Main Menu:
1. Language Selection
2. Select User
2.1. New User
2.2. Enter Username and Password
3. New Game
3.1. Create
3.1.1. Mode Selection
3.1.2. View Online Users
3.1.3. Start Game
3.1.4. Cancel
3.2. Join
3.2.1. Enter IP Address
3.2.2. Character Selection
3.2.3. Send Message (Chat with others)
3.2.4. View Online Users
3.2.5. Start
3.2.6. Cancel
4. Learn to Play
5. Options
5.1. Audio Settings
5.2. Microphone Settings
5.3. Graphics Settings
5.4. Controls Settings
6. Statistics
6.1. View Performance Of User
6.2. View Performance Of Team
7.Exit Game
Pause Menu:
1. Resume Game
2. Options
2.1. Audio Settings
2.2. Microphone Settings
2.3. Graphics Settings
2.4. Controls Settings
3. View Resource Details
4. Statistics
4.1. View Performance of User (Current game performance)
4.2. View Performance of Team
5.Exit Game
5.2.1. Usability
Being an education tool, our program will be used by the trainees including both experienced and
inexperienced computer users. Taking this into consideration, we try to design human‐program
interaction as clear as possible. The program is aimed to be easy to learn and satisfying to use. In this
respect, we follow a user‐centered design paradigm keeping the users’ needs in mind all the time.
5.2.2. Quality
Quality of the design and quality of conformance to this design is one of the major requirements of the
project’s development. The phases should be completed in certain time and the resulting software
should be free from the bugs as much as possible. Also it should be user‐fault‐tolerant to provide a
user‐friendly environment.
5.2.3. Documentation
The recorded audio data are sent to other users over the network module. Similarly, other users’
recorded audio data are transferred over network module to audio module of the client. Input handler
evaluates the keyboard and mouse inputs and sends the data that will affect all users of the program to
server via network module. The data that affect only the user like menu commands are sent to game
engine by input handler. On the other hand, the game state coming from server is passed over network
module to game engine. Game engine then sends the information about sound data to audio module and
audio module gets the corresponding audio data from repository. Like audio module, graphics module
gets the information about graphics data from game engine and gets the data itself from repository.
Figure 3 ‐ Level 1 Data Flow Diagram (Client Side)
6.1.3. Level 1 of Data Flow Diagram (Server Side)
Level 1 of data flow diagram for server side is given in Figure 3. The diagram is very similar to the one
for client side. However, there are minor differences. Server is the decision centre of the program and
the real game state is stored in the server. Other client machines have approximate game states, so
server continuously sends game state to clients and the clients updates their data accordingly. Also,
server gathers all the requests from users about the game flow, and makes decisions about flow by
using script engine.
Figure 4
6.2. Use Case Diagrams
6.2.1 Start Menu Use Case
6.2.2. Pause Menu Use Case
7. Project Scheduling
7.1 Project Schedule
To schedule our project, we first needed to identify main tasks and subtasks in the
project. Also, determining relationships between subtasks was important to make a
consistent schedule. While assigning start and finish dates for the tasks, we tried to
distribute the workload in time equally so that we would never fall behind the schedule.
Following the schedule, we will manage our time efficiently and in the meantime, finish
all tasks in the specified time interval. Task assignment is done considering team
members' interests and skills. Also equal distribution of workload among team members
was taken into consideration. We grouped our tasks into 8 main groups. Documenting our
project, analyzing development tools and developing game concept are the main tasks we
schedule to complete this semester. Tasks related to game resource production and
implementation are planned to be started and finished next semester. Specifically, these
tasks are divided into groups such as game resource & game art production, graphics &
audio development, network development, game logic development and game
deployment and testing.
7.2 Gantt Chart
8. Risk Management
Risk management is a key issue for completing a project successfully in time. Having a
plan before hand would certainly decrease the impact of a risk. As the subject of the
project is mainly about saving human life, it is risky by nature. The people who are using
this simulation program are always faced with challenging conditions involving risk.
Their each decision may result in many people’s death or survival. Therefore, training of
them also involves risk. Implementing the project successfully is crucial in this sense.
Requirements should be understood very well. The pathways that the user will choose
should not cause him to be trained incorrectly and the application should evaluate the
user correctly. Especially for this project, not achieving those criteria are possible and
hazardous risks. Therefore, we try to do a detailed risk plan and avoid the possible risks
as much as possible.
• Used technology’s being defective, halfway or incompetent: In the project, mainly open
source tools and environments are used. If those are not examined carefully at the
beginning, project team could face with many problems such as bugs, halfway
components, etc… and this would definitely slower the project for no reason.
• Use of complicated technology: Especially for game programming, there are lots of
libraries, engines and tools. Although they could be quite useful, learning to use them is
another big task. Getting stuck with those could result in hazardous delays in the project.
9. References
http://unter-hund.com/2009/01/24/top-10-linux-games-fps/
http://en.wikipedia.org/wiki/First-person_shooter
http://www.ogre3d.org/
http://www.unrealtournament.com/
http://www.enemyterritory.com/