Software Requirements Specification

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.

Software Requirements Specification for <Project>

Page ii

Table of Contents
1. Introduction................................................................................................................................1 2. Overall Description....................................................................................................................2 3. External Interface Requirements............................................................................................. 3 4. System Features......................................................................................................................... 4 5. Other Nonfunctional Requirements.........................................................................................5 6. Other Requirements.................................................................................................................. 7

Revision History
Name Lea Taylor Lea Taylor Date Feb 17 April 20 Reason For Changes Version Needed to add information to team member sects 1.0 Final Draft needed for Product Roll Out 1.2

Software Requirements Specification for <Project>

Page 1

1.
1.1

Introduction
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 games into one easy-to-use package. Initially containing games by the diligent workforce in Software Engineering 4700 in Villanova University, the product shall offer other users to add in their own games once it is released to the public on April 29, 2004. This means that our product has limitless possibilities to expand into a game system that is widely used and supported. Once released, NGL encourages users to build and play their own games, 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, the external interface requirements, system features, and other nonfunctional requirements. As this is the final draft, any future modifications of this document would involve adapting the product to changing systems and uses. We hope to have the product evolve to changing times as to ensure continued use and success. The Document and Specification team have prepared the overall information in this document to the best of their ability. Once read, it is evident that each section is important to the overall SRS and significant to the 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 into detail about what our program does, and is not necessary reading if all you want to do is play games. The information here describes product features, company goals, and user requirements. The aim of NGL is to make an easy-to-use interface for games, so there should be very little that is hard to understand in the document.

1.4

Product Scope

Our company is intent on bringing a interface for simple or complex games that is easy to use and easily configurable. The main selling point to our game, other than providing endless hours of fun, is that people are able to write their own games and add it to an ever-increasing library of games. This sharing of different 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 barring the possibility that financial gain could be made if the final product is deemed popular and workable. Our intent is to release it online for free, and if people actually utilize it and make their own games, start to plan out ways 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

Software Requirements Specification for <Project>

Page 2

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

Overall Description
Product Perspective

The Java Game Player is a new java-based game-playing program designed for a Villanova University Computer Science course. It is an environment that allows a user to play a variety of games, as well as create and add new games on their own. This product does have similarities to other game playing programs, 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 help integrate the games into the Player System. The user will not see the background classes or history unless they decide to develop their own game and implement it into the system. The module creator and the Front End Integration team who designed the system will be the only people with knowledge of the user class details and characteristics.

2.4

Operating Environment

The Java Game Player resides on the website http://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 Java game applications. There is no best operating system that NovaSoft is currently advocating as the best system. The environment of the Java Game Player allows many people to access it and the best use out of its creation.

Software Requirements Specification for <Project>

Page 3

2.5

Design and Implementation Constraints

The Java Game Player design had no budget for its development, which could affect its overall performance and testing reliability. Due to the fact that the whole system needed to be completed in 4 months, there was a serious time constraint put on the development of the system. In addition, the two offices are on different ends of the country so communication should be taken care of via e-mail and IM or telephone. Also, on the implementation end, as this game player system is new and innovative, it is more difficult to anticipate how it will react to a wide range of users with different expectations, backgrounds, and experience. There is currently no historical usage, so the constraints placed on the system may be either significant 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, an email address to contact with any problems and questions, and a user manual for the SDK. With all of this information available to the user, there should be no difficulty in using the game playing system or troubleshooting 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, but it is dependent upon the decision of each user as to whether they will develop their own games entirely on their own.

3.
3.1

External Interface Requirements

User Interfaces

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

3.2

Hardware Interfaces

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

Software Requirements Specification for <Project>

Page 4

3.3

Software Interfaces

This section will have more detailed information at a later date, however, NovaSoft Laboratories so far will be using databases to hold user login information and the NovaSoft staff information as well. In addition, there will be a Java testing system used to ensure the modules that are loaded will work correctly 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 customer support will be through email providers like the Villanova mail system or even Microsoft outlook depending on the users personal emailing capabilities. The Villanova campus web server will be used to publish the NovaSoft 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 End and Integration Team and possible the Module and Support Team as well.

4.
4.1

System Features
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 and resources 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 actual game, 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 later date 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 is used in the GUI to launch the games. REQ-5: A standard WIDTH, HEIGHT for each applet (so everything fits).

Software Requirements Specification for <Project>

Page 5

REQ-6: A HELP document built into each game, so that the user can pause the game, and view help, if they dont know whats happening/or how to play. Will be a text file separate from 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 by module and support, by which file is the smallest, so that the final product does not take forever 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 on swing 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 before implemented.

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 will contain 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 that the 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 future work of the Module and Support Team. REQ-1: One player game, arrows always be movement, p = pause, space bar or left mouse click to fire weapons, or for action

5.
5.1

Other Nonfunctional Requirements

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

Software Requirements Specification for <Project>

Page 6

large amounts of information at once when memory driven games are uploaded into the system. It is noted 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 web server do not reach their max where no more modules would be accepted. However, a possible solution may be to place a limit on the number of modules the system can allow, but after a certain time 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 development is re-evolved to future system requirements. Other performance requirements will be added as the product is in use and the issues surrounding 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 hazard avoidance, in which the system is designed so that hazards are avoided. Developers attempt to prevent hazards by designing for the worst-case scenarios and preventing their occurrence, no matter how farfetched 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, virus protection is utilized to confirm that all modules are scanned for viruses, Trojans, or other harmful attachments, which may infiltrate the game playing system. These safety requirements have been implemented in the final stages of design, prior to the testing 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 be protected from hackers who would try to infiltrate the system and steal any personal or user information 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 alter the code thats present for current games on the site without logging in or registering. Moreover, the modules that are loaded into the system are scanned for viruses, Trojans, or other attachments that can weaken the security of the system. As users of The Java Game Player can upload games from their home computer and log onto our system with a password and login, it is important that we guarantee their security. Hence, Secure Socket Layer (SSL) encryption is used as well as a Digital Certificate, which would provide complete security for all parties involved in transactions. Secure Socket Layer is a World Wide web service that authenticates and encrypts the communication between clients and servers. Thus, all user and platform connections can be protected. In addition, a firewall (preferably the stateful packet inspection kind) is used to enhance the security of the system by checking all email message content and filtering all the information that is accepted 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 will guarantee that the security components are integrated correctly into the system and that there will be less vulnerability in the testing stages of the production process.

Software Requirements Specification for <Project>

Page 7

5.4

Software Quality Attributes

As for additional attributes, The Java game player is able to adapt and accept Java games formatted with upgraded Java Platforms and Standard Library editions, which may be more flexible and 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 and increases the amount of testing over time. However, this also increases the usability of the system and prevents 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. Users of the Java GP will be able to help the support and maintenance of the product by notifying NovaSoft of 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 be testing the system from a different perspective than our testing team. The software quality attributes will be addressed throughout the software design process and on 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, and Rules of the World Wide Web Consortium will all be taken into consideration and followed to the best of 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 as possible and have obtained all licensing that is needed for our product. They have checked that NovaSoft is not breaking any copyright or licensing laws with the product or any of the modules that are uploaded into the game playing system. Besides licensing, the Specification team, Support team, and Testing team have ensured that all of the requirements of the system (such as the help guide) uphold all IEEE standards and will prevent any lawsuits or injustices on the part of the user. They are the backbone of preventing legal action 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, all standards are maintained without faltering. This avoids legal issues and possible business practice violations 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. Other requirements will be added during the overall development and by the additional NovaSoft teams discretion.

Appendix A: Glossary
NGL: NovaSoft Game Laboratories IEEE: Institute of Electrical and Electronics Engineers Java GP: Java Game Platform SSL: Secure Socket Layer encryption SRS: Software Requirements Specification GUI: Graphical User Interface

Software Requirements Specification for <Project>

Page 8

Appendix B: Analysis Models

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

Appendix C: To Be Determined List

The functional success of the Java Game Player will eventually be determined after the product is rolled out into the marketplace and available for usage.