software requirements specification - web.cs.dal.cadecoste/seng/srs_group6.pdfsoftware requirements...

Software Requirements Specification for Interstitial Viewer

Software Requirements Specification

for

Interstitial Viewer

Version 1.0 approved

Prepared by Benjamin DeCosteJayde Fanjoy

Karl LeuschenTravis RobertsBret Schofield

CSCI 3130 – Group 6

January 31, 2012

Copyright © 2012. Permission is granted to use, modify, and distribute this document.


Table of Contents

Table of ContentsRevision History1. Introduction

1.1 Purpose1.2 Document Conventions1.3 Intended Audience and Reading Suggestions1.4 Product Scope1.5 References

2. Overall Description2.1 Product Perspective2.2 Product Functions2.3 User Classes and Characteristics2.4 Operating Environment2.5 Design and Implementation Constraints2.6 User Documentation2.7 Assumptions and Dependencies

3. External Interface Requirements3.1 User Interfaces3.2 Hardware Interfaces3.3 Software Interfaces3.4 Communications Interfaces

4. System Features4.1 Starting the Client4.2 Starting the Server4.3 Moving

5. Other Nonfunctional Requirements5.1 Performance Requirements5.2 Safety Requirements5.3 Security Requirements5.4 Software Quality Attributes5.5 Business Rules

6. Other RequirementsAppendix A: GlossaryAppendix B: Analysis ModelsAppendix C: To Be Determined List

Revision History

Name Date Reason For Changes Version

Benjamin DeCoste Jan 31, 2012

Original Document 1.0



1. Introduction1. Purpose

The goal of this project is to show whether or not it is possible to implement an augmentedreality using GPS, compass, and gyroscope to track where a player is in the game at any giventime, 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 currentgame 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 ConventionsBeing 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 SuggestionsThis 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 ScopeRefer to project plan.

5. ReferencesWe have no references at this point.

2. Overall Description1. 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 Functions2.2.1 Starting the ClientThe 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 ServerThe 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 MovementThe 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 CharacteristicsThe 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 Environment2.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 ConstraintsThe 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 DocumentationThere 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 DependenciesWe 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 Requirements1. User InterfacesServer Side Application:The server application will be constructed using simple Java Swing objects. There will be a drop-down 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 InterfacesThe 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 chip-set to relay data to and from the server application.

3. Software InterfacesThe 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 InterfacesThe 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 Server4.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.


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.


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 Requirements1. 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 RequirementsDue 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 RequirementsNo 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 AttributesThe 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 RulesOnly users with valid credentials for the game world should be able to use the software.


software requirements specification - web.cs.dal.cadecoste/seng/srs_group6.pdfsoftware requirements...

Documents