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

The appendixes are at the end.

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.

If a user want to have a conference with others, he has to launch the Application Client. The server will remain available on a special machine.
Data are sent from the clients who own, each one, an Intel Creative Camera. Those data are sent to the server which will send them back to other client connected.

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

This is the client-server application as simple as we can :

One server needs to be launched, but as many client can be launched.

2.2 Product functions

The main functions of our application are can be divided in 2 different parts :

• Recognition and translation :
  

Our software will be able to detect and recognize gestures from the user. It will have a lot of data about sign language in a special dictionnary. If the movement is not recognized, it will just do nothing. If the gesture is recognized, the translation will be written and spoken. Another feature will be to add in the dictionnary signs that the software doesn't recognize.

• Network :
  

The goal is to connect people all around the world with the same application. There will be two different applications, one launch on the server to process data and send it back. The other is the client application which will contain recognition and translation functions.

2.3 User characteristics

There will be 3 different type of users :

• "Normal" user : a user that can use the application as another video/audio communication application.
• Sign language speaker user : a user who will speak thanks to his hand. Movement dectection and recognition is especially done for this user.
• Blind user : the function which will do the speech translation is well-adapted for this kind of user.

2.4 General constraints

The main constraint of our application is, if you want a sign language recognition, to have an Intel Creative Camera.
The user also need to have a good internet connection.
The size of the dictionnary may be a constraint if too many words are added to it.

2.5 Assumptions and dependencies

In that way, we will assume that users have a good internet connection and have, of course, the Intel Creative camera.

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:

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