Software Requirements

Specification
For

Flappy Bird
Version 1.1 approved

Prepared by

S.Haider Ali (2080286)

Haider Gul (1980220)

<organization>

25th of May, 2022

Copyright © 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Software Requirements Specification for <Project> Page ii

Table of Contents
Table of Contents .......................................................................................................................... ii
Revision History ............................................................................................................................ ii
1. Introduction ..............................................................................................................................1
1.1 Purpose............................................................................................................................................. 1
1.2 Document Conventions .................................................................................................................... 1
1.3 Intended Audience and Reading Suggestions .................................................................................. 1
1.4 Product Scope .................................................................................................................................. 1
1.5 References ........................................................................................................................................ 1
2. Overall Description ..................................................................................................................2
2.1 Product Perspective.......................................................................................................................... 2
2.2 Product Functions ............................................................................................................................ 2
2.3 User Classes and Characteristics ..................................................................................................... 2
2.4 Operating Environment .................................................................................................................... 3
2.5 Design and Implementation Constraints .......................................................................................... 3
2.6 User Documentation ........................................................................................................................ 4
2.7 Assumptions and Dependencies ...................................................................................................... 5
3. External Interface Requirements .........................................................................................11
3.1 User Interfaces ............................................................................................................................... 11
3.2 Hardware Interfaces ....................................................................................................................... 12
3.3 Software Interfaces ........................................................................................................................ 12
3.4 Communications Interfaces ............................................................Error! Bookmark not defined.
4. System Features .....................................................................................................................12
4.1 System Feature 1 .............................................................................Error! Bookmark not defined.
4.2 System Feature 2 (and so on) ..........................................................Error! Bookmark not defined.
5. Other Nonfunctional Requirements .....................................................................................14
5.1 Performance Requirements ............................................................................................................ 14
5.2 Safety Requirements ...................................................................................................................... 14
5.3 Security Requirements ................................................................................................................... 14
5.4 Software Quality Attributes ........................................................................................................... 14
5.5 Business Rules ............................................................................................................................... 15
6. Other Requirements ..............................................................................................................15
Appendix A: Glossary..................................................................................................................15
Appendix B: Analysis Models .....................................................................................................15
Appendix C: To Be Determined List ..........................................................................................15

Revision History
Name Date Reason For Changes Version
Flappy Bird 29th of Additional information 1.0
march,
2022
Software Requirements Specification for <Project> Page 1

1. Introduction
1.1 Purpose
The purpose of this SRS document is to an overview of an android game “FLAPPY BIRD” along
with the mechanics, user interface and story of the game. The SRS document details all the
features, reference to the manner and importance of their implementation.

1.2 Document Conventions

As we are responsible for the SRS document, there should be no confusion to its usage. There is a
clear difference, however, between the two used words "player" and "character." The "player" is
the human being interacting with the game in the real work! While the "character" is the in-game
character avatar being manipulated by the player from the real world. This document is too printed
on A4 paper in Arial font. Italic text is size 11 black, while section headings are in Times font bold
text size 18 black. Subheadings are bolded size 14 black.

1.3 Intended Audience and Reading Suggestions

1.4 The SRS document also provides the inspectors and project managers with a way to ensure
game adherence to the original vision. Although the document may be read from front to back to
fully understand the project, it was written in sections and therefore could not be read as such. For
more information on the document and the project itself, see General Description (Section 2)

1.5 Product Scope

Flappy Bird is a simple Android Phone game that sits on you to jump and control the bird, trying to
fly between pillars of green pipes without hitting them.
The Flappy bird also requires a little patience and time; otherwise the game can drive you crazy.
Available for low memory devices, Flappy bird is a fun game you can have in your library in those
times you need a little help over time.
The Flappy bird's main menu is small with two game modes available. The two types of play are
simple and complex. The main difference between the two methods is the distance between the
green pillars where the player has to bounce the bird. Controlling your bird is done by tapping on
the screen. Tapping on the left side bounces the bird up to the top and then pressing the right
button will send the bird to the top right. Tap this on the right tap and your bird will move forward in
a straight line. The navigation trail will have a small space between the two straight green pillars
(from top to bottom) past your bird. You will need to avoid contact with the green pillars.
Connecting with any of the pillars will end the game.

1.6 References
https://en.wikipedia.org/wiki/Flappy_Bird
Software Requirements Specification for <Project> Page 2

2. Overall Description
2.1 Product Perspective
Its implementation was made possible by the Unity Game Engine and its ability to integrate and
create projects to be used on an Android mobile device.
With smartphones these days full of games therefore, one of our goals when designing a game is
to allow the user to understand the gameplay at the beginning of the game and not to silence how
often and unlock the game, we achieve this by showing the guide screen at the beginning of the
game. , which is why we always engage the user with the game. We tried to avoid creating a story
especially because users (especially when it comes to small smartphone games) find it rather
annoying rather than our game model focusing on earning points by reaching a level of difficulty.

2.2 Product Functions

The following is a summary of the main functions used in the game. They are divided into
categories based on what is needed for the game to work.

 GRAVITY ROTATION:

The main mechanic of the game is to allow the player to change the way he looks.

 JUMPING:

Also a necessary movement mechanic, allowing sudden movements to control the bird.

 TITLE SCREEN:

The first viewable screen upon starting up the application, containing buttons for play game,
options.

2.3 User Classes and Characteristics

Our control system is designed to be automatic and our game to be pioneering and unusual.
Therefore, experience with games will not be a key factor in determining who can play: players of
any age or skill level should be able to pick it up. However, like any game with a fan base large
enough, there will be natural differences between regular and strong players. The two categories
will differentiate themselves naturally through the use of game tools and the level structure. Skills
and features that distinguish strong players will promote:
 Tapping: The ability to tap the bird rapidly and in timely manner accelerating gravity vector
with proper thing in order to reach certain points without contacting the green pillars.
 Speed: The ability to complete levels quickly
 Intuition: Ability to effectively predict the presence of objects off the screen.
Software Requirements Specification for <Project> Page 3

2.4 Operating Environment

Flappy Bird requires android phone and essential requirement is android 2.2, which requires an
active android device.

2.5 Design and Implementation Constraints

This includes design and implementation risks or constraints.

2.5.1 Design:

This section contains the requirements for compiling and creating a game software architecture.
The phase will be reviewed several times during the implementation phase.

2.5.2 Implementation:

This section contains the repetitive process of creating a game. The whole structure should be
used, and then the actual code will be written, as well as tests and complete documentation.

2.5.3 Risk Analysis:

This section is about the risks in this project. They are separated into two pans, general risks and
specific risks.

2.5.3.1 General Risks

 Internal Conflicts:

Conflicts between team members are possible, and even more so as we will be working
closely together for a long time. It is therefore important to communicate openly, and to
address problems early on before they become too numerous to be addressed. If this is not
enough one can always seek the help of management, or in the worst case - disband the
team.

 Android Difficulties:

Android development is something we are not aware of when we spend a lot of time gaining
insight into the framework, development will take longer than expected and some parts of
the project will suffer. We can prevent this by properly planning and giving us enough time
to understand Android, as well as starting development early.

 Bad Prototyping:

Surveys and tests tell us that the concept of model is bad. This is a risk that we may not be
able to design a satisfactory platform, which could have a significant impact on the project.
One way to reduce the likelihood that this will happen is to consult a teacher to confirm the
Software Requirements Specification for <Project> Page 4

learning aspect of the concept. The impact can be reduced by conducting a survey that will
provide us with useful information even if prototype design is bad.

2.5.3.2 Specific Risks

 BATTERY:

Low battery life on smartphones is a well-known problem, especially when GPS is enabled
or the touch screen is widely used. This may interfere with the display of our model, in the
event that any of the phones are running out of battery. We need to plan with battery usage
in mind, that is, use GPS as little as possible.

 UNCLEAR TASKS:

When you create job descriptions, you run the risk of performing obscure tasks. This can
lead to frustration for participants and they may get stuck. This can be avoided by
examining the activities and making sure that they are clear and unambiguous. If that does
not work, participants can always contact the exhibition manager and get clarification.

2.6 User Documentation

Android game, Flappy Bird, creates a modern combination of Mario Bros. and Angry Birds into
one. All one has to do is fly a bird between pipes of different heights. Sounds easy? That's the
challenge of the game.
 Tap on the screen to make the bird fly.

 Stay in the middle of the pipes. This is the main objective of the game. If you hit a pipe or
the ground, the game ends
Software Requirements Specification for <Project> Page 5

 Get point for every set of pipes you pass through.

 Don’t crash into the pipes or your game is over.

 Play again and try to get the high score.

2.7 Assumptions and Dependencies

2.8 Assumptions and Dependencies

 Play store policies regarding android games could be changed
 Unity game engine server drawbacks
 Blockage of add sense account
 Back in certain countries due to underage policies
Software Requirements Specification for <Project> Page 6

Use-Case Modeling

Use Case: Play Game

ID: UC 1
Actor:
Player
Pre-Condition:

The game Should Be launched correctly

Flow Of Events

 On the title screen the game button appears on the screen

 When you press a button the app should stop the use of the gameplay screen

 Tie the instruction screen is full, it should disappear with a single tap
Secondly Scenario
 The user exits the app by pressing the back or home button of the Android device.
Post-Condition
 The game should start
Software Requirements Specification for <Project> Page 7

Use Case: Exit Game

ID: UC 2
Actor:
Player
Pre-Condition:

The application should be at the title screen

Flow Of Events

 When the pause button is pressed the exit button appears, or when user hunches the
application

 Upon pressing the exit button the application should kill all the objects and the bodies and
it should end the game

 The application closes

Secondly Scenario
 User exits the application by pressing the back or home button of the Android device.
Post-Condition
 The game process is killed
Software Requirements Specification for <Project> Page 8

Use Case: Select Mode

ID: UC 3
Actor:
Player
Pre-Condition:

The game Should Be launched correctly

Flow Of Events
 The button is completed on the main screen of the app

 When you press the select nixie button the application should take the user to a select
location

 Different options must be completed

Secondly Scenario
 User logs out of the app by pressing the home or back button of the Android device.
Post-Condition
 User logs in to select mode

Use Case: Easy

ID: UC 5
Actor:
Player
Pre-Condition:

Mode selection event should have been activated

Flow Of Events
 Game mechanics and physics are simplified

 User is restored to the main screen

Secondly Scenario
 User logs out of the app by pressing the home or back button of the Android device.
Post-Condition
 The game becomes easier
Software Requirements Specification for <Project> Page 9

Use Case: Difficult

ID: UC 5
Actor:
Player
Pre-Condition:

The selected event should be activated

Flow Of Events
 Game equipment and physics become more complex

 User returns to main screen

Secondly Scenario
 User logs out of the app by pressing the home or back button of the Android device.
Post-Condition
 Games becomes difficult to play

Use Case: Change Bird

ID: UC 6
Actor:
Player
Pre-Condition:

The application should be at the title screen

Flow Of Events
 The button should be completed at the beginning of the application

 When you press the button to change the bird, the user is brought to the screen where he
can select different situations for the bird.
Secondly Scenario
 User logs out of the app by pressing the home or back button of the Android device.
Post-Condition
 User ends up in the selection menu
Software Requirements Specification for <Project> Page 10

Use Case: Red Bird

ID: UC 7
Actor:
Player
Pre-Condition:

The application should be in the Change Bird mode.

Flow Of Events
 The button representing the red bird is populated in the change background shape color
menu

 Upon pressing the red color button, the game character's color is changed to the red in the
gameplay
Secondly Scenario
 User logs out of the app by pressing the home or back button of the Android device.
Post-Condition
 The color of the bird is now red

Use Case: Yellow Bird

ID: UC 8
Actor:
Player
Pre-Condition:

The application should be in the Change Bird mode.

Flow Of Events
 The button representing the yellow bird is populated in the change background shape
color menu

 Upon pressing the yellow color button, the game character's color is changed to the yellow
in the gameplay
Secondly Scenario
 User logs out of the app by pressing the home or back button of the Android device.
Post-Condition
 The color of the bird is now yellow
Software Requirements Specification for <Project> Page 11

Use Case: Check Score

ID: UC 9
Actor:
Player
Pre-Condition:

Application requires to be in title screen.

Flow Of Events
 When you press, the check points button leads to a list of the highest points or hall of
fame

 When you press back or swipe, the user is returned to the main screen

Secondly Scenario
 User logs out of the app by pressing the home or back button of the Android device.
Post-Condition
 User saw list of points or high score

3. External Interface Requirements

3.1 User Interfaces

The user interface mainly consist of a drawing area on which game renders the different dynamic
elements of the game. Static elements can be defined within the layout of our main activity. The
Software Requirements Specification for <Project> Page 12

Flappy Bird background is the static element that we will define within an Image View taking the
entire screen. The dynamic part will be drawn as the game evolves within.

3.2 Hardware Interfaces

Flappy Bird is a mobile app designed specifically for the Android platform and works on both smart
phones and tablets. Game app data is stored locally on an Android device using the SQLite related
website.
Flappy bird is designed for Android version 2.2 with all the following releases. The Android platform
is adaptable with 2-dimensional Photo Library and 3-dimensional image library based on OpenGL
ES 2.0 specification and computer layout, scaling, pixel format conversion and accelerated 3D
images.

3.3 Software Interfaces

 Flappy Bird will be developed under the Android operating system using a series of game
development tools.
 Android Software Development Kit (Android SDK): Software development kit for Android
platform.
 Unity Game Engine: The main game development library using Java and c #.
 Used in compatibility with Android SDK and processing.
 Box2D Processing: An assistant class that addresses the area of Unity development and
Processing.
 PDE: Processes Development Area.

4. System Features
4.1 Gravity Rotation:
4.1.1 Description and Priority
This mechanic gives the player complete control over the level of the level in the relationship
with the character. Rotating gravity replaces the main movement controls (left and
right) by allowing the player to tilt upwards to slide and "fall" at different speeds and
directions.
4.1.2 Stimulus/Response Sequences
Step 1: The player slides his finger up / down the scroll bar on the right or left of the screen.
Step 2: The level rotates the opposing clock intelligently / clockwise next to the character in
real time with limited speed and the actual distance scratched by the player.
4.1.3 Functional Requirements
REQ-1: Scroll bar should constantly update the player's current finger position to allow for
real-time re-gravity reset.
REQ-2: The impact of the scroll bar in the rotation fog is measured so that the player can
deceive the level with accuracy
REQ-3: Different spatial inclusions should affect the vector velocity.
REQ4: Levels should be built to take advantage of the effects of this game machine
Software Requirements Specification for <Project> Page 13

4.2 JUMPING:
4.1.1 Description and Priority
As it is the second input of the player, the jump keeps the value of the game in the second
highest. This mechanic allows the player to move around in spaces without having to
master the force of gravity.
4.1.2 Stimulus/Response Sequences
Step 1: The player taps on the screen in order to jump.
Step 2: The character jumps with unchanging power.
4.1.3 Functional Requirements
REQ-1: Because the touch screen is sensitive to pressure, the jump force Trust should be
uniform.
REQ-2: Levels should be converted to this standard jump
REQ-3: Jumping should take into account current vertical and horizontal speed and local
inclination.
REQ4: Jump power should be large enough that the mechanic is made useless but not so
large that rotating gravity can easily replace the effect

4.3 TITLE SCREEN:

4.1.1 Description and Priority
The title indicates the screen, the player will see each time they play a game. With this
interface, the player can start the game, see high score, or adjust options. As the title
indicates the "hub" of all activities in the project, it should be included.
4.1.2 Stimulus/Response Sequences
Step 1: The player launches the game from the mobile device.
Step 2: The first screen loads and appears, making the player with three buttons: "Play
Game", "Options", and "Exit".
Step 3: The player presses one of the buttons, activating their function in sequence.
4.1.3 Functional Requirements
REQ-1: The title screen must load and appear every time the game is launched.
REQ-2: f the player quits the game during any stage of a level, they must be returned to the
screen
REQ-3: If the player presses the exit button, the game will end and return the player to the
phone's regular interface.
REQ4: If the player completes the game, the game will end and return the player to the title
screen
Software Requirements Specification for <Project> Page 14

5. Other Nonfunctional Requirements

5.1 Performance Requirements
Based on the capabilities of current phones and the Android system, performance should not be a
problem. However, phones with weak hardware may present some inconvenience and may be less
efficient. Game design will be done correctly to give a happy feeling to all Android phones,
regardless of hardware. The performance of the game will be simple enough, but not trivial, and
the graphics will not be too detailed so the system will not slow down.

5.2 Safety Requirements

Flappy Bird will not affect or harm any other applications installed on the player's phone. It will not
cause any heat to the player's phone; therefore, the internal parts of the phone will not be
damaged. Flappy Bird should not be played when the player is a short tempered personality.

5.3 Security Requirements

Flappy Bird will not ask for any personal information from the player and will thus be unable to
compromise such information. There is no player authentication required to play Flappy Bird. The
player simply has to download the application in order to start playing Flappy Bird. That being
stated, anyone who has access to the player's phone will have the ability to play Flappy Bird. If any
unauthorized player acquires the original player's phone, that unauthorized player will be able to
play Flappy Bird. It is the responsibility of the player to make sure that his mobile is not in wrong
hands.

5.4 Software Quality Attributes

To ensure integrity and fairness, Flappy Bird will respond to player instructions in a timely manner.
If the player makes the box jump gravity and the speed will respond quickly, the player must see
the effects of this command within milliseconds and not 10 seconds after the result. Pliable and
flexible, Flappy Bird will automatically keep player progress after a new record is set. That way, in
the event that the player's phone runs out of battery during game play, the player may be able to
continue playing the game in the correct starting position. In terms of usability, the visual interface
of the user will be much easier for the player to use. The first levels of Flappy Bird will gradually
introduce each unique command available to the player and any other game equipment the player
may need to master to go further. . This method will ensure that the player gradually learns all the
instruments of the game and enjoy the feeling of playing a challenging game. Our game focuses
on both ease of use and easy learning while not dependent on one or the other. Flappy Bird should
be a game any player can pick up and play quickly without spending too much time gaining
controls. The controls will be simple and easy to use and the player will not be bombed by using all
the controls at once in the beginning. Game play will facilitate the player in learning and applying
each command by gradually introducing each command as the player progresses through the
game and combines each level. At the end of any given level, the player must be fully acquainted
Software Requirements Specification for <Project> Page 15

and able to use the command presented in that level and all the instructions presented in previous
levels.

5.5 Business Rules

The SKU or app name can't be reused in the same organization. And name Flappy Bird is patent

6. Other Requirements
There are not any other specific requirements. And name Flappy Bird is patent.

Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire
organization, and just include terms specific to a single project in each SRS.>

Appendix B: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state-transition diagrams, or entity-relationship diagrams.>

Appendix C: To Be Determined List

<Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they
can be tracked to closure.>