Software Requirements

Specification
for

Mobile Game Development

Version 1.0 approved

Prepared by <author>

<organization>

<date created>

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
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..............................................................................................................................2
2. Overall Description.............................................................................................................. 2
2.1 Product Perspective................................................................................................................2
2.2 Product Functions...................................................................................................................4
2.3 User Classes and Characteristics.............................................................................................4
2.4 Operating Environment..........................................................................................................5
2.5 Design and Implementation Constraints..................................................................................5
2.6 User Documentation...............................................................................................................6
2.7 Assumptions and Dependencies..............................................................................................6
3. External Interface Requirements........................................................................................ 6
3.1 User Interfaces........................................................................................................................6
3.2 Hardware Interfaces................................................................................................................7
3.3 Software Interfaces.................................................................................................................7
3.4 Communications Interfaces.....................................................................................................7
4. System Features................................................................................................................... 7
4.1 Registration, Login/Logout Stage...........................................................................................7
4.2 Deckbuilding..........................................................................................................................8
4.3 Gameplay...............................................................................................................................9
5. Other Nonfunctional Requirements.................................................................................. 10
5.1 Performance Requirements...................................................................................................10
5.2 Safety Requirements.............................................................................................................11
5.3 Security Requirements..........................................................................................................11
5.4 Software Quality Attributes..................................................................................................11
5.5 Business Rules.....................................................................................................................11
6. Other Requirements.............................................................................................................. 11

Revision History
Name Date Reason For Changes Version
Software Requirements Specification for <Project> Page 1

1. Introduction

1.1 Purpose

The purpose of this Software Requirements Specification (SRS) report is explaining the defined
functional and non-functional requirements of the Mobile Game Development software project.
The report explains what are the important functional and non-functional and other requirements of
the card game that will be produced, which leads to better understanding for how analysis part of
the project is managed. Additionally, the report have several system design diagrams which give
better understanding for design stage of the project.

1.2 Document Conventions

This SRS report has table of contents, headings, subheadings and diagrams in order to make it
easier to follow. This report may have several hard-to understand features such as acronyms and
abbreviations which is highlighted in Appendix A: Glossary section.

1.3 Intended Audience and Reading Suggestions

The report is designed for software developers, documentation writers and testers. The SRS
report starts with overall descriptions, external interface requirements, functional and non-
functional requirements. Additionally, the report includes diagrams that represents the use cases,
activities, entity-relationships etc. to give a better understanding for how the system should be
implemented.
The report may include several acronyms and abbreviations that is specific for game
terminologies. To prevent any confusion, the report includes Appendix A: Glossary section which
explains the card game terminologies, acronyms and abbreviations.

1.4 Product Scope

In the SRS stage, our requirements are simply defined for account management, gameplay and
user interfaces for deck building and card analysis panel.
Software Requirements Specification for <Project> Page 2

1.5 References
<List any other documents or Web addresses to which this SRS refers. These may include user
interface style guides, contracts, standards, system requirements specifications, use case
documents, or a vision and scope document. Provide enough information so that the reader could
access a copy of each reference, including title, author, version number, date, and source or
location.>

2. Overall Description

2.1 Product Perspective

Our project, mobile card game, included in “turn based collectible card game” game type. The
project have several successful examples which are named as Legends of Runeterra, Heartstone,
Gwent etc. Our project will be inspired from these successful project that is exist in the
marketplace, with innovative features and gameplay rules. The reason of using the similar
interfaces of existing projects is making the game familiar with the players that are playing these
existing card games.
Software Requirements Specification for <Project> Page 3

Figure 1: Simple Diagram for System Components

Figure 1 represents the simple diagram that displays system components. Our system components
for this project are:
 Gameplay: The screen where the actual game is represented, which is the most important
component for our system to be completed.
 Deck Building Panel: The component of the system that is used by players to select their
cards and make their deck before playing. Deck building panel is highly important for
quality of the system.
 Login/Logout System: The component of the system where the players login/logout or
switch their accounts of the system.
 Game Settings/Account Settings: The system component that is designed for gameplay
settings, such as voice level, animation quality, 0
Software Requirements Specification for <Project> Page 4

2.2 Product Functions

Major product functions of the system is listed at below with brief explanations.

2.2.1 Register/Login/Logout

Users should be able to register to the game with valid e-mail address , unique username and
password. The system should give an error message if the username is already taken, if the e-mail is
invalid and if the password is too short.

2.2.2 Deckbuilding.

Users should be able to select their decks and see the cards inside of the deck. Additionally,
users should be able to add/remove cards from their deck based on their playstyles. Users should be
able to remove their existing deck or add a new one (There is a limit for number of decks).

2.2.3 Settings

Users should be able to manipulate their game settings or account settings. Game settings
include volume of game (music, action and environment) and graphic settings for optimizations.
Account settings include e-mail and profile picture changes.

2.3 User Classes and Characteristics

This project have 2 user classes, which can be named as player and admin. The characteristic of
the users are listed as subheadings at below.

2.3.1 Players

Players are the main actors of the system. They have a validated user account to play the game.
They can use all the components of the system that is mentioned at 2.1 Product Perspective section.
System development will be highly dependent on players actions and their feedbacks in order to
improve the system.

2.3.2 Admins
Software Requirements Specification for <Project> Page 5

Similar to players, admins have a validated user account to play the game. In order to differ if
the user of the system is player or admin, they have a specific “Admin” name included in their user
name. Admins often use their accounts to interact with the players, testing the system, monitoring
the behaviours of players and marketing promotions (showing new features in livestreams).

Moreover, admins are able to enter the beta environment of the game in order to test different
new features that will be added to game to observe minor/major bugs in the game.

2.4 Operating Environment

Our development and testing stage will use different operating environments in both hardware
and software. Our development stage will be started on computer with Windows 10 operating
system and continues with IOS mobile phones after the system will be integrated to support mobile
devices. Our testing stage will be mostly on mobile devices since the game will be mainly released
in mobile platform.

2.5 Design and Implementation Constraints

There are several constraints that effects the design and implementation of the system which are
listed at below.

2.5.1 Resource Allocation

Our main constraint is the limitation of memory management of mobile devices. Memory and
resource allocation of mobile devices are much lower than computer devices since they have
limited RAM, which ultimately leads to careful assets management that requires many tests and
time. Furhtermore, we need to decrease the runtime of system algorithms in order to prevent the
performance problems that highly effects the quality of system, such as sudden game crashes.

2.5.2 Storage Size

Mobile devices have limited storage sizes. We need to manage our system features carefully to
handle the storage size problems that system may possibly have.
Software Requirements Specification for <Project> Page 6

2.5.3 App Store Policies

There are several policies app stores that should be concerned. Most of the app stores have strict
policy for appropriate contents and mature contents. Furthermore, data collection and privacy
policies should be considered and the system must inform users how the data collected and handled.

Additionally, app stores may have a policy for notification and approval. Big updates and
changes may require the approval of the app store, which may delay the update of the system.

2.5.4 Testing

Testing is the essential part for software development to measure the overall quality and ensure
the compatibility of the system. Card games naturally require too many number of tests to be
conducted especially for card functionalities, since there are many different cards that have
different set of functions and there should be no override of functions between cards.

2.6 User Documentation

Our plans for user documentation outside of PPM, SRS and Final report is documenting the
gameplay tutorials especially for alpha testers in order to speed up the process where the game
features are difficult to understand. The gameplay tutorials will specify the account creation,
gameplay, deckbuilding and system settings.

2.7 Assumptions and Dependencies

The project is highly depended on performance of mobile platforms. Mobile games, if the game
has many contents, require attention for graphic management and memory and storage management
as it as also mentioned in Design and Implementation Constrains part.
Software Requirements Specification for <Project> Page 7

3. External Interface Requirements

3.1 User Interfaces

<Describe the logical characteristics of each interface between the software product and the
users. This may include sample screen images, any GUI standards or product family style guides
that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that
will appear on every screen, keyboard shortcuts, error message display standards, and so on.
Define the software components for which a user interface is needed. Details of the user interface
design should be documented in a separate user interface specification.>

3.2 Hardware Interfaces

<Describe the logical and physical characteristics of each interface between the software product
and the hardware components of the system. This may include the supported device types, the
nature of the data and control interactions between the software and the hardware, and
communication protocols to be used.>

3.3 Software Interfaces

<Describe the connections between this product and other specific software components (name
and version), including databases, operating systems, tools, libraries, and integrated commercial
components. Identify the data items or messages coming into the system and going out and
describe the purpose of each. Describe the services needed and the nature of communications.
Refer to documents that describe detailed application programming interface protocols. Identify
data that will be shared across software components. If the data sharing mechanism must be
implemented in a specific way (for example, use of a global data area in a multitasking operating
system), specify this as an implementation constraint.>

3.4 Communications Interfaces

<Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting. Identify any communication
standards that will be used, such as FTP or HTTP. Specify any communication security or
encryption issues, data transfer rates, and synchronization mechanisms.>

4. System Features
System features of our system is documented one by one at below:

4.1 Registration, Login/Logout Stage

4.1.1 Description and Priority

Software Requirements Specification for <Project> Page 8

User shall be able to sign up for the system and create accounts with their personal
information. The registration stage is one of the primary sections of the application because
it's the initial step required to access the application. If the user doesn't have an account, they
will press the "Sign In" button and enter their personal information (a valid email address)
and chosen details into the system. These details will be stored in the system's database. If
they already have an account, they can press the "Log In" button and enter their existing
information to access the system.Users can exist their account by clicking logout button

4.1.2 Stimulus/Response Sequences

When users create a new account within the system, they will need to choose a username
and password that comply with the system's rules (at least 8 characters long, including
uppercase and lowercase letters). After providing the necessary information, users will be
able to access their own profiles and start playing the game. User can exit game via clicking
exit button and can enter the game without signing again. Users can exit with clicking logout
button and will exit their account and have to enter account information for entering the
game

4.1.3 Functional Requirements

1. Users shall be able to sign into the game by entering their account user name, password.
2. Users shall be able to receive an “account successfully created” message after entering
validated information.
3. Users shall be able to get error message if their password is too short or if their username is
already taken.
4. Users shall be able to access their account the system confrim their password and user name.
5. Users shall able to logout from their account
6. Users shall be able to exit the game without signing out of their account
7. Users shall be able to get a warning message if they enter their username or password wrong.
Software Requirements Specification for <Project> Page 9

4.2 Deckbuilding

4.2.1 Description and Priority

Creating the card deck is necessary for users to utilize the main mechanics of the game .
Building card deck is one of the key features of the system. When creating their profile, users will
start with the cards provided by the system and progressively add cards they earn as they advance in
the game. Within the predefined card deck limit set by the game, users will construct their own
deck by combining these cards.

4.2.2 Functional Requirements

1. User shall be able to view all owned cards.

2. User shall be able to arrange owned cards by their mana levels.

3. User shall be able to sort owned cards alphabetically.
4. User shall be able to sort owned cards by their attack points.
5. User shall be able to sort owned cards by their defense points.
6. User shall be able to sort owned cards by card type.
7. User shall be able to view only the unique owned cards.
8. User shall be able to select cards for a deck based on deck size limitations.
9. User shall be able to remove selected cards for a deck from the deck.
10. User shall be able to view selected cards for a deck.
11. User shall be able to save the created deck.
12. User shall be able to delete the created deck.
13. User shall be able to duplicate the created deck.
14. User shall be able to assign a specific name to the created deck.
15. User shall be able to modify the name of the created deck.
16. User shall be able to view the average attack points of the created decks.
17. User shall be able to view the average defense points of the created decks.
18. User shall be able to view the average mana usage of the created decks.
19. User shall be able to view individual cards owned.
Software Requirements Specification for <Project> Page 10

20. User shall be able to view individual cards in a deck.

21. User shall be able to compare two selected cards from owned cards.
22. User shall be able to compare two selected cards from a deck.
23. Players should be able to specify the quantity of each card they wish to include in their
deck.

4.3 Gameplay

4.3.1 Description and Priority

Gameplay requirements are mostly focused on the overall gameplay features and actions that
players make. When the game starts, players should be able to do their decisions and make actions
based on different scenarios. Gameplay have the most important priorities since it is the main
feature that attracts the players to the game.

4.3.2 Functional Requirements

1. User shall be able to see his hand

2. User shall be able to change the cards before first turn starts if he/she wants
3. User shall be able to start the turn first or wait for opponent to take a turn
4. User shall be able to play a card if him/her mana enough
5. User shall be able to destroy opponent’s minions
6. User shall be able to pick one card from the deck every turn
7. User shall be able to heal himself/herself or his/her minions.
8. User shall be able to use his/her character or minions to deal damage to opponent’s character or
opponent’s minions
9. User shall be able to cast a spell to buff/heal/damage/shield minions or characters
10. User shall be able to end his/her turn by pressing the button
11. User shall be able to automatically end his/her turn when turn time is up
12. User shall be able to take damage when his/her deck is empty and no card can be picked
13. User shall be able to discard the card he/she picked from the deck when hand is full
Software Requirements Specification for <Project> Page 11

14. User shall be able to concede

15. User shall be able to drag and drop the card to the field to play
16. User shall be able to see the remaining card count on the deck

4.4 Settings

4.4.1 Description and Priority

Settings are essential to optimize the game for users own desire, which is one of the most
important requirement for the system. Settings include account settings and game settings, which
contains sounds, graphics and user profile changes.

4.4.2 Functional Requirements

1. User should be able to enter settings.

2. User should be able to enter their account settings for changing profile picture.
3. User should be able to enter their game settings for volume and graphic change.
4. User should be able to enter the advanced settings.

5. Other Nonfunctional Requirements

5.1 Performance Requirements

<If there are performance requirements for the product under various circumstances, state them
here and explain their rationale, to help the developers understand the intent and make suitable
design choices. Specify the timing relationships for real time systems. Make such requirements as
specific as possible. You may need to state performance requirements for individual functional
requirements or features.>

5.2 Safety Requirements

<Specify those requirements that are concerned with possible loss, damage, or harm that could
result from the use of the product. Define any safeguards or actions that must be taken, as well
as actions that must be prevented. Refer to any external policies or regulations that state safety
issues that affect the product’s design or use. Define any safety certifications that must be
satisfied.>
Software Requirements Specification for <Project> Page 12

5.3 Security Requirements

<Specify any requirements regarding security or privacy issues surrounding use of the product or
protection of the data used or created by the product. Define any user identity authentication
requirements. Refer to any external policies or regulations containing security issues that affect
the product. Define any security or privacy certifications that must be satisfied.>

5.4 Software Quality Attributes

<Specify any additional quality characteristics for the product that will be important to either the
customers or the developers. Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability,
and usability. Write these to be specific, quantitative, and verifiable when possible. At the least,
clarify the relative preferences for various attributes, such as ease of use over ease of learning.>

5.5 Business Rules

<List any operating principles about the product, such as which individuals or roles can perform
which functions under specific circumstances. These are not functional requirements in
themselves, but they may imply certain functional requirements to enforce the rules.>

6. Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the
project, and so on. Add any new sections that are pertinent to the project.>

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.>
Software Requirements Specification for <Project> Page 13

Appendix B: Analysis Models

Figure 2: Use Case Diagram for Register/Login to the System

Software Requirements Specification for <Project> Page 14

Figure 3: Use Case Diagram for General Gameplay

Software Requirements Specification for <Project> Page 15

Figure 4: Use Case Diagram for Deckbuilding

Software Requirements Specification for <Project> Page 16

Figure 5: Use Case Diagram for Settings

Software Requirements Specification for <Project> Page 17
Software Requirements Specification for <Project> Page 18

Figure 6: General Activity Diagram

Figure 7: Sequence Diagram for Login Event

Software Requirements Specification for <Project> Page 19

Figure 8: Sequence Diagram for Deckbuilding Event

Figure 9: Level 0 Data Flow Diagram

Software Requirements Specification for <Project> Page 20

Figure 10: Level 1 Data Flow Diagram for Deckbuilding Panel

Software Requirements Specification for <Project> Page 21

Figure 11: Level 1 Data Flow Diagram for Settings

Software Requirements Specification for <Project> Page 22

Figure 12: Entity-Relationship Diagram

Software Requirements Specification for <Project> Page 23

Figure 13: SWOT Analysis

Software Requirements Specification for <Project> Page 24

Figure 14: Affinity Diagram

Figure 15: Kano Analysis Model

Software Requirements Specification for <Project> Page 25

Figure 16: Burndown Chart

Software Requirements Specification for <Project> Page 26

Figure 17: Pareto Analysis and Pareto Chart

Software Requirements Specification for <Project> Page 27

Figure 18: Fishbone Diagram

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.>

Source: http://www.frontiernet.net/~kwiegers/process_assets/srs_template.doc