SRI JAYACHAMARAJENDRA (GOVT.

) POLYTECHNIC
Department Of Computer Science and Engineering
Sheshadri Road, Bangalore -01

SOFTWARE REQUIREMENTS SPECIFICATION

ON
PUBG MOBILE
Submitted in partial fulfillment of requirement for the award of

DIPLOMA IN COMPUTER SCIENCE AND ENGINEERING

Prescribed by the Board of Technical Education
2019-2020
Under the guidance of

Mr. Praveen Kumar K

Submitted by:
Mahesh Gowda Patil & Praveen Kumar S
1 INTRODUCTION
1.1 Purpose
1.2 Scope
1.3 Definitions
1.4 Goals and Challenges
1.5 Overview
2 OVERALL DESCRIPTIONS
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
3 SPECIFIC REQUIREMENTS
3.1 DETAILED REQUIREMENTS
3.1.1 System interfaces
3.1.2 User interfaces
3.1.3 Hardware interfaces
3.1.4 Software interfaces
3.1.5 Communications interfaces
3.1.6 Operations
3.2 FUNCTIONAL REQUIREMENTS
3.2.2 Menu Requirements
3.2.3 Game Flow Requirements
3.3 PERFORMANCE REQUIREMENTS
3.3.1 Static requirements
3.3.2 Dynamic requirements
3.4 ATTRIBUTES
3.5 OTHER REQUIREMENTS
4 USE CASES
4.1 Game play use case
4.2 Login use case
4.3 Chat use case
1 INTRODUCTION
1.1 PURPOSE
Player Unknown Battle Grounds will be an online multiplayer battle
royal game, up to one hundred users parachute onto island and
scavenge for weapons and equipment to kill others while avoiding
getting killed themselves. The available safe area of the game’s
decreases in size over time, directing surviving users into tighter areas to
force encounters. The last player or team standing wins the round.
1.2 SCOPE
This specification establishes the functional, performance and
development requirements for release of PUBG Mobile. This document
will be used by the end-user, developers and tester of the game.
1.3 DEFINITIONS
DB: Database
AI: Artificial Intelligence
GUI: Graphical User Interface
Http: Hypertext Transfer Protocol
API: Application programming interface
1.4 GOALS AND CHALLENGES
 Maintaining the game-state consistent
 Ordering the events
 Increasing interactive responsiveness
 Providing realistic rendering of 3D components
 Integrating artificial intelligence into the game
 Displaying animations
 Scheduling computations across users
 Providing authentication/authorization mechanisms
 Implementing a cheat-proof design
1.5 OVERVIEW
Section 1 identifies the scope of this document, the purpose of the
game and lists of the definitions. Section 2 describes the overall
description of the project. Section 3 identifies specific and detailed
requirements of the game. There will be more specific details and
 information about the project content, general requirements and
environment.
2 OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE
PUGB will be player versus player shooter game in which up to one
hundred users fight in a battle royal, a type of large scale last man
standing death match where users fight to remain last alive. Users can
choose to enter the match solo, duo, or with a small team of up to four
people. The last person or team alive wins the match. Each match shall
starts with users parachuting from a plane onto map(Island), with areas
of approximately 8 × 8 kilometers (5.0 × 5.0 mi).The plane's flight path
across the map shall vary with each round, requiring users to quickly
determine the best time to eject and parachute to the ground. Users
start with no gear beyond customized clothing selections which do not
affect game play. Once they land, users can search buildings, towns and
other sites to find weapons, vehicles, armor, and other equipment.
These items will be procedurally distributed throughout the map at the
start of a match. Killed users can be looted to acquire their gear as well.
Every few minutes, the playable area of the map will begin to shrink
down towards a random location, with any player caught outside the
safe area taking damage incrementally, and eventually being eliminated
if the safe zone is not entered in time; in game, the users can see the
boundary as a shimmering blue wall that contract over time On average
a full round takes no more than 30 minutes.
2.2 PRODUCT FUNCTIONS
Register: The user must register once in order to get access to the game;
after registering, a unique user name and password will be provided and
will allow the logging in of the registered user.
Log-in: A registered user has to enter his/her unique username and
password combination in order access the game.
Log-out: User logs out in order to let another user to register or log-in.
Settings: An option allowing the user to modify the settings for the
controls and graphics.
Exit: User exits the program.

2.3 USER CHARACTERISTICS

 User must be above 14 Years.
  All the users must have minimal technical expertise (need to know how to use
mobile and game controls).
 User needs to be very familiar and the comprehended game rules
2.4 CONSTRAINTS
Time Constraints: There exist strict deadlines for each phase of the
process, so the constraints of the meeting the deadlines is of utmost
concern.
Attribute Constraints: As a common denominator in the game
programming, it is best to use C++ as the main programming language as
the server side component. The components to be integrated, hence the
overall design is considered around the core of C++ component.
Tool Constraints: Using Graphics and AI engines leads to limitations
within the corresponding domain according to the implantation of
functionalities. While engines reduce the burden of low level
programming, they introduce constraints to the capabilities of the
project.
Network Connections: Since the aim is to be able to support a great
number of users, the effective transmission of game data is exposed to
network connection speed constraints, which greatly affects the project
design.
Graphics Constraints: A good frame rate is to be guaranteed in order to
have a decent display and game play. This places constraints of to what
extent the graphics module complexity can be pushed.
3 SPECIFIC REQUIREMENTS
3 DETAILED REQUIREMENTS
3.1.1 SYSTEM INTERFACE
The game integrates two internal systems to provide functionality:
CLIENT: The game software has an interface to user’s client to receive
user input and process the selection for the game.
SERVER: The game software has an interface to the network in order to
transmit information.
3.1.2 USER INTERFACE
It includes an interface resembling a common dashboard of the player.
3.1.3 HARDWARE INTERFACE
The system has no hardware interface requirements.
3.1.4 SOFTWARE INTERFACE
The required software products for PUBG Mobile are
  Game engine IDE platform called Unreal Engine.
 Java for the use of OpenGL for graphics makes the game realistic along with
good performance.
 Python to make the game more secure, hack proof and to provide a lot of
built in functions for gaming and also making the game more adaptable and
stable.

3.1.5 COMMUNICATION INTERFACE

Communication between the clients is facilitated by common network
protocols using TCP/IP.
3.1.6 OPERATIONS
 The system should allow users to login.
 The system should allow users to log out.
 The system should allow users to register account.
 The system should allow the administrator to ban account.
 The system should allow users to play the game.
 The system should allow users to exit the game at any point.
 The system should allow users to view tutorial of how to play
game.
 The system should allow users to practice playing the game
 The system should allow users to view their performance history.
 The system should allow users to modify their game settings.
 The system should allow the administrator to add, modify and
delete levels.

3.2 FUNCTIONAL REQUIREMENTS

3.2.2 MENU REQUIREMENTS
These are the requirements that are related to the menu that is
displayed in the game. This part is divided into two sections; one is
about the general properties of the menu and the other one is about
the properties and usage of the items that can appear in this menu.
a) General Requirements
 This menu is displayed from two contexts: first one is the
entrance of the game (Main Access Menu) and the latter one is
anytime whenever requested by the player during the playing of
the game (Paused Access Menu).
 Menu is composed of items which are included in the menu
according to the context that the menu is displayed from.
b) Menu Items Requirements
View Profile
 This item is included in Main Access Menu.
 The player can view his profile by this.
 The information about the player career results, statistics and
achievements.
Help
 This item is included in both Main Access Menu and Paused
Access.
 Help section is displayed which includes general information
about game contents, playing of the game and game controls.
Shop
 This item is included in main menu access.
 The player can buy outfits, Weapons finishes and used to
redeem items.
Setting
 This consist of various settings like basic setting, Graphics
setting, Controls setting, Sensitivity setting, Pick up setting,
Scope setting, Audio setting, Language setting and other
settings.
Mail
 The mail box is to receive game messages, updates and
rewards.
Inventory
 This consists of the outfit, Weapon Finish and other items
owned by player.
Friend’s List
 It consists of in game friends list and also acts as
communication channel between two players.
Start Button
 To start the game
Mission
 This consists of the mission that is to be accomplished by the
player.
3.2.3 GAME FLOW REQUIREMENTS
These requirements cover the period that the player is in the game
actively. It includes environment, main character abilities, interaction
between player and game and overall game logic during the game.
Game Logic Requirements
• The game has a homogeneous characteristic.
• The game is played in map, which consists of various locations.
• The player can change his location from one place to another.
• Most of the places will have buildings and monuments.
• Every location has a different view, which means a different a different
appearance.
Human Player: It has abilities like
 Walk
 Sprint
 Jump
 Crouch
 Turn
 Climb
 Prone
 Look around
 Fire
 Aim
 Heal
 Drive
 Reload
 Swap weapon
 Peek
 Pick up items
 Use items
 Drop items
 Speak, chat with other players
 Get wounded, every player will have a specific health
 Die
 Player-Game Interaction Requirements
 Player uses fingers on touch display to supply input to the game.
 Game uses display and sound devices to supply output to the
player.
 During the game the players can talk to each other, this talk can be
private or public.
 Player manages the character’s inventory items like selecting or
dropping one by a menu.
 Player views the game from the first person’s perspective and third
person’s perspective.
 Player can view the health and inventory status during the game.
 Player can escape to the menu during the game.

3.3 PERFORMANCE REQUIREMENTS

This section describes the expected performance requirements. This is an
estimation of the system, and all the numerical values may vary depends
on how large the final application is.

3.3.1 STATIC REQUIREMENTS

1. The system shall support only one terminal.
2. The system shall support only one simultaneous user on each device;
however, it shall support multiple users to create personal accounts
and access the system on the same machine at different times.
3. The system shall run on both i OS 8 and Android version above 5.1
Mobile devices with at least 3GB of memory.
3.3.2 DYNAMIC REQUIREMENTS
1. The system shall be loaded and functioning within 10 seconds 95% of
the time after Starting the game.
2. Each account shall be stored and activated within 5 seconds after
creation.
4. Each user input during the session shall be responded to within 3
seconds 98% of the time.
5. Each session grade report shall be generated within 5 seconds at the
end of each Session 95% of the time.
3.4 ATTRIBUTES
Reliability
The system should never crash or hang, other than as the result of an
Internet connection error (Network Error). If there is an network error the
system will ask the user to make sure that the device has active internet
connection.
Availability
The game has the risk of server failure because of excessive number of
users. Important precautions will be taken to avoid this circumstance such
as setting up checkpoints and some regular interval backups. So
application will always have a stable state which we offer to users.
Safety
The system should warn the user to take a break after every two hours
continuous play to prevent eyestrain and repetitive strain injury. No other
safety requirements have been identified.
Portability
The system should be portable to any Android system version above 5.1,
including ios 9. No other specific portability requirements have been
identified.
Security
Security will be guaranteed to all users. No personal information will be
shared with or sold to any other third party companies.
Maintainability
The design will be flexible. Whenever a new functionality is needed for
Game, it will be easy to integrate because the design is going to have a
Layered structure.
3.5 OTHER REQUIREMENTS
There are no other requirements.

4 USE CASES
The use case diagrams provided below go in direct correspondence with
each of the functional requirements item discussed in the Project
Requirements section of the report. The reader is encouraged to revisit
that section, if necessary.

4.1 GAME PLAY USE CASE

This use case displays the actions that the player can do in game play
without interaction with other players. We grouped these actions into
four: Movement, Camera, Items and Menu Entrance. Player can walk,
jump or crouch in the game. Those movements can be executed forward,
backward, left or right. Player can change the camera view in the game.
Items are an important issue in the game. There are two types of items in
the game: Wall Items are non-moveable items and can only be used,
Inventory Items are moveable. An inventory item can be picked up,
dropped, equipped or unequipped. The last action is the Menu entrance
in the game, player can enter the menu whenever he wants.
4.2 LOGIN USE CASE
This use case displays the player’s login to the game. Authentication server
checks player’s username and password and according to the check it
either allows or disallows player’s entrance to the game.

4.3 CHAT USE CASE

This use case displays the chat usage in the game. Player can chat with
other players in the game. This chat can be public, which includes all
players in a room, or can be private, which can only be done by two
players. Player can also interact with AI players in the game; this
interaction is of course limited.