Software Requirements Specification for Interstitial Viewer

Software Requirements Specification for Interstitial Viewer Version 1.0 approved Prepared by Benjamin DeCoste Jayde Fanjoy Karl Leuschen Travis Roberts Bret Schofield CSCI 3130 Group 6 January 31, 2012

Table of Contents Table of Contents Revision History 1. Introduction 1.1 Purpose 1.2 Document Conventions 1.3 Intended Audience and Reading Suggestions 1.4 Product Scope 1.5 References 2. Overall Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Classes and Characteristics 2.4 Operating Environment 2.5 Design and Implementation Constraints 2.6 User Documentation 2.7 Assumptions and Dependencies 3. External Interface Requirements 3.1 User Interfaces 3.2 Hardware Interfaces 3.3 Software Interfaces 3.4 Communications Interfaces 4. System Features 4.1 Starting the Client 4.2 Starting the Server 4.3 Moving 5. Other Nonfunctional Requirements 5.1 Performance Requirements 5.2 Safety Requirements 5.3 Security Requirements 5.4 Software Quality Attributes 5.5 Business Rules 6. Other Requirements Appendix A: Glossary Appendix B: Analysis Models Appendix C: To Be Determined List Revision History Name Date Reason For Changes Version Benjamin DeCoste Jan 31, 2012 Original Document 1.0

1. Introduction 1. Purpose The goal of this project is to show whether or not it is possible to implement an augmented reality using GPS, compass, and gyroscope to track where a player is in the game at any given time, and track where the user goes depending on where he or she moves in the real world. This project is a proof of concept to show whether or not it can be achieved using current game architecture and framework (ie open wonderland). The player should be able to navigate the game world, using the viewer, wherever he or she is, as long as he or she can be connect to the other players using the game. That player should be able to see game objects in real distance from the player. 2. Document Conventions Being in the early stages of developing our project we are still creating document conventions as we go along. Two conventions that we have already established are: Any code written in documents will have a monospaced font We will refer to our project as viewer instead of interstitial viewer: world overlay 3. Intended Audience and Reading Suggestions This document will only be intended for our client and internal developers. Our information is organized into six main categories which include an Introduction, Overall Description, External Interface Requirements, System Features, Other Nonfunctional Requirements, and Other Requirements. For internal developers we would suggest reading all six sections of this SRS document and for our client who will probably be less interested in the more technical side of the project we would suggest reading the entire document as well, excluding the section on External Interface Requirements. 4. Product Scope Refer to project plan. 5. References We have no references at this point. 2. Overall Description 1. Product Perspective Product is an interstitial viewer/world overlay. It is an add-on to an already existing game called L Or de L Acadie. This game is built on an open source software framework called Open Wonderland. The player should be able to use this product to navigate the game world, wherever he or she is, as long as he or she can be connect to the other players using the game. That player should be able to see game objects in real distance from the player. The larger game, L Or de L Acadie, involves a player going around a map and collecting coins. This program should allow a player to use an android in a designated game space to communicate with the main game to explore the map in a more unrestricted way.

2. Product Functions 2.2.1 Starting the Client The Phone must be able to communicate with the main game. A client is designed to be started by the user when he logs into the game which will contact a server that is already running on the computer hosting the main game. 2.2.1 Starting the Server The Main Game must be set up to communicate with the phone. A server should be started up when the main program starts up that listens for a client. 2.2.1 Movement The Software must be able to Keep track of the user s movements in order to have a smooth experience during the game. This part will communicate with the client on the user s phone. 3. User Classes and Characteristics The user of this software will be average gamers and most likely undergraduates in computer science. The average users will have no security privileges, and no programming or developing experience necessary. In particular someone with no gaming experience should be able to download the application and use it with little or no explanation of how to use it. 4. Operating Environment 2.4.1 Mobile Client Platform The program will run on the android operating system and use the hardware integrated into the phone. In particular the important hardware that will be used constantly during the run time of the program is the GPS, gyroscope, accelerometer and compass. 2.4.2 Stationary Server Platform The server will be a desktop application that will run during the same time as the game. It will run on a stationary computer with the same specs has the main game (Exact specifications are still TBD). 2.4.3 The Physical Environment The physical environment of which the game takes place is also of concerned has movement and GPS technology is affect by where the hardware is. This may limit where inside a building the game can take place. Also there is a chance the game could be used outside and the hardware involved must be able to stand up to such conditions. 5. Design and Implementation Constraints The game will ask for credentials when logging in that will be verified by the main game. The phone platform may be limited to the model originally developed for the game (2.2 Froyo or higher) and other phone models that have all the same features and the same outgoing protocols.

After the schedule dead-line the staff can be contacted for any questions about the product but the code is no longer maintained by the group. 6. User Documentation There will be a tutorial session to each player before playing the game. The system will be design to be quick to learn and easy to use. 7. Assumptions and Dependencies We are assuming that the Open Wonderland toolkit will be stable and easy to work with. We are also assuming that the main game will have protocols ready to send out information about the map and other game items. 3. External Interface Requirements 1. User Interfaces Server Side Application: The server application will be constructed using simple Java Swing objects. There will be a dropdown menu at the top which will allow the user to start and stop the server as well as tweak server settings using additional prompts. The body of the server application window will contain a scrollable view of the server log. This log will contain information about connected users and detailed information pertinent to debugging. Android Client Application: The client application on the Android will be constructed using Android s native View catalogue. Upon starting the program, the first screen will contain an EditText box which will allow the user to enter the server s host name or IP address. Below that will be a connect button which, upon clicking, will create a connection to the server and switch to the second view. The second view will be a full-screen view of the server s screen that is updated in real-time. A pop-up context menu will allow the user to disconnect from the server. Any error messages will be handled by Android s Toast object. This object creates a small black pop-up dialogue at the bottom of the screen that will notify users of any errors. 2. Hardware Interfaces The Android client will make use of any Android supported environmental monitors (e.g. GPS, compass, accelerometers). It will also take full advantage of the on-board 802.11N Wireless chipset to relay data to and from the server application. 3. Software Interfaces The Server Application will interact with the Openwonderland environment through Twinspace and Openwonderland s loadable modules. The specifics of these interactions will be determined after researching the capabilities of Twinspace and the Openwonderland modules. 4. Communications Interfaces The Android application and Server Application will communicate using Java s socket networking which uses TCP/IP networking. Screenshots will be sent by the server as byte arrays. Environmental sensor data will be sent by the Android as sensor information packages through Java s ObjectOutputStream. A 200Mbps wifi connection between the Server Application and Android Application would be optimal. Transferring the Server Application s screenshots will be very network heavy unless some type of optimization is used. Server authentication and data encryption should be considered to disallow unauthorized users from logging in to the server, but is outside the scope of this project.

4. System Features 1. Starting the Client 4.1.1 Description and Priority Starting the client. This will be the most integral component of the application. The client will start this activity whenever he or she wants to start the interstitial viewer and the game experience. It currently has a medium priority and it will require the server feature to be implemented already before it can be constructed. 4.1.2 Stimulus/Response Sequences The user must already have the server running before he/she can start this activity. It will be launched from an application icon on the user s phone. Once logged in the user will be prompted to give credentials. And the application will return confirmation regarding the success of the user input. 4.1.3 Functional Requirements This feature depends on the Server being implemented and running. The user must be able to connect to a desktop running the application and have a phone capable of running the application. Details regarding technical specifications that must be met from both devices will be revealed as the application is further developed and implemented (TBD). REQ-1: The client will require a server to be running remotely. REQ-2: The client program will run on an Android phone capable of running the program. The exact specifications are TBD. 2. Starting the Server 4.2.1 Description and Priority

Starting the server requires the user to launch a desktop application that will feed information from the game to the Android phone. This is currently the highest priority task that we have, as it is the backbone architecture for the game. 4.2.2 Stimulus/Response Sequence The user will launch this client on a desktop and enter their credentials. The server application will then confirm whether or not connection was successful. The server will then idle until the Client program tries to make a connection. No user interaction will be required after startup. 4.2.3 Functional Requirements REQ-1: This will just take a desktop or laptop computer. Hardware requirements should be quite low, but exact specification is TBD. Moving 4.3.1 Description and Priority This is the mechanism that will allow the player to interact with the game once the client and server are running. It is currently a low priority feature. 4.3.2 Stimulus/Response Sequence The user will not be prompted with any sort of command. When the player moves in the game (by walking in real life) the screen will update with the players new coordinates. 4.3.3 Functional Requirements REQ-1: This activity will require an Android phone (At least 2.2 Froyo or higher) capable of drawing the game (Exact specifications are still TBD). 5. Other Nonfunctional Requirements 1. Performance Requirements Requirement Metric Value Smooth visuals Frames per second >= 15 fps

Precision of placement/motion of player in game world None device dependent (software should not introduce additional error in location) 2. Safety Requirements Due to the potentially immersive nature of augmented/virtual reality, users of the viewer are at risk of stumbling and/or tripping on uneven real world terrain, and also colliding with real world objects. To mitigate the risk of harm, a warning should be displayed on the viewing device at some point before the game world is displayed. 3. Security Requirements No additional security measures, beyond those already present in establishing and maintaining a connection to the game world (e.g. log in credentials), are required. 4. Software Quality Attributes The software should be well tested, with tests targeting the implementation of all the functional requirements. Test code coverage should be greater than 80%. The code should be well documented each class, method and property should be documented in the code base, following JavaDoc conventions. 5. Business Rules Only users with valid credentials for the game world should be able to use the software.