Software Requirements Specification

For

Virtual Classroom
Prepared by Tal Lev

January 1st 2010

Software Requirements Specification for Virtual Classroom

Page ii

Table of Contents
Table of Contents .......................................................................................................................... ii Revision History ........................................................................................................................... iii 1. Introduction ..............................................................................................................................1
1.1 1.2 1.3 1.4 1.5 2.1 2.2 2.3 2.4 2.5 2.6 Purpose ........................................................................................................................................ 1 Document Conventions ............................................................................................................... 1 Intended Audience and Reading Suggestions ............................................................................. 1 Project Scope ............................................................................................................................... 1 References ................................................................................................................................... 1 Product Perspective ..................................................................................................................... 2 Product Features .......................................................................................................................... 2 User Classes and Characteristics ................................................................................................. 2 Operating Environment ............................................................................................................... 2 Design and Implementation Constraints ..................................................................................... 2 User Documentation .................................................................................................................... 2

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

3. System Features........................................................................................................................3
3.1 Virtual Whiteboard ...................................................................................................................... 3 3.1.1 Description and Priority .......................................................................................................... 3 3.1.2 Stimulus/Response Sequences ................................................................................................ 3 3.1.3 Functional Requirements ........................................................................................................ 3 3.2 Content Windows ........................................................................................................................ 3 3.2.1 Description and Priority .......................................................................................................... 3 3.2.2 Stimulus/Response Sequences ................................................................................................ 3 3.2.3 Functional Requirements ........................................................................................................ 3 3.3 Save Session ................................................................................................................................ 4 3.3.1 Description and Priority .......................................................................................................... 4 3.3.2 Stimulus/Response Sequences ................................................................................................ 4 3.3.3 Functional Requirements ........................................................................................................ 4 3.4 Load Session................................................................................................................................ 4 3.4.1 Description and Priority .......................................................................................................... 4 3.4.2 Stimulus/Response Sequences ................................................................................................ 4 3.4.3 Functional Requirements ........................................................................................................ 4 4.1 User Interfaces ............................................................................................................................. 6 4.2............................................................................................................................................................. 7 4.2 Hardware Interfaces .................................................................................................................... 7 4.3 Software Interfaces ...................................................................................................................... 7 4.4 Communications Interfaces ......................................................................................................... 7 5.1 5.2 5.3 Performance Requirements ......................................................................................................... 8 Safety Requirements .................................................................................................................... 8 Security Requirements ................................................................................................................ 8

4. External Interface Requirements ...........................................................................................6

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

Appendix A: The Wii remote ........................................................................................................8 Appendix B: Wiimote communication protocol ..........................................................................8 Appendix C: Project description ..................................................................................................8 Appendix D: Screen shots .............................................................................................................8
Wiimote.cs : ........................................................................................................................................... 13 WiiMouseControlModule.cs: ................................................................................................................ 13

Software Requirements Specification for Virtual Classroom

Page iii

Revision History
Name Tal Lev Date 20/2/201 0 Reason For Changes Creation Version 1.0

Software Requirements Specification for Virtual Classroom

Page 1

1. Introduction
1.1 Purpose
The system shall provide a virtual workspace for the user, consisting of a virtual whiteboard, a set of content windows and an ability to save the current data.

1.2 Document Conventions

TBD

1.3 Intended Audience and Reading Suggestions

The different types of reader that the document is intended for are developers, project managers, testers, and documentation writers. The rest of this SRS contains the details and specifications of the system. It is organized according to the modules that the system is using.

1.4 Project Scope

The software will be a window that contains windows, on the main surface of the window the user could write and sketch, and the other windows will contain content such as videos, diagrams, pdf files and pictures. The purpose of the software is to simplify the way a lecturer conducts his lecture by gathering all the instructional material in one place and an organized one.

1.5 References
www.wii.com - The consoles main page. www.nintendo.com - Nintendo the maker of the wii console and remote. http://en.wikipedia.org/wiki/Wii_Remote - Information of the wii remote technology from Wikipedia.

Software Requirements Specification for Virtual Classroom

Page 2

2. Overall Description
2.1 Product Perspective
This product is a new, self-Contained product.

2.2 Product Features

Virtual tabbed whiteboard. Content window for pictures. Content window for movies. Content window for PDFs. Content window for a web page.

2.3 User Classes and Characteristics

The main User Class that is going to use this product is the teaching group (teachers, lecturers, etc.), and it's frequency of use could be on a daily basis. Because this product is innovative this user class will need some training to get used to the new technologies and to get experienced. Another User Class to be using this product is guiding personnel which will be needed to guide and train the first use class. Its frequency of use would be on demand whenever there would be the need for guidance and training.

2.4 Operating Environment

For the moment the system will be compatible with Intel chipped computers running Windows Vista and up with the .NET Framework 3.5 installed.

2.5 Design and Implementation Constraints

For now the only way this technology is available is with the remote of the game console Wii by Nintendo, it's quite large and needs to be placed in a specific location in order for the product to run effectively. Because of the technology the user would have to stand right in front the viewing adapter which limits his move in the room.

2.6 User Documentation

For now there will be no user documentation.

Software Requirements Specification for Virtual Classroom

Page 3

3. System Features
3.1 Virtual Whiteboard
3.1.1 Description and Priority
A main feature of the program is the virtual whiteboard which is the area on the screen that will provide the user the ability to write and sketch in various colors and highlights, the user could also go through pages as if he/she would do so in a notebook. This feature is of high importance.

3.1.2 Stimulus/Response Sequences

The sequences of user actions and system responses that stimulate the behavior defined for this feature are: a. Performing a click with the hands input -> starts to write in the area. b. Releasing the click with the hands input -> stops to write in the area.

3.1.3 Functional Requirements

Recognize movement, recognize click, draw according to movement and stop drawing on release.

REQ-1: REQ-2: REQ-3: REQ-4:

The product will recognize the input adapter and will control the mouse movements. The product will recognize the change in the adapter that states a click. The product will draw a path as the adapter moves in front of the display. The product will stop drawing as it recognizes a release click from the adapter.

3.2 Content Windows

3.2.1 Description and Priority
Another main feature of the program is the Content Windows which are inner windowlike areas inside the main products' window that contains them, the windows should enable the user to load different types of content (such as pictures, videos, PDFs)

3.2.2 Stimulus/Response Sequences

The sequences of user actions and system responses that stimulate the behavior defined for this feature are: a. Open the drawer of content -> drawer opens. b. Drag the selected content to the main window -> the content opens in the selected space with the appropriate window. c. Other content specific interactions.

3.2.3 Functional Requirements

Recognize click on the drawer, recognize movement in the opening direction, move drawer according to movement, drag drop of the content element and open relevant window according to content.

Software Requirements Specification for Virtual Classroom

Page 4

REQ-1: REQ-2: REQ-3: REQ-4: REQ-5:

The product will recognize the input adapter and will control the mouse movements and clicks. The product will move the drawer according to the input adapter. The product will provide a list of the contents in a specified directory. The product will enable a drag drop feature from the drawer to the main window area. The product will recognize the content type and open the relevant window.

3.3 Save Session

3.3.1 Description and Priority
A secondary feature of the program is the ability to save a session in progress which means take all the written data and the content windows and save them to file.

3.3.2 Stimulus/Response Sequences

The sequences of user actions and system responses that stimulate the behavior defined for this feature are: a. Press the save button -> saves the data to file.

3.3.3 Functional Requirements

Recognize click on save button, pack all session elements and save the data to file.

REQ-1: REQ-2: REQ-3: REQ-4:

The product will recognize the input adapter and will control the mouse movements and clicks. The product will recognize the click on the save button. The product will gather all the elements in the session (writings and content) and will pack them to a predetermined data model. The product will take the model and will save it to file.

3.4 Load Session

3.4.1 Description and Priority
Following the previous feature is the ability to load data that has been saved onto a file.

3.4.2 Stimulus/Response Sequences

The sequences of user actions and system responses that stimulate the behavior defined for this feature are: a. Performing a click on the load button -> opens a file dialog. b. Select a file from the file dialog -> load the session selected.

3.4.3 Functional Requirements

Recognize click on load button, open file dialog, check file type get the data model from the file and unpack the model to the current session.

REQ-1: REQ-2: REQ-3: REQ-4:

The product will recognize the input adapter and will control the mouse movements and clicks. The product will recognize the predetermined file types in the file dialog. The product will be able to check validation of the file selected. The product will be able to load the data model from the file.

Software Requirements Specification for Virtual Classroom

Page 5

REQ-5:

The product will be able to unpack the session from the data model.

Software Requirements Specification for Virtual Classroom

Page 6

4. External Interface Requirements

4.1 User Interfaces
The UI should consist of the main sketch area that fills the whole window, a tool bar at the top that has 3 buttons (Load, Save and Settings) and the content drawer at the right most middle of the screen, the screen should overlap the task bar so it consumes the whole screen space.

4.2

Software Requirements Specification for Virtual Classroom

Page 7

4.2 Hardware Interfaces

The hardware interface to be used with this product will be the Bluetooth adapter, synchronized to the Wii remote.

4.3 Software Interfaces

There would be a use of the library of the Wiimote module to have the ability to communicate with the device and get info according to the input read by the device. That information would then be used to triangulate the position on screen where the mouse pointer should be and then communicate with the OS to get the mouse handle and move it to the desired position. Another input would be to identify the execution of a click in the device and according to that get the OS to perform that click by the mouse in the given position. There would also be an interface with the file system to enable saving and loading data.

4.4 Communications Interfaces

This product will use the Bluetooth adapter with a unique protocol to communicate with the Wii remote device, getting from the device a veriaty of data such as information on IR leds it detects and battery status (as well as button state and other data not concerned by the product).

Software Requirements Specification for Virtual Classroom

Page 8

5. Other Nonfunctional Requirements

5.1 Performance Requirements
The system shall be as responsive as possible when it comes to the sketching and writing area, this allows the user for a better experience of use. Other than that there are no more Performance issues that should be considered.

5.2 Safety Requirements

For a general rule there should be a secure holster stand for the Wii remote device so it would not be harmed in any way. Furthermore because of the fact that the user isn't up close to the screen but in a range of a few feet from it there should be a continuous self awareness of the surroundings so no one would get hurt in the duration of the use of the product.

5.3 Security Requirements

TBD

Appendix A: The Wii remote Appendix B: Wiimote communication protocol Appendix C: Project description Appendix D: Screen shots

Software Requirements Specification for Virtual Classroom

Page 9

The Wii Remote

The Wii Remote, sometimes unofficially nicknamed "Wiimote", is the primary controller for Nintendo's Wii console. A main feature of the Wii Remote is its motion sensing capability, which allows the user to interact with and manipulate items on screen via gesture recognition and pointing through the use of accelerometer and optical sensor technology. Another feature is its expandability through the use of attachments. The attachment bundled with the Wii console is the Nunchuk, which complements the Wii Remote by providing functions similar to those in gamepad controllers. The controller was revealed at the Tokyo Game Show on October 14, 2005, with the name "Wii Remote" announced April 27, 2006. It has since received much attention due to its unique features and the contrast between it and typical gaming controllers. It has also gained significant attention from hackers using it to control non Wii-related devices through Wii homebrew. The Wii Remote has the ability to sense acceleration along three axes through the use of an ADXL330 accelerometer. The Wii Remote also features a PixArt optical sensor, allowing it to determine where the Wii Remote is pointing. Unlike a light gun that senses light from a television screen, the Wii Remote senses light from the console's Sensor Bar (model number RVL-014), which allows consistent usage regardless of a television's type or size. The Sensor Bar is about 20 cm (8 in) long and features ten infrared LEDs, five at each end of the bar The LEDs furthest from the center are pointed slightly outwards, the LEDs closest to the center are pointed slightly inwards, while the rest are pointed straight forward. The Sensor Bar's cable is 353 cm (11 ft 7 in) in length. The bar may be placed above or below the television, and should be centered. If placed above, the sensor should be in line with the front of the television, and if placed below, should be in line with the front of the surface the television is placed on. It is not necessary to point directly at the Sensor Bar, but pointing significantly away from the bar will disrupt position-sensing ability due to the limited viewing angle of the Wii Remote. Use of the Sensor Bar allows the Wii Remote to be used as an accurate pointing device up to 5 meters (approx. 16 ft) away from the bar. The Wii Remote's image sensor is used to locate the Sensor Bar's points of light in the Wii Remote's field of view. The light emitted from each end of the Sensor Bar is focused onto the image sensor which sees the light as two bright dots separated by a distance "mi" on the image sensor. The second distance "m" between the two clusters of light emitters in the Sensor Bar is a fixed distance. From these two distances m and mi, the Wii CPU calculates the distance between the Wii Remote and the Sensor Bar using triangulation. In addition, rotation of the Wii Remote with respect to the ground can also be calculated from the relative angle of the two dots of light on the image sensor. Games can be programmed to sense whether the image sensor is covered, which is demonstrated in a Microgame of Smooth Moves, where if the player does not uncover the sensor, the champagne bottle that the remote represents will not open. The Sensor Bar is required when the Wii Remote is controlling up-down, left-right motion of a cursor or reticle on the TV screen to point to menu options or objects such as enemies in firstperson shooters. Because the Sensor Bar also allows the Wii Remote to calculate the distance between the Wii Remote and the Sensor Bar, the Wii Remote can also control slow forwardbackward motion of an object in a 3-dimensional game. Rapid forward-backward motion, such as punching in a boxing game, is controlled by the acceleration sensors. Using these acceleration sensors (acting as tilt sensors), the Wii Remote can also control rotation of a cursor or other objects.

Software Requirements Specification for Virtual Classroom

Page 10

The use of an infrared sensor to detect position can cause some detection problems when other infrared sources are around, such as incandescent light bulbs or candles. This can be easily alleviated by using fluorescent lights around the Wii, which emit little to no infrared light. Innovative users have used other sources of IR light as Sensor Bar substitutes such as a pair of flashlights and a pair ofcandles. Such substitutes for the Sensor Bar illustrate the fact that a pair of non-moving lights provide continuous calibration of the direction that the Wii Remote is pointing and its physical location relative to the light sources. There is no way to calibrate the position of the cursor relative to where the user is pointing the controller without the two stable reference sources of light provided by the Sensor Bar or substitutes. Wireless sensor bars have also been released. The position and motion tracking of the Wii Remote allows the player to mimic actual game actions, such as swinging a sword or aiming a gun, instead of simply pressing buttons. An early marketing video showed actors miming actions such as fishing, cooking, drumming, conducting a string quartet, shooting a gun, sword fighting, and performing dental surgery. The LEDs can be seen through some cameras and other devices with a wider visible spectrum than the human eye, like most digital cameras and camera phones. The Wii Remote also has twelve buttons. It has a power button to toggle the Wii on and off, a d-pad which is interpreted as four separate buttons, and buttons labeled "A", "B", "1", "2", "home", "-", and "+".

Software Requirements Specification for Virtual Classroom

Page 11

Wiimote - Communication Protocol

Type Accelerometer Y Size 1 X3 Y4 Extensions Introduction: Nintendo have made the Wii console's communication protocol very efficient, the information is delivered down to the bit level and by that no space is left unused. The way it works is by setting the 1st byte of the message to be the message type and by that we can continue extracting data from the message according to the type we got. There are 8 types of messages : Status - a status report. ReadData - Read data from memory location. Buttons - button data only. ButtonsAccel - buttons and accelerometer data. IRAccel - IR sensor and accelerometer data. ButtonsExtension - buttons and extension controller data. ExtensionAccel - extension controller and accelerometer data. IRExtensionAccel - IR sensor, extension controller and accelerometer data. There are also the messages that are sent to the Wiimote but my focus is on the information and data you can extract from the remote. Buttons Accelerometer Z X2 Y3 Size 4 Buttons X1 Y2 Size 3 Extensions Accelerometer X Y1 Size 2 X4

Software Requirements Specification for Virtual Classroom

Page 12

Buttons: Gets the information about the buttons state from the 2 nd and 3rd bytes. Buttons + Accelerometer: Gets the former information and in addition gets the information about the accelerometer from bytes 4-6. IR + Accelerometer: Gets the former information and in addition gets the data of the IR camera from bytes 7-18. Buttons + Extension: Gets the data for the buttons and the data of the extension from bytes 5-10 depending on the extension type. Extension + Accelerometer: Gets the data for the buttons and the accelerometer from bytes 2-6 and the data for the extension from bytes 7-12 depending on the type. IR + Extension + Accelerometer: Gets the data for the buttons from bytes 2-3 and the data for the accelerometer from bytes 46 and the data for the IR from bytes 7-18 and the data for the extension from bytes 19-22. Status: Gets the data for the buttons, and battery from byte 7 and the IR recognized from byte 4. Read Data: Gets the data for the buttons and reads data from the 4 th byte.

Software Requirements Specification for Virtual Classroom

Page 13

Project Description:
The project consists of 2 main modules:

Wiimote.cs :
Represents the wii remote in the application, and manages the communication protocol with the device, this module holds the state of the device at any given moment. When a change occur in the state of the device the module fires up the "WiimoteChanged" event so the user could make the changes necessary according the change in state. The creation of the module should be made using the default constructor supplied, To initialize the module a call to the method "Connect" should be made, then a call to the method "SetReportType" sets the report type desired (one of the 8 supplied). The call to "GetStatus" gets the state of the device at that specific moment, the last thing that should be made is to enroll to the event "WiimoteChanged" and by that getting the state of the device each time it hanges. By calling the "Disconnect" method the module disconnects from the device and frees all resources.

WiiMouseControlModule.cs:
Represents the entity that controls the mouse by the glove (2 leds of IR), this module uses the module 'Wiimote.cs' in a way that it saves the last state of the device and selects the actions that are to be made according to the state change. It uses the IR recognition of the device to acquire 2 IR led lights and according to their positions it makes the proper calculations to get the right commands to the mouse and the OS. I've used the Singleton design pattern in this module so there will be only one instance of it, the whole idea is that this module will work as a standalone entity that will bridge between the device and the OS and will be in charge of controlling the mouse with the glove. Each IR led acquired by the device has an X value ranging 0 - 1023 and a Y value ranging 0 767. After normalizing them you get two values ranging 0.0 - 1.0 so when multiplied by the dimensions of the screen you get a point on screen. because the device is reverted (0,0 is the bottom right corner and 1,1 is the upper left) than an adjustment is needed. The module uses Win32 procedures to put commands in the mouse's Queue in the OS, it mainly uses the 'SendInput' procedure which takes an array of INPUT structures and its size. every INPUT structure has a type (mouse, keyboard, hardware) and according to the type it holds the information in MI - Mouse Input, KI - Keyboard Input, HI - Hardware Input. The module uses the mouse input which is a structure of MOUSEINPUT which looks like so: DX - a value from 0 - 65535 that determines the absolute or relative X value. DY - a value from 0 - 65535 that determines the absolute or relative Y value. MouseData - usually stays empty. DWFlags - determines what kind of input is in the structure (move, left Down, left Up, absolute

Software Requirements Specification for Virtual Classroom

Page 14

position, relative position). Time - a timestamp for the command sent. DWExtraInfo - some extra info, usually stays empty. Every change in the state of the device, this module gets the information about the IR led lights that it acquired, first if it has been acquired and second it's X and Y values. if the module acquired 2 IRs than it calculates the average between the two points and the distance between them, if the distance is larger than a specific constant value than it makes the mouse move there, if not it makes the mouse do a left button down action (according to the last state of the device). This module has the infrastructure to support 4 led lights for a future ability to work in a multi touch environment, using 2 gloves will let the user make 2 clicks at the same time and enable multi dragging and zooming in and out like a multi touch surface can.

Software Requirements Specification for Virtual Classroom

Page 15

Screen Shots
This is a screen shot of the application: