SRS REPORT ON A ANDROID GAME

1
TRIBHUVAN UNIVERSITY
INSTITUTE OF ENGINEERING
ADVANCED COLLEGE OF ENGINEERING AND
MANAGEMENT
LALITPUR, NEPAL
MINTO GAME
SRS REPORT
SUBJECT: SOFTWAREENGINEERING
SUBMITTED BY: SUBMITTED TO:
NAME: Milan Tripathi DEPARTMEN OF
ROLL: 2072/BCT542 COMPUTER ENGINEERING

2
TITLE
Software Crisis and failure
OBJECTIVES:
To investigate the different types of software failure and crisis in the history
THEORY:
Software crisis is a term used in the early days of computing science for the difficulty of writing
useful and efficient computer programs in the required time. The software crisis was due to the
rapid increases in computer power and the complexity of the problems that could not be tackled.
With the increase in the complexity of the software, many software problems arose because
existing methods were insufficient.
The definition of a software project as a failure varies and seems to be quite a subjective issue.
Most of the times, it depends on the type of the project and the standards that the company
producing it has set for it. A commercial project that exceeds the pre-estimated budget or does
not meet the predefined deadline could be seen as a failure. On the other hand, an open-source
project could be considered as a failure if it does not succeed in creating a community around it
which takes care of its maintenance and evolution.
7 software engineering principles
1. Manage using a phased life cycle plan.
2. Perform continuous validation.
3. Maintain disciplined product control
4. Use modern programming practices.
5. Maintain clear accountability for results.
6. Use better and fewer people.
7. Maintain a commitment to improve the process

3
CASES:
Case 1:
Absence or bad definition of system requirements
The existence of Software Requirement Specifications (SRS) is fundamental in the software
development process. System specifications that are not defined in a thorough and precise way
can cause misunderstandings and lead to bad implementation. The accuracy of SRS is very
important and can save much time and eliminate problems that could possibly arise during the
next steps of the development procedure regarding the addition of new features or changes in
already existing ones.
Case 2:
Unrealistic expectations and project goals
There is a close relation among this factor and some others associated with the pressure caused
by imminent deadlines and the skills of the software development team working on a project. In
some cases, project managers fail to realise that it is not feasible to implement all the ideas
regarding a project within the specified time limits, especially when some of them appear to be
quite complex. Moreover, they often overestimate the abilities and skills of the members
working on that project, who may be for instance young and inexperienced. The lack of a well
organised plan based on the correlation among these issues can easily lead to project failure. It is
also true that the unrealistic expectations can be a result of inexperience of project managers
themselves.
Case 3:
Poor communication among developers, customers and final users
There is no way of a software project being successful, if there is no constant and meaningful
communication among these groups of people. Users’ needs and customers’ requirements and
expectations change all the time and developers should always take into consideration this new
information during the development process.

4
Case 4:
Inadequate resources or use of inappropriate ones
Software development teams often tend to use resources and tools that are obsolete and as a
result not the most suitable for the development of modern software projects. This can often
cause unexpected and undesirable results and in the worst scenario to failure of the whole
project. Software manufactures should be responsible for keeping themselves informed about the
technology changes and being ready to exploit their advantages in order to improve their project.
In some other cases, a bad estimate about the required resources may be done. This fact makes
the development of software at the expected and predefined level extremely difficult and
sometimes infeasible.
Case 5:
Absence or bad risk management
Risks in software projects refer to uncertain states that could affect a project in an undesirable
way, e.g. inadequate or badly written requirement specifications, use of unsuitable technology
and tools, etc. Risk management is another crucial part of the software development process that
should be precise, done from the beginning to the end and kept updated. In that way, many
problems could be encountered and solved before becoming too serious and leading to failure.
Conclusion
In this lab, we discuss about the different types of software failures and crisis in the history. We
research about the various cases of software failures and learn various principles to be followed
to overcome such failures.

5
TITLE
To specify: purpose, scope, definitions for making good and effective srs (software requirement
specification).
OBJECTIVES:
1. To determine the purpose, scope, definition for the SRS
2. To identify the technical definitions and acronyms that can be used in the project.
THEORY:
1.0. Introduction
1.1. Background
Background is a set of events invented for a plot, presented as preceding and
leading up to that plot. It is a literary device of a narrative history all
chronologically earlier than the narrative of primary interest. In our project it’s a
single player strategy game emphasizing logical thinking and planning. They
often stress resource and time management, which usually takes precedence over
fast action and character involvement. Tactical organization and execution are
necessary, and the game creators usually place the decision-making skills and
delivery of commands in the player’s hands.
1.2. About the Project
It’s a endless runner game. The main character of ‘Minto Game’ is a alien whose
is being chased by dark lord. He is travelling by UFO to escape army of dark lord.
He has to control the UFO and pass through spike bomb. The UFO will blast if
collided with bomb. The UFO can’t go too up or too down .
1.3. Purpose
The purpose of this document is to present a detailed description of the Minto
Game System. It will explain the purpose and features of the system, the

6
interfaces of the system, what the system will do, the constraints under which it
must operate and how the system will react to external stimuli. This document is
intended for both the client and the developers of the system.
1.4. Scope of Project
This Report describes all the requirements for the project. The purpose of this
research is to provide a virtual image for the combination of both structured and
unstructured information of our project “Minto”. “Minto” is a single-player
strategy game on the Android platform. The player will progress through levels
which require precise manipulation of the environment, though the game
Encourages creativity and daring via branching pathways. The episodic structure
of the game facilitates the pace of the story.
1.5. Definition, Acronyms, Abbreviation:
 JAVA - platform independence
 SQL - Structured query Language
 DFD - Data Flow Diagram
 CFD - Context Flow Diagram
 ER - Entity Relationship
 IDE - Integrated Development Environment
 SRS - Software Requirement Specification
2. OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE
There are three main components of the system:
1. Client game: where the player plays.
2. Admin module: provide admin interface to the administrators

7
3. Database backend: where all of the data such as player statistics, game states, etc. are
stored.
Conclusion
Thus, we introduced about the Minto Game. It is a blend of classic and modern indie game. This
game reflects the blend of classic and modern indie genre. This game will help the company to
achieve a bigger fan base. The purpose, scope, user perspective have been discussed above.
Moreover, the major objective of making this game is to establish a better game development
culture in the company.

8
TITLE
Overall description: system interface, hardware interface, software interface, user characteristics
and different types of class diagram for making srs
OBJECTIVES:
3. To determine the different types system boundaries.
4. To determine the different types of interfaces to be used.
5. To use a new tool for making design diagram
THEORY:
1.0 SOFTWARE REQUIREMENT
1. Lua
2. Corona SDK
3. Java Development Kit
4. Windows 10, Windows 8, or Windows 7
5. OpenGL 2.1 or higher
2.3 HARDWARE REQUIREMENT
1. Android 4.0.3 with ARMv7 processor
2. 1 Ghz processor(recommended)
3. 1 GB of RAM(recommended)
2.4 ASSUMTIONS AND DEPENDENCIES
The product needs following third party applications for the development of the project:
1. Corona SDK
2. Photoshop
3. Sublime Text
2.5 USER CHARACTERISTICS

9
The first screen is the login screen. It will feature a username and password string entry, and
submit and exit buttons. The user will be notified by a dialogue box in case of an incorrect entry.
Once the user has signed on, the main menu screen will be presented. The main menu will have
three buttons: New Game and Restart Game. All buttons in the preceding and subsequent menus
will have a similar style: energetic, entertaining, but also easy to understand and use. The buttons
will provide the following functionality:
1. The New Game button will open the new game screen.
2. The Pause Game button will pause the game for specific period
3. The Restart Game button will start a new game clearing all the data of previous game
4. The function of any Quit Game button will be the closing of the game.

12
2.9 State Machine Diagram
3.0 Context Level Diagram

14
Level 1
Conclusion
In this lab, we discuss about the system interface, hardware interface, software interface, user
characteristics and different types of class diagram for making srs .

15
TITLE
SPECIFIC REQUIREMENTS: FUNCTIONAL AND NON-FUNCTIONAL
OBJECTIVES:
To determine different types of functional and non-functional requirements for the
SRS
THEORY:
Functional Requirement
In Software engineering and systems engineering, a functional requirement defines a function of
a system or its component. A function is described as a set of inputs, the behavior, and outputs.
Functional requirements may be calculations, technical details, data manipulation and processing
and other specific functionality that define what a system is supposed to accomplish. Behavioral
requirements describing all the cases where the system uses the functional requirements are
captured in use cases. Functional requirements are supported by non-functional requirements
(also known as quality requirements), which impose constraints on the design or implementation
(such as performance requirements, security, or reliability). Generally, functional requirements
are expressed in the form "system must do <requirement>", while non-functional requirements
are "system shall be <requirement>". The plan for implementing functional requirements is
detailed in the system design. The plan for implementing non-functional requirements is detailed
in the system architecture.
Non-Functional Requirement
n systems engineering and requirements engineering, a non-functional requirement (NFR) is a
requirement that specifies criteria that can be used to judge the operation of a system, rather than
specific behaviors. They are contrasted with functional requirements that define specific

16
behavior or functions. The plan for implementing functional requirements is detailed in the
system design. The plan for implementing non-functional requirements is detailed in the system
architecture, because they are usually Architecturally Significant Requirements.
FUNCTIONAL REQUIREMENT
1. Login/Log out
2. Start
3. Pause
4. Restart
5. View Game Statistics
6. Collision
NON-FUNCTIONAL REQUIREMENT
1. Usability Requirement
The system shall allow the users to access the system from the phone using android
application. The system uses a android application as an interface. Since all users are
familiar with the general usage of mobile app, no special training is required. The system
is user friendly which makes the system easy.
2. Availability Requirement
The system is available 100% for the user and is used 24 hrs a day and 365 days a year.
The system shall be operational 24 hours a day and 7 days a week.
3. Performance Requirement
The system has to be 100% reliable due to the importance of data and the damages that
can be caused by incorrect or incomplete data. The system will run 7 days a week, 24
hours a day.
4. Reliability Requirement
The system has to be 100% reliable due to the importance of data and the damages that
can be caused by incorrect or incomplete data. The system will run 7 days a week, 24
hours a day.

17
5. Accuracy
The system should accurately provide real time information taking into consideration
various concurrency issues. The system shall provide 100% access reliability.
Conclusion
In this lab, we discuss about the to different types of functional and non-functional requirements
for the SRS.

18
TITLE
Case Study: Architectural Design and Real Time Software Design
OBJECTIVES:
1. To study different types of architectural design and real time software design.
2. To understand the importance of choosing the design with respect to software
requirements.
THEORY:
Architecture Design
Software architectural design represents the structure of the data and program components that
are required to build a computer-based system.
Different Architecture Style
1. Data Centered Architecture
Data center architecture is the physical and logical layout of the resources and equipment
within a data center facility. It serves as a blueprint for designing and deploying a data
center facility. It is a layered process which provides architectural guidelines in data
center development.

19
2. Data Flow Architecture
In data flow architecture, the whole software system is seen as a series of transformations
on consecutive pieces or set of input data, where data and operations are independent of
each other. In this approach, the data enters into the system and then flows through the
modules one at a time until they are assigned to some final destination (output or a data
store).

20
3. Call and Return Architecture
This architecture style allows to achieve a program structure which is easy to modify.
1. Main program or subprogram architecture
The program is divided into smaller pieces hierarchically. The main program invokes
many of program components in the hierarchy that program components are divided
into subprogram.
2. Remote procedure call architecture
The main program or subprogram components are distributed in network of multiple
computers. The main aim is to increase the performance.
4. Layered Architecture
Layered architecture focuses on the grouping of related functionality within an application
into distinct layers that are stacked vertically on top of each other. Functionality within

21
each layer is related by a common role or responsibility. Communication between layers is
explicit and loosely coupled. Layering your application appropriately helps to support a
strong separation of concerns that, in turn, supports flexibility and maintainability.
The layered architectural style has been described as an inverted pyramid of reuse where
each layer aggregates the responsibilities and abstractions of the layer directly beneath it.
With strict layering, components in one layer can interact only with components in the
same layer or with components from the layer directly below it. More relaxed layering
allows components in a layer to interact with components in the same layer or with
components in any lower layer.
5. Reference Architecture
A reference architecture in the field of software architecture or enterprise architecture
provides a template solution for an architecture for a particular domain. It also provides a

22
common vocabulary with which to discuss implementations, often with the aim to stress
commonality. A software reference architecture is a software architecture where the
structures and respective elements and relations provide templates for concrete
architectures in a particular domain or in a family of software systems.
A reference architecture often consists of a list of functions and some indication of their
interfaces (or APIs) and interactions with each other and with functions located outside of
the scope of the reference architecture.
6. Multiprocessor Architecture
Multiprocessing is the use of two or more central processing units (CPUs) within a single
computer system. The term also refers to the ability of a system to support more than one
processor and/or the ability to allocate tasks between them.
The term ‘processor’ in multiprocessor can mean either a CPU or an input-
outputnprocessor (IOP).

23
There are some similarities between multiprocessor and multicomputer systemssince both
support concurrent operations. However, there exists an importantdistinction between the
two.
In case of multicomputer systems, several autonomous computers are connected through a
network that may or may not communicate with each other. On the other hand, in a
multiprocessor system, processors interact with each other through an operating system
and cooperate in the solution of a problem.
Real Time Software Design
A real-time system is a software system where the correct functioning of the system
depends on the results produced by the system and the time at which these results are
produced. A ‘soft’ real-time system is a system whose operation is degraded if results are
not produced according to the specified timing requirements. A ‘hard’ real-time system is
a system whose operation is incorrect if results are not produced according to the timing
specification.

24
Conclusion
In this lab, we discuss about the different types of architectural design and real time software
design. We research about the importance of choosing the design with respect to software
requirements.

25
TITLE
To make the test cases for the above srs.
OBJECTIVES:
1. To design the test cases for the SRS made.
2. To make student to test different modules that has been documented as SRS.
THEORY:
Register
S.No Test Case Excepted Result Test Result
1
Enter valid username, email,
password & click on register button
Register Successful Successful
2
Enter invalid Invalid username or
password
Successful
Login
S.No Test Case Excepted Result Test
Result
1 Enter valid username and password & click on
login button
Start Game Screen should
appear
Successful
2 Enter invalid Invalid username or password
popup
Successful
Game
1 Click the Start Button Start new game Successful
2 Click the Pause Button Game is paused Successful

26
3 Click the Restart Button New Game with all
previous data reset
Successful
4 Click the Quit Button Game is closed Successful
View Game Statistics
1 Click on Offline data option Show user previous
game score in
descending order
Successful
2 Click on Friends Score option Show data of user and
connected friends in
descending order
Successful
3 Click on Global Score option Show data of all user
worldwide in
descending order
Successful
Conclusion
In this lab, we discuss about the design of the test cases for the SRS. We also test different
modules that has been documented as SRS.

27
TITLE
Bugs in the demo project: test execution sheet in excel
OBJECTIVES:
1. To find out real time bugs in the demo project
2. To become able to document the bugs detected and identify its severity
Test Cases:
Several Tests were done in the System. And the Test cases of the system are given in the table
below:
Test
Case
ID
Test Scenario Test Step Test Data Expected
Output
Actual
Output
Statu
s
AA01 To check the
Authentication
Login system
with valid user
Go to login
system and
enter valid User
name and pass-
word
1.Username=mila
n22,
password=nokias
2.UserName=nar
u120993,
password=’bestia
cana’
3.User
Name=gobfmr
Password=’fevesb
owaer’
Forwards
the user
for the
sector
login/sign-
in
As
expected
Pass
AA02 To check the
Authentication
Login system
with one empty
field
.Go to login
system and
enter keep
either User
name and pass-
word empty
1.Username=mila
n22, password=
2.UserName=,
password=’bestia
cana’
Please fill
all fields
As
Excepted
Pass
AA03 To check the
Authentication
Login system
with invalid
Users and
password
Go to login
system and
keep either User
name or
password
invalid
1.Username=
nomgr
Password=’ytrew
q’
2.User
Name=shodan
Password=’foulhe
r’
1.Message
“invalid
Username
or
password”
As
Excepted
Pass

28
Test
Case
ID
Test Scenario Test Step Test Data Expected
Output
Actual
Output
Status
AA04 To Delete
action in
Account
system
Go to delete
system and
enter Customer
ID
1.Customer ID: 1 Delete
Successful
Access
denied
for user
'root'@'lo
calhost'
(using
password
: NO)
Fail
AA5 To check the
Mini
Statement
Form
Go to Mini
Statement
Form system
and enter
Account No
1.Account No: 1 Successful Access
denied
for user
'root'@'lo
calhost'
(using
password
: NO)
Fail
AA06 To check the
Edit Account
Form
Go to Edit
Account
system and
enter Account
No
1.Account No: 1 Successful Access
denied
for user
'root'@'lo
calhost'
(using
password
: NO)
Fail
AA07 To check the
Edit Customer
Form
Go to Edit
Customer
system and
enter Customer
ID
1.Customer ID: 1 Successful Access
denied
for user
'root'@'lo
calhost'
(using
password
: NO)
Fail
AA08 To check Log
Out System
Click Log Out
Option
Nope Successfully
Logged Out
As
Excepted
Pass

29
CONCLUSION:
Hence we visited the guru99 page and we looked a demo project of GPTL bank. Several Tests
were done in the System and we found some bugs in that project. The bugs detected as well as
the passed tests are documented in the above table.

30
TITLE
Case Study: Configuration Management
OBJECTIVES:
To study different types of configuration management techniques used
THEORY:
In software engineering, software configuration management (SCM or S/W CM) is the task of
tracking and controlling changes in the software, part of the larger cross-disciplinary field of
configuration management. SCM practices include revision control and the establishment of
baselines. If something goes wrong, SCM can determine what was changed and who changed it.
If a configuration is working well, SCM can determine how to replicate it across many hosts.
CM Activities
Version management
Version management (VM) is the process of keeping track of different versions of software
components or configuration items and the systems in which these components are used.
It also involves ensuring that changes made by different developers to these versions do not
interfere with each other. Therefore version management can be thought of as the process of
managing codelines and baselines.
A codeline is a sequence of versions of source code with later versions in the sequence derived
from earlier versions.
Keeping track of the multiple versions of system components and ensuring that changes made to
components by different developers do not interfere with each other.

31
System building
System building is the process of creating a complete, executable system by compiling and
linking the system components, external libraries, configuration files, etc. System building tools
and version management tools must communicate as the build process involves checking out
component versions from the repository managed by the version management system. The
configuration description used to identify a baseline is also used by the system building tool.
Developers check out code from the version management system into a private workspace before
making changes to the system.

32
Change management
Organizational needs and requirements change during the lifetime of a system, bugs have to be
repaired and systems have to adapt to changes in their environment.
Change management is intended to ensure that system evolution is a managed process and that
priority is given to the most urgent and cost-effective changes.
The change management process is concerned with analyzing the costs and benefits of proposed
changes, approving those changes that are worthwhile and tracking which components in the
system have been changed.

33
Release management
A system release is a version of a software system that is distributed to customers.
For mass market software, it is usually possible to identify two types of release: major releases
which deliver significant new functionality, and minor releases, which repair bugs and fix
customer problems that have been reported.
For custom software or software product lines, releases of the system may have to be produced
for each customer and individual customers may be running several different releases of the
system at the same time.
CASE tools for configuration management
CM processes are standardized and involve applying pre-defined procedures. Large amounts of
data must be managed. CASE tool support for CM is there for essential Mature. CASE tools to
support configuration management are available ranging from stand-alone tools to integrated CM
workbenches
1. Change management tools
Change management is a procedural process so it can be modeled and integrated with
aversion management system. Change management tools. Form editor to support
processing the change request forms. Workflow system to define who does what and to
automate information transfer. Change database that manages change proposals and is
linked to a VM system.
2. Version management tools
1. Version and release identification
Systems assign identifiers automatically when anew version is submitted to the
system.
2. Storage management
System stores the differences between versions rather than all the version code
3. Change history recording
Record reasons for version creation
4. Independent development
Only one version at a time may be checked out for change. Parallel working on
different versions

34
CONCLUSION
Hence, we studied about the different types of configuration management techniques used .We
also learnt about use of CASE tools to support configuration management process. In this way
we successfully conducted our case study.

SRS REPORT ON A ANDROID GAME

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a SRS REPORT ON A ANDROID GAME

Similar a SRS REPORT ON A ANDROID GAME (20)

Último

Último (20)

SRS REPORT ON A ANDROID GAME