CSC SoftSpecs

7/27/2019 CSC SoftSpecs

1/10

Software RequirementsSpecification

for

Java Game Platform (Java GP)

Version 1.2 approved

Prepared by Lea Taylor

NovaSoft Laboratories

April 22, 2004

Copyright 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.


2/10

SoftwareRequirements Specification for Page ii

Table of Contents

1. Introduction................................................................................................................................1

2. Overall Description....................................................................................................................2

3. External Interface Requirements............................................................................................. 34. System Features......................................................................................................................... 4

5. Other Nonfunctional Requirements.........................................................................................5

6. Other Requirements.................................................................................................................. 7

Revision History

Name Date Reason For Changes Version

Lea Taylor Feb 17 Needed to add information to team member sects 1.0

Lea Taylor April 20 Final Draft needed for Product Roll Out 1.2


3/10

SoftwareRequirements Specification for Page 1

1. Introduction

1.1 Purpose

Novasoft Game Laboratories (NGL) is intent on bringing you the very best entertainment software.The Java Game Player is a graphical user interface (GUI) that provides a platform to connect various gamesinto one easy-to-use package. Initially containing games by the diligent workforce in Software Engineering4700 in Villanova University, the product shall offer other users to add in their own games once it is releasedto the public on April 29, 2004. This means that our product has limitless possibilities to expand into a gamesystem that is widely used and supported. Once released, NGL encourages users to build and play their owngames, since our growth is based on outside participation.

1.2 Document Conventions

This SRS is pretty straightforward, divided up into sections detailing an overall description, theexternal interface requirements, system features, and other nonfunctional requirements.

As this is the final draft, any future modifications of this document would involve adapting the productto changing systems and uses. We hope to have the product evolve to changing times as to ensure continueduse and success.

The Document and Specification team have prepared the overall information in this document to thebest of their ability. Once read, it is evident that each section is important to the overall SRS and significant tothe project in its own right.

1.3 Intended Audience and Reading Suggestions

This document is intended for any businesses interested in utilizing the services of NGL employees,

and any game developers interested in programming games for the Java Game Player. The SRS goes intodetail about what our program does, and is not necessary reading if all you want to do is play games. Theinformation here describes product features, company goals, and user requirements. The aim of NGL is tomake an easy-to-use interface for games, so there should be very little that is hard to understand in thedocument.

1.4 Product Scope

Our company is intent on bringing a interface for simple or complex games that is easy to use andeasily configurable. The main selling point to our game, other than providing endless hours of fun, is thatpeople are able to write their own games and add it to an ever-increasing library of games. This sharing ofdifferent ideas encourages community and promotes creativity in others to make new games. While strictly

non-profit on the outset, with the main goal being a good grade in Software Engineering, NGL is not barringthe possibility that financial gain could be made if the final product is deemed popular and workable. Ourintent is to release it online for free, and if people actually utilize it and make their own games, start to plan outways to make a profit from it, though this is a small possibility and isnt a problem for some time in the future.Ultimately, NGL is in the business of FUN, and making a game interface is a logical step in that direction.

1.5 References

Dr. Thomas Ways website: Head of Novasoft


4/10


http://www.csc.villanova.edu/~tway/- See site for more information on the company and product.

JBuilder newsgroups : http://support.borland.com/newsgroups/jbuilder.asp

Jbuilder download: http://www.borland.com/products/downloads/download_jbuilder.html

Rudimentary Sound Sample site:www.spies.com/SOX

2. Overall Description

2.1 Product Perspective

The Java Game Player is a new java-based game-playing program designed for a VillanovaUniversity Computer Science course. It is an environment that allows a user to play a variety of games, aswell as create and add new games on their own. This product does have similarities to other game playingprograms, but is a self-contained product of its own.

2.2 Product Functions

The Product Game Player:- Allows a user to upload a game of their own design.

- Allows user to select game to play from a number of pre-designed games, other user games, or

their own uploaded games.- Allow one game played per browser.

- Allow users to register with a name and password.

- Keep track of a users history with their password.

- Save a game to be completed later.

-End game

- Close program

2.3 User Classes and Characteristics

According to the Module and Support Team, the game modules will be Java Applets as this will helpintegrate the games into the Player System. The user will not see the background classes or history unless theydecide to develop their own game and implement it into the system. The module creator and the Front EndIntegration team who designed the system will be the only people with knowledge of the user class details andcharacteristics.

2.4 Operating EnvironmentThe Java Game Player resides on the websitehttp://ngl.binwar.com/javagp.html which is the

NovaSoft Laboratories website. The user will use the Java application on this site to play the various Javagame applications. There is no best operating system that NovaSoft is currently advocating as the bestsystem. The environment of the Java Game Player allows many people to access it and the best use out of itscreation.
http://www.csc.villanova.edu/~tway/http://support.borland.com/newsgroups/jbuilder.asphttp://www.borland.com/products/downloads/download_jbuilder.htmlhttp://www.spies.com/SOXhttp://www.spies.com/SOXhttp://ngl.binwar.com/javagp.htmlhttp://ngl.binwar.com/javagp.htmlhttp://www.csc.villanova.edu/~tway/http://support.borland.com/newsgroups/jbuilder.asphttp://www.borland.com/products/downloads/download_jbuilder.htmlhttp://www.spies.com/SOXhttp://ngl.binwar.com/javagp.html


5/10


2.5 Design and Implementation Constraints

The Java Game Player design had no budget for its development, which could affect its overallperformance and testing reliability. Due to the fact that the whole system needed to be completed in 4months, there was a serious time constraint put on the development of the system. In addition, the two officesare on different ends of the country so communication should be taken care of via e-mail and IM ortelephone.

Also, on the implementation end, as this game player system is new and innovative, it is moredifficult to anticipate how it will react to a wide range of users with different expectations, backgrounds, andexperience. There is currently no historical usage, so the constraints placed on the system may be eithersignificant or nonexistent.

2.6 User Documentation

There will be a brief set of instructions for each game, a user manual for the games in general, anemail address to contact with any problems and questions, and a user manual for the SDK. With all of thisinformation available to the user, there should be no difficulty in using the game playing system ortroubleshooting the player if any problems arise.

2.7 Assumptions and Dependencies

The game modules themselves may be dependent upon shared software sources from the Internet, butit is dependent upon the decision of each user as to whether they will develop their own games entirely on theirown.

3. External Interface Requirements

3.1 User Interfaces

The main interface of the Java Game Player is extremely user friendly with an arcade-like feel. Theappearance can be noted in figure A at the back of this specification. The standard buttons present allow theuser to load a game, edit a game, play a game, or get additional help on how to use the game platform. Errorswill display if the game is not loaded correctly by the user or the loaded user game is unplayable meaning Javaerrors are present leading to run-time/compile-time errors. Some keyboard shortcuts include pause buttonsand/or a quick ctrl-H to get to the help page of the platform. The games are organized by topic with buttonsfor each game selection in the category. Clearly, the user interface is easy to navigate and understand, as it isthe main component that will drive the game playing system. If it is un-usable then the game platform isuseless.

3.2 Hardware Interfaces

There is no distinct interface for hardware upon which the Java Game Player needs to reside. If uponusage, a Game Player user discovers that the system functions better on one type of hardware over another, itwould be important to take note of that fact.


6/10


3.3 Software Interfaces

This section will have more detailed information at a later date, however, NovaSoftLaboratories so far will be using databases to hold user login information and the NovaSoft staff informationas well. In addition, there will be a Java testing system used to ensure the modules that are loaded will workcorrectly on the platform. Also, JBuilder Java programming environment will be user to help develop the

modules and interfaces that drive the game platform system. Communication between all users and customersupport will be through email providers like the Villanova mail system or even Microsoft outlook depending onthe users personal emailing capabilities. The Villanova campus web server will be used to publish theNovaSoft Laboratories website and allow all of the game platform components to be available to users.

3.4 Communications Interfaces

This section will be determined at a later date. The section relies on the future work of the Front Endand Integration Team and possible the Module and Support Team as well.

4. System Features

4.1 System Feature 1: Create New Games

4.1.1 Description and Priority

Users can develop new games from original ideas or develop games based on preceding games,with consent from the previous developers.

High Priority

4.1.2 Stimulus/Response Sequences

Users choose the category of game they would like to create and then implement the tools andresources supplied by the platform.

4.1.3 Functional Requirements

REQ-1:Every game must have a splash screen or some sort of intro before playing the actualgame, so that the user knows what to press. (Ie. a graphic showing what keys.)

REQ-2: Developer can choose to define a set of keys to be used for each game, a standard(like Nintendo, has only an A & B button)

REQ-3: Connection to a high game server via a high game client code implemented at a laterdate in each game module (if the game has a high score system). The user can still play games,if not connected to the web.REQ-4: Games will be programmed as applets, as the web-browser implementation idea isused in the GUI to launch the games.

REQ-5: A standard WIDTH, HEIGHT for each applet (so everything fits).


7/10


REQ-6: A HELP document built into each game, so that the user can pause the game, andview help, if they dont know whats happening/or how to play. Will be a text file separatefrom the code itself, and it will be read into the module

REQ-7: All games should have some sort of rudimentary sound; in the file format:: TBD bymodule and support, by which file is the smallest, so that the final product does not takeforever to download possibly will be [ .au format: which is 8bits sampled at 8kHz

www.spies.com/SOX ].

REQ-8: There must be a way to turn music [on/off]

REQ-9: All graphics to be used and imported, must be in [.gif format]

REQ-10: SWING/AWT systems are available, however, the game player will concentrate onswing as it has some nicer features, and have all game modules using strictly the one we pick,so as everything is uniform.

REQ-11: Any other extra ideas to the skeleton must be sent to module and support beforeimplemented.

4.2 System Feature 2: Play Games

4.2.1 Description and Priority

Users can choose games to play from a variety of games listed by popularity. The list willcontain games developed on the platform.

- High Priority

4.2.2 Stimulus/Response Sequences

Users choose the game they wish to play and the game will appear in another window, so thatthe list of games will be easily accessible.

4.2.3 Functional Requirements

This section will be determined at a later date in better detail. The section relies on the futurework of the Module and Support Team.

REQ-1: One player game, arrows always be movement, p = pause, space bar or left mouseclick to fire weapons, or for action

5. Other Nonfunctional Requirements

5.1 Performance Requirements

The game-playing product can withstand large amounts of usage at one time and will notcrash or freeze at a moment of high activity and implementation. In addition, the system can accept


8/10


large amounts of information at once when memory driven games are uploaded into the system. It isnoted the maximum file size a certain module can take up on the upload option site.

Additionally, the number of modules accepted is high enough that memory levels on the webserver do not reach their max where no more modules would be accepted. However, a possiblesolution may be to place a limit on the number of modules the system can allow, but after a certaintime period of the module existing on the server, it is immediately removed/archived so that another

new module can be updated. This may be decided after the system has begun use and the developmentis re-evolved to future system requirements.

Other performance requirements will be added as the product is in use and the issuessurrounding performance will be addressed and new obstacles discovered.

5.2 Safety Requirements

In order to ensure the safety of The Java GP, NovaSoft ensures that accidents will not occur,and that if by chance one does, that the consequences of it are minimal. NovaSoft employs hazardavoidance, in which the system is designed so that hazards are avoided. Developers attempt to preventhazards by designing for the worst-case scenarios and preventing their occurrence, no matter howfarfetched the assumption. In addition, in the case that not all hazards are predicted, the system

includes protection features that will minimize fallout from various incidents. For instance, virusprotection is utilized to confirm that all modules are scanned for viruses, Trojans, or other harmfulattachments, which may infiltrate the game playing system.

These safety requirements have been implemented in the final stages of design, prior to thetesting stage so as to prevent any severe crashes or accidents during the testing stages.

5.3 Security Requirements

The database contains all of the user logins/passwords and other information that must beprotected from hackers who would try to infiltrate the system and steal any personal or userinformation and try to login under a stolen name. In addition, the modules that users load onto the site

and the sites original games are all protected from outside hackers who may want to negatively alterthe code thats present for current games on the site without logging in or registering. Moreover, themodules that are loaded into the system are scanned for viruses, Trojans, or other attachments that canweaken the security of the system.

As users of The Java Game Player can upload games from their home computer and log ontoour system with a password and login, it is important that we guarantee their security. Hence, SecureSocket Layer (SSL) encryption is used as well as a Digital Certificate, which would provide completesecurity for all parties involved in transactions. Secure Socket Layer is a World Wide web servicethat authenticates and encrypts the communication between clients and servers. Thus, all user andplatform connections can be protected.

In addition, a firewall (preferably the stateful packet inspection kind) is used to enhance thesecurity of the system by checking all email message content and filtering all the information that isaccepted from certain sites and users. Thus, data privacy is guaranteed for all parties involved and our

software system is invulnerable to middleman attacks.The security requirements of the game playing system will be implemented in the actual

design stages of the system during the integration of components and front end designing. This willguarantee that the security components are integrated correctly into the system and that there will beless vulnerability in the testing stages of the production process.


9/10


5.4 Software Quality Attributes

As for additional attributes, The Java game player is able to adapt and accept Java gamesformatted with upgraded Java Platforms and Standard Library editions, which may be more flexibleand have more capabilities than the Java code available at this products original release. As a result,this quality makes the game platform more flexible to the newer designed modules that it will

encounter. This ease of adaptability makes the maintenance of the system more complex andincreases the amount of testing over time. However, this also increases the usability of the system andprevents the game platform from becoming obsolete as the capabilities of the Java language increase.

In addition, there will be an email mechanism dedicated simply for Customer Service. Usersof the Java GP will be able to help the support and maintenance of the product by notifying NovaSoftof any system difficulties. As a result, the system will have increased reliability and usability. Also,this will ensure the quality of The Java GP will be the best possible for all users, as they will betesting the system from a different perspective than our testing team.

The software quality attributes will be addressed throughout the software design process andon into the maintenance stages after the product is released. It is an ongoing part of the production.

5.5 Business Rules

NovaSoft Laboratories will be confirming that all the IEEE standards, Java Standards, andRules of the World Wide Web Consortium will all be taken into consideration and followed to the bestof the companys ability in all aspects of project design, planning, and implementation.

The Web and Legal team members have ensured that the web site is as accessible to users aspossible and have obtained all licensing that is needed for our product. They have checked thatNovaSoft is not breaking any copyright or licensing laws with the product or any of the modules thatare uploaded into the game playing system.

Besides licensing, the Specification team, Support team, and Testing team have ensured thatall of the requirements of the system (such as the help guide) uphold all IEEE standards and willprevent any lawsuits or injustices on the part of the user. They are the backbone of preventing legalaction against NovaSoft for any failings in the requirements of the system.

Business rules are founded on the idea that once the company starts the product and releases it, allstandards are maintained without faltering. This avoids legal issues and possible business practiceviolations if all standards and practices are addressed at the start of the project.

6. Other Requirements

We need to obtain GPL license information and create a product use agreement and license . Otherrequirements will be added during the overall development and by the additional NovaSoft teams discretion.

Appendix A: Glossary

NGL: NovaSoft Game LaboratoriesIEEE: Institute of Electrical and Electronics EngineersJava GP: Java Game PlatformSSL: Secure Socket Layer encryptionSRS: Software Requirements SpecificationGUI: Graphical User Interface


10/10


Appendix B: Analysis Models

There are no models available at this time. There is a website page model and description of thehierarchy of pages, but that was inaccessible to the author at this junction.

Appendix C: To Be Determined ListThe functional success of the Java Game Player will eventually be determined after the product is

rolled out into the marketplace and available for usage.

CSC SoftSpecs

Documents

Transcript of CSC SoftSpecs