SOFTWARE

REQUIREMENT
SPECIFICATION
By S.H.A.R.D

Muhammad Arslan 201298

Sheraz Ahmed Chishti 201240
Maratib Ali 201324
Muhammad Saad 201256
Hassaan Tahir 201276
 Page | 2

Table of Contents
0. Revision Table ...........................................................................................................................................3
1. Purpose of Document ...............................................................................................................................3
2. Project Introduction .............................................................................................................................3
2.1. Project Background .........................................................................................................................4
2.2. Project Definition .........................................................................................................................4
2.3. Project Goals and Scope .............................................................................................................4
3. The Process ..................................................................................................................................................5
3.1. Process Model .....................................................................................................................................5
3.2. Team Management ................................................................................................................................6
3.3. Project Constraints.......................................................................................................................6
3.3.1. Project Schedule .....................................................................................................................6
3.3.2. User Interactivity ................................................................................................................6
3.3.3. Interesting Game Play .........................................................................................................6
3.3.4. Breathtaking Scenes ..............................................................................................................6
4. Research ..........................................................................................................................................................6
4.1. Literature Survey and Technical analysis ....................................................................7
4.1.1. Graphics ........................................................................................................................................7
4.1.2. Sound API ......................................................................................................................................8
4.1.3. Network...........................................................................................................................................9
4.1.4. Other tools .................................................................................................................................9
4.2. Existing Solutions .........................................................................................................................9
4.2.1. Super Mario 3D ..........................................................................................................................9
4.2.2. Pokémon Games ......................................................................................................................... 10
5. Requirements ............................................................................................................................................. 10
5.1. Functional Requirements: ........................................................................................................ 10
5.2. Non-Functional Requirements: .............................................................................................. 11
6. Use Cases .................................................................................................................................................... 11
6.2. Use Case Diagram ........................................................................................................................... 11
6.3. Hardware Diagram ........................................................................................................................... 12
6.4. Use Case Tables ............................................................................................................................. 13
7. Project Scheduling ............................................................................................................................... 19
7.1 Gantt Chart ......................................................................................................................................... 19
 Page | 3

8. Risk Management ...................................................................................................................................... 19

8.1. Project Risks .................................................................................................................................. 19
8.1.1. Staff Size and Experience ............................................................................................ 20
8.1.2. Customer Characteristics ............................................................................................... 20
8.1.3. Project Parameters ............................................................................................................. 20
8.1.4. Development Process ........................................................................................................... 20
8.1.5. Development Environment ................................................................................................. 20
9. References .................................................................................................................................................. 20

0. Revision Table

# DATE DESCRIPTION
REVISION 0 27-03-2021 First attempt at making an SRS Document.

REVISION 1 03-04-2021 Updated use case diagram of section 6.2.

1. Purpose of Document

This software requirements specification has tried to provide a complete

description of all requirements of our game named “Adventures of Novo:
Oubliette”. The requirements proposed in this document will serve as a
guideline throughout the development process of this project. We began
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, the system analysis, and
use cases. In the end the estimated task and the expected time to
execute the task is mentioned.

2. Project Introduction

This chapter introduces the reader about the RPG (Role Playing Games).
In introduction, first project background is discussed and then project
definition is discussed. Then we explain why such an idea appeals us.
 Page | 4

Intro is concluded by a discussion of what are its scopes and what is

not in its scope.

2.1. Project Background

As with the advent of modern era of games and multimedia the 2D games
plays the very important role. No matter how long it’s been since the
first game released, 2D games have always been fun to play and are a
reminiscent of retro artwork. Even in the year 2021 we see various 2D
games emerge in the form of action RPG or platformers. The basic purpose
of this project is to analyze study and understand the basic of game
development to make a game. So, for that purpose the foremost step which
is the core of game development need to be researched a lot.

2.2. Project Definition

RPG stands for “role playing game”, RPGs come in various types such as
2D, 3D, Platformer, 2.5D, First person, Third person, etc. The main
concept behind all of them are the same, we play as a fictional character
in the game to advance and learn about the plot.

Some RPG games have multiplayer mode, in which they can interact and
play with other people (and even friends). This mode is usually very
popular because the series of actions are always random. In campaign
(single player or default mode), the series of action are pre-written
and can get boring really fast.

2.3. Project Goals and Scope

This goal is to make a game that:

 Is based on a 2D level design.

 Is playable by a wider audience.
 Has good story.
 Has sound effects.
 Has visual effects.
 Has AI built-in.
 Has good documentation.
 Has low system requirement.
 Page | 5

 Is most importantly, enjoyable.

The goals do not include:

 Cross platform support.

 Coding an engine from scratch.
 Designing for proprietary hardware.

3. The Process

3.1. Process Model

Since all requirements are predefined, we do not need to make any

further changes to this setup. Hence, we will be using a modified
version of the waterfall model with only four steps. The figure for
this model is shown below:

Requirement
Specification

Story, Plot
and Design

Coding and
Building

Deployment
 Page | 6

3.2. Team Management

With only 5 members, there is no need for a team leader. All members
will be able to make decision. In our model all members would contribute
and come up with innovative ideas.

3.3. Project Constraints

3.3.1. Project Schedule

The said project is very tedious and time taking, so we have allocated
about 16 Weeks, or almost 4 Months to complete and publish this game.
During this process the team members will also be learning about all
the different aspects of game development.

3.3.2. User Interactivity

Our game is intended to be used by people that have very basic knowledge
of using computers. Our user will interact with the game using basic
keyboard and mouse inputs. The only requirement is that they must
understand English.

3.3.3. Interesting Game Play

Since our game is 2D based, we have to make it as interesting as possible

so that the user can indulge and enjoy the story the game has to offer.
This is not an easy task as making a good story not only requires good
computing skills, but also very good narration skills. So, doing this,
we have to be very careful to not end up mis-training our users.

3.3.4. Breathtaking Scenes

Our level designs need to be top notch if we want to have any chance of
making this a good and enjoyable experience for our users. We also need
to make sure the textures are well optimized to consume minimal disk
space.

4. Research
 Page | 7

4.1. Literature Survey and Technical analysis

We spent a lot of time and resources to find out what rendering engines
and APIs were best suited for our application.

4.1.1. Graphics

After researching for an extensive period about the graphics, which

turned out to be the most challenging part of the document, we deduced
which engines were best suited and easy to use. The engines and APIs
are given in the following subsections:
4.1.1.1. Unreal Engine 4

This engine is the most used engine out there, boasting over 15 top
selling titles across all genres. This is also a fairly easy to use
rendering engine as it is operated using C++. I think this engine paired
with good APIs and a third-party modeling software would provide easy
coding and well rendering. Since it has a very high royalty fee, we
didn’t this this was viable.
4.1.1.2. Java Engine

By using JAVA to manually create a proprietary engine for the sake of

game seems like a lot of work, although it can be beneficial in the
sense that it will be designed to work flawlessly with the game. However,
a lot of existing solutions offer much better and easier features so
this option was set aside.
4.1.1.3. Unity Engine

A fairly easy to use rendering engine that is operated using C#. This
engine has been used for games such as Assassin’s Creed, Deus Ex and
Rust. All three of these games are in the dominating market for user
satisfaction regarding fluidity and beauty of the renders. It can also
be used with third party APIs to make work easier.
4.1.1.4. GODOT Engine

This engine is balanced for 2D games like the one we are aiming for. It
has a lot of easier to use models and features that can be manipulated
 Page | 8

using either Python, C++ or C#. The texture-based rendering system also
allows us to auto generate terrain and control animation with side
scripts. Since it allows for a lot of flexibility and ease of usage,
this was the one we settled for.
4.1.1.5. Metal API

Metal engine is an API used by Apple. It will allow us to port our

project over to MacOS and allow users to run our software on a non-
windows environment. This might be beneficial since it means there
would be a wider audience. But since games on MacOS aren’t very popular,
we have to scrap this idea.
4.1.1.6. DirectX API

Amongst all the other APIs, this is the most used one since almost all
Windows based games use it, however the optimization is very poor hence
the rendering engines can never take advantage of the complete hardware.
Albeit being easy to implement, we gave up on this.
4.1.1.7. Vulkan API

This API is fairly new and is used in most recent titles used released
after 2019, including but not limited to Dota 2, Doom, Warzone, Rainbow
6 Siege and Ashes of the Singularity. It provides much smoother
experience than DirectX and has better hardware level control. We think
this would be a better option for our project.

4.1.2. Sound API

Since sound is an important part of a game, allowing a person to be

aware of their surroundings, we had to decide which library and API was
best suited, here are the libraries, we researched:
4.1.2.1. OpenAL

This is an open-source, cross-platform audio API that is free to use

and suitable for game applications. It has good documentation and a lot
of utilities. It is also used by well-known game engines such as Unreal
Engine 4, Unity, etc. However, it doesn’t have good optimization and
control, so we gave up on it.
 Page | 9

4.1.2.2. SDL

SDL is a well-known API that has many useful audio features, it is also
useable with many game engines and rendering engines. The only downside
is that the code is fairly long and it be overwhelming. The interface
is also not very optimized. Hence, this was not optimal.
4.1.2.3. SFML

The SFML is an alternative to SDL and is much easier to use, the commands
are more streamlined and code is easier to write. When armed with
plugins such as FMOD, this can be a very powerful and easy tool to
implement in our project.

4.1.3. Network

This game will not include a multiplayer mode, so at the moment, having
proper networking to transfer between the game and server is not
required, although modern game engines such as Unreal and Unity already
have very good multiplayer APIs for connection to servers. If needed in
the future we can use UDP protocol offered by publishers such as Steam
and EA (Origin).

4.1.4. Other tools

1. Maya or blender will be best for making 3D scenes, along with some
2D figures and terrain.
2. Adobe Photoshop can be used for texture generation
3. Any IDE will suffice as long as it supports the programming
language.
4. For text editors, we can use the built-in ones in the game engines.

4.2. Existing Solutions

We can use existing games as examples, as they also involve 3D aspects,

multiplayer and audio-based communication between players. We won’t be
using all the modules, but we can take inspiration from them. The games
we examined are described below:

4.2.1. Super Mario 3D

 P a g e | 10

Released early 2021, this game is a 2D platformer that shows us the

perfect work case and depicts the motions and mechanics put into place
since 1985. Albeit a classic, this game can still be used as a reference
for our project.

4.2.2. Pokémon Games

Almost all Pokémon games released on the switch and the 3DS are open
world and 2D + 3D mixed action games. Using similar art style and semi-
3D model, we can make our game more attractive and polished.

5. Requirements

5.1. Functional Requirements:

• Menu: A menu screen where user can select either to start or exit
game.

• Player Sword Attack: The player attacks when the left mouse key
is pressed.

• Player Gun Attack: Player shoots a projectile at the location where

the user right clicks the mouse button.

• Player Special Gun Attack: Player shoots a projectile at the

location where the user long right clicks the mouse button. But the
bullet damage is more than the normal gun attack.

• Gun Damage: Any Entity that is present at the bullet/projectile

location it gets hurt by the damage value of that gun.

• Door: There are invisible door objects place at the borders of

game, which take the player to the next room when player collides with
it.

• Slime (Mob): There are slime enemies in game which follow the
player, if the player is inside the radar radius of the slime.

• Bat (Mob): Bat enemies move left and right and attacks a projectile
if the player is inside the radar radius of bat.

• Player Damage: Player gets hurt when it touches any enemy.

 P a g e | 11

• Coins (Item): There are coins inside some rooms which player can
pick.

• Potion (Item): There are potions inside some rooms which player
can pick, and increases the player health by a certain fixed amount.

• Boss (Mob): The boss moves left and right and can only shoot big
projectiles which cause the most damage than any projectile in game.
The attack radius of boss is largest and can shoot no matter where the
player is.

• Restart: Player Restarts from the first room when he dies.

5.2. Non-Functional Requirements:

• HUD: The player’s Health and Coin count should always be displayed
on screen.

• Level Transition: There should be a screen before the start of

every that displays the level name.

• Projectile Sprite: The sprites for each projectile should be

different.

• Game End: When the game ends, there should be a screen that shows
that ‘Game Ended’ and asks for user input to return to menu screen.

• Pause: The player presses the escape button to pause the game and
can resume it by pressing the same button.

6. Use Cases
6.2. Use Case Diagram

The use case diagram for all possible scenarios is given in the table
below:
 P a g e | 12

Game : Adventures of Novo: Oubliette

Close Game <<extend>> Pause Level <<extend>> Restart

<<extend>>

Start Level <<include>> Show Health

Move Around <<extend>> Get Items <<include>> Win Game

User
<<include>>
<<extend>>

Use Weapons <<extend>> Kill Mobs Lose Game

<<extend>> <<include>>

Get Killed

6.3. Hardware Diagram

Output to Monitor
Game and
Hard Drive
Texture Files

Rendering

Graphics
Card Sound Output
User Input
From mouse and
keyboard

Speakers
 P a g e | 13

6.4. Use Case Tables

USE CASE ID M_01

USE CASE NAME Close Game

DESCRIPTION Allows us to close the application

ACTORS User

TRIGGER Close button shown on screen

PRECONDITIONS Application is running

POSTCONDITIONS Application is no longer running

NORMAL FLOW Run Application -> Close Game -> Close Application

EXCEPTIONS Application is not running

ASSUMPTIONS User can use mouse and understand English

USE CASE ID M-02

USE CASE NAME Pause Level

DESCRIPTION Game will be paused

ACTORS User

TRIGGER Pause button

PRECONDITIONS Level is loaded

POSTCONDITIONS Game is paused

NORMAL FLOW Start Level (M-03) -> Pause Level

EXCEPTIONS Level isn’t loaded

ASSUMPTIONS User can use mouse and understand English

 P a g e | 14

USE CASE ID M_03

USE CASE NAME Start Level

DESCRIPTION Level will be loaded

ACTORS User

TRIGGER Start button

PRECONDITIONS Game is running

POSTCONDITIONS Level will be loaded

NORMAL FLOW Start button -> Level Loaded

EXCEPTIONS Game isn’t running

ASSUMPTIONS User can use mouse and understand English

USE CASE ID M_04

USE CASE NAME Move Around

DESCRIPTION Player will Move around the level

ACTORS Player

TRIGGER Arrow Keys

PRECONDITIONS Level is loaded

POSTCONDITIONS Player Moved

NORMAL FLOW Start Level -> Move Around

EXCEPTIONS Level isn’t loaded

ASSUMPTIONS User can use keyboard

 P a g e | 15

USE CASE ID M_05

USE CASE NAME Use Weapons

DESCRIPTION Guns will be triggered or Sword will be used

ACTORS Player, Gun, Sword

TRIGGER Left Mouse Button, Right Mouse Button

PRECONDITIONS Level is loaded

POSTCONDITIONS Weapon will be used

NORMAL FLOW Left/Right Mouse Button Press -> Weapon Used

EXCEPTIONS Buttons aren’t pressed, level isn’t loaded

ASSUMPTIONS User can use mouse

USE CASE ID E2

USE CASE NAME Restart

DESCRIPTION User will restart level

ACTORS User

TRIGGER Restart button

PRECONDITIONS Level is loaded, pause level is selected

POSTCONDITIONS Level is restarted

NORMAL FLOW Start Level -> Pause Level -> Restart

EXCEPTIONS Button isn’t pressed, level isn’t paused

ASSUMPTIONS User can use mouse and understand English

 P a g e | 16

USE CASE ID I3

USE CASE NAME Show health

DESCRIPTION Health will be shown on screen

ACTORS User

TRIGGER Start Level

PRECONDITIONS Level is loaded

POSTCONDITIONS Health status will be shown on screen

NORMAL FLOW Start Level -> Show health

EXCEPTIONS Level not loaded

ASSUMPTIONS Nil

USE CASE ID E4

USE CASE NAME Get Items

DESCRIPTION Earn Coin OR Get potions

ACTORS Player, Coin, potions

TRIGGER Move over coin or potions

PRECONDITIONS Level is loaded

POSTCONDITIONS Player gets item

NORMAL FLOW Move around -> Get coin OR Move around -> Get potions

EXCEPTIONS Level not loaded OR player hasn’t moved

ASSUMPTIONS User can use keyboard

 P a g e | 17

USE CASE ID E4E5

USE CASE NAME Kill Mobs

DESCRIPTION Player will fight mobs

ACTORS Player, Mobs

TRIGGER Movement Buttons, Right/Left Mouse Button

PRECONDITIONS Level is loaded

POSTCONDITIONS Player wins the game

NORMAL FLOW Move Around -> Use Weapons -> Kill Mobs

EXCEPTIONS Level not loaded

ASSUMPTIONS User can use keyboard and mouse

USE CASE ID E5

USE CASE NAME Get Killed

DESCRIPTION Player killed by Mobs

ACTORS Player, Mobs

TRIGGER Movement, Gun, Sword usage

PRECONDITIONS Player moves near Mobs in loaded level

POSTCONDITIONS Player dies due to damage

NORMAL FLOW Move Around -> Player Dies

EXCEPTIONS Level not loaded OR player hasn’t moved

ASSUMPTIONS User can use keyboard and mouse

 P a g e | 18

USE CASE ID END_POS

USE CASE NAME Win Game

DESCRIPTION Player Wins the game

ACTORS Player AND (ITEMS OR MOBS)

TRIGGER Movement OR (Gun AND Sword usage)

PRECONDITIONS Player collects items OR kills Mobs

POSTCONDITIONS Win Game screen shows

NORMAL FLOW items collected -> Win Game OR Mobs killed -> Win
Game
EXCEPTIONS Level not loaded OR player hasn’t moved

ASSUMPTIONS User can use keyboard and mouse

USE CASE ID END_NEG

USE CASE NAME Lose Game

DESCRIPTION Player loses the game

ACTORS Player, Mobs

TRIGGER Player gets killed by Mobs

PRECONDITIONS Player fights Mobs

POSTCONDITIONS Player dies and Loses

NORMAL FLOW Player killed by Mobs -> Player loses game

EXCEPTIONS Level not loaded OR player hasn’t fought Mobs

ASSUMPTIONS User can use keyboard and mouse

 P a g e | 19

7. Project Scheduling

We separated the main tasks and subtasks of our project to make a simple
and consistent schedule. To make sure we don’t fall behind due dates,
we assigned start and finish dates. All of this is made according to
the team members interest and skills. This schedule is presented in the
form of a Gantt chart shown below:

7.1 Gantt Chart

8. Risk Management

The key or main issue for completing a project successfully in time is

Risk management. By creating a plan beforehand would certainly decrease
the impact of a risk. As the subject of the project is a game so it is
not that risky by nature. The most common risks are of bugs and glitches
in game. Requirements should be understood very well to implement the
project successfully. The pathways that the user will choose should not
cause him to be trained incorrectly and the application should evaluate
the user correctly.

8.1. Project Risks

 P a g e | 20

8.1.1. Staff Size and Experience

 Experience with involved tools is important. If staff members

skipped semesters, they would require additional training which
would take extra time.
 Minor roles are easy to forget so they are not to be
underestimated and overlooked.
 Lack of responsible team members could affect the schedule and
cause problems in meeting project deadlines.

8.1.2. Customer Characteristics

If the customers are unsure or doubtful about the requirements, we

will have to redefine the project design otherwise change the project
layout if they are dissatisfied.

8.1.3. Project Parameters

The project will be made with a good base level hardware specification.
Being 2D, it will require low amount of compute power. So, a GT730 and
an i3 2120 should be able to play this game without any issue, given
that DirectX 11 is used.

8.1.4. Development Process

The development phase must have quality checks throughout the process
for a satisfactory and efficient result. Thorough testing and
compatibility reports are mandatory for the game to be playable for a
greater audience.

8.1.5. Development Environment

Using updated IDEs with newer environment and latest API versions would
be much more beneficial as it would result in minimum number of bugs.
The number of bugs is directly proportional to how old the APIs and
environments are.

9. References

1. https://www.unrealengine.com/en-US/
 P a g e | 21

2. https://www.java.com/en/
3. https://unity.com/
4. https://godotengine.org/
5. https://developer.apple.com/metal/
6. https://www.microsoft.com/en-pk/download/details.aspx?id=35
7. https://www.khronos.org/vulkan/
8. https://openal.org/
9. https://www.libsdl.org/
10. https://www.sfml-dev.org/
11. https://www.blender.org/
12. https://www.autodesk.com/products/maya/overview
13. https://www.adobe.com/products/photoshop.html
14. https://supermario3dworld.nintendo.com/
15. https://www.nintendo.com/games/detail/pokemon-sun-3ds