Proj-2013-2014-Sign2Speech-SRS

=1.  Introduction=

1.1 Purpose of the requirements document
This Software Requirements Specification (SRS) identifies the requirements for our software "Sign 2 Speech". The goal of this document is to illustrate and explain the development of our software. Moreover, it will give a detailed description of system constraints and interactions with users.

1.2 Scope of the product
"Sign 2 Speech" is a software designed especially for people who are mute but all other users can use it. The main function is to allow the user to use sign language in front of its Intel Creative camera and then the application is recognizing the gesture. Each movement recognized is translate and send to the other user(s) thanks to internet, so our application is to be developped on the network. Secondly, for people who are blind or partially-sighted, once they received the translation of the movement, the text is also read. Then we want to allow more than two users to speak together. Our last purpose is to allow the self-learning on our application of new signs. To run the software, the user will need Internet and a Intel Creative Camera.

1.3 Definitions, acronyms and abbreviations

 * SDK : A software development kit (SDK or "devkit") is typically a set of software development tools that allows for the creation of applications for a certain software package, software framework.
 * Overlay : An Overlay on the SDK is a block of code that we rewrote because the initially SDK was not enough or complete.
 * Software : A computer program / application.
 * Hardware : An electronical component refering to something link to the computer.
 * XML : Extensible Markup Language (XML) which is a programming language with markers.

1.4 References
[1] http://software.intel.com/en-us/articles/intel-perceptual-computing-sdk-tutorials [2] http://en.cppreference.com/w/

1.5 Overview of the remainder of the document
This document includes three main chapters : The appendixes are at the end.
 * The first describe the working of our software and explain most of the development.
 * The second one is about specific requirements, covering functional, non-functional and interface requirements.
 * The third one is about the evelution of our product.

=2.  General description= This part will describe in general our software and how we made it. We will see also the interaction with users and the dependencies.

2.1 Product perspective
Our software is divided in two main different parts. The first one is about the gesture recognition, the oral and textual translation. These functions will be called on client side. The second part is the server side, which will redirect data to every clients connected.



This is the client part. It is shown only functions which don't have link with the network.



2.5 Assumptions and dependencies
=3.Specific requirements, covering functional, non-functional and interface requirements=
 * document external interfaces,
 * describe system functionality and performance
 * specify logical database requirements,
 * design constraints,
 * emergent system properties and quality characteristics.

a. Hand movements recognition
Description: The application must recognize hand movements of the speechless user using the computer´s inputs.

Inputs: Stream data

Source: Leap motion and creative camera sensors

Outputs: Data base index corresponding to the recognized gesture

Destination: Local machine

Action: The user must placed himself in front of the camera or above the leap motion. He communicate with the computer with hand movements. The movements are recognized by the sensors and the data is transmitted to the program. The program processed it, makes the calculation and determines which sign language movement it is.

Non functional requirements: The recongnition process should be done in real time. (3 seconds maximum)

Pre-condition: Using the Creative Camera, ambient light should be enough to see correctly user´s movements. Using the leap motion, hands should be above the sensor. The recognized gesture is present in the data base.

Post-condition: The user hand movement has been well recognized.

Side-effects: Bad gesture recognition

b. Literal translation
Description: The application must show on the screen the word or the idea that refers to the user movement detected.

Inputs: Processed data (by our program) and sign language gesture data base.

Source: Hard drive of the local machine

Outputs: String

Destination: The screen

Action: The program searches into the data base the literal translation corresponding to the recognized gesture.

Non functional requirements: /

Pre-condition: The literal translation of the recognized gesture is present in the data base.

Post-condition: The literal translation is correctly shown on the screen.

Side-effects:

c. Vocal synthesis
Description: The application must say the literal translation of the user´s gesture found previously.

Inputs: Data base index

Source: Local machine

Outputs: Sound

Destination: Speakers

Action: The program searches into the data base the sound corresponding to the recognized gesture.

Non functional requirements: /

Pre-condition: The computer must have speakers. The sound of the recognized gesture is present in the data base.

Post-condition: The sound is correctly played on the screen.

Side-effects:

d. Self-learning
Description: Learn a new sign language gesture

Inputs: Stream data

Source: Local machine

Outputs: New data base index

Destination: Local machine

Action: If the gesture is not recognized, the program should propose to the user to enter the corresponding literal translation. Then, the application add a new entry in the data base.

Non functional requirements: The recongnition process should be done "quickly". (3 seconds maximum)

Pre-condition:

Post-condition: A new entry corresponding to the unknown gesture is added in the data base

Side-effects:

=4. Product evolution=

=5. Appendices=

5.1. SRS structure
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.

References:
 * http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
 * http://en.wikipedia.org/wiki/Software_requirements_specification
 * IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998

=6. Index= References:
 * For all of our UML diagram, we used Visual Paradigm Community Edition