Contents

CONTENTS ................................................................................................................................................................. I

1 INTRODUCTION ..............................................................................................................................................1
1.1 SYSTEM INTRODUCTION ..............................................................................................................................1
1.2 BACKGROUND OF THE SYSTEM ...................................................................................................................1
1.3 OBJECTIVES OF THE SYSTEM .......................................................................................................................1
1.4 SIGNIFICANCE OF THE SYSTEM ....................................................................................................................2
2 OVERALL DESCRIPTION .............................................................................................................................2
2.1 PRODUCT PERSPECTIVE ...............................................................................................................................2
2.2 PRODUCT SCOPE..........................................................................................................................................5
2.3 PRODUCT FUNCTIONALITY ..........................................................................................................................5
2.4 USERS AND CHARACTERISTICS....................................................................................................................5
2.5 OPERATING ENVIRONMENT .........................................................................................................................5
3 SPECIFIC REQUIREMENTS .........................................................................................................................6
3.1 FUNCTIONAL REQUIREMENTS .....................................................................................................................6
3.2 BEHAVIOUR REQUIREMENTS .......................................................................................................................6
3.3 EXTERNAL INTERFACE REQUIREMENTS ......................................................................................................7
4 OTHER NON-FUNCTIONAL REQUIREMENTS ........................................................................................8
4.1 PERFORMANCE REQUIREMENTS ..................................................................................................................8
4.2 SAFETY AND SECURITY REQUIREMENTS .....................................................................................................9
4.3 SOFTWARE QUALITY ATTRIBUTES ..............................................................................................................9
5 DESIGN DESCRIPTION ................................................................................................................................ 10
5.1 COMPOSITE VIEWPOINT ............................................................................................................................ 10
5.2 LOGICAL VIEWPOINT ................................................................................................................................ 11
5.3 INFORMATION VIEWPOINT ........................................................................................................................ 12
5.4 INTERACTION VIEWPOINT ......................................................................................................................... 13
5.5 STATE DYNAMICS VIEWPOINT .................................................................................................................. 16
5.6 ALGORITHM VIEWPOINT ........................................................................................................................... 17
Software Requirements Specification & Design Description for <Project> Page 1

1 Introduction

1.1 System Introduction

The purpose of this part is to describe the project titled “Anyone Can Talk”. This part contains the
functional and non-functional requirements of the project. It contains the guidelines for developers
and examiners of the project. The purpose of this project is to enable the deaf and dumb to
communicate with normal people without any communication barriers. So we propose a device
which can convert their hand gestures into voice which a normal person can understand.

1.2 Background of the System

There were a few projects that were based on the idea of ACT following is a detailed
description of projects previously carried out in this context.
• Audio to audio translation from one language to another language for android and PC.
• Audio to text translation for android and PC.
• Text to text translation from one language to another for android and PC.
• Text to audio translation for android and PC.
Image Processing Solution :
Here the images of hand gestures are gone through following steps:
• Gray Scaling of image.
• Logical transformation of image.
• Edge Detection.
Hidden Markov Models:
• Markov models were used in image processing to give real time sign language
recognition.
• It uses AI to guess the next gesture depending upon the previous gesture Hence it
provides a faster solution to sign language recognition.
Conclusion:
Image Processing restricts the movements in front of the camera, any gesture outside the
frame didn’t count.Other existing solutions only provides translation of sign language into
audio, they didn’t translate audio into sign language. So, we proposed a solution, where a deaf
person can also know what a healthy person is saying, by translating audio into Sign
LanguageAppearance changes could for instance also deal with the sharpness of objects of
interest, thus allowing the user to make apparent changes of focus.

1.3 Objectives of the System

Main objective of this system are:
• This system will be useful for dumb and deaf people to communicate with blind and
normal people
• This system will convert the sign language into voice and text which is easily
understandable by blind and normal people
• The sign language is translated into some text form, to facilitate the deaf people as
well
Software Requirements Specification & Design Description for <Project> Page 2
• This system will work for both platforms i.e. PCs and Android to make it portable for
people This text will be displayed on LCD on PC and on mobile screens while using
android app
• we can accommodate a number of other gestures as well for better and efficient
communication

1.4 Significance of the System

Sign language is a natural way for communication between normal and the deaf and dumb people,
but often they find difficulty in communicating with normal people as they don’t understand their
sign language. Therefore, there always exists a language barrier. To overcome this barrier, we
propose a device which can convert their hand gestures into voice which a normal person can
understand. It will also help out the deaf and dumb people to understand what a normal person is
saying by watching their sign language on a screen. This device consists of a Wireless Glove,
consisting of flex sensors and accelerometer. These sensors sense the movement of hands and
fingers. This system consists of a two way speech synthesizer software which converts these
movements of hand into real time speech output and a display will give the text for the
corresponding gesture. While on the other hand it will convert the speech of the healthy person into
sign language so that the patient can understand.

2 Overall Description

2.1 Product Perspective

This product would enable the deaf and dumb to communicate with normal people without any
communication barriers by converting their hand gestures into voice which a normal person can
understand.
Software Requirements Specification & Design Description for <Project> Page 3

System Diagram:

Figure1: hand gesture to speech

Software Requirements Specification & Design Description for <Project> Page 4

Figure2: speech to hand gesture

Software Requirements Specification & Design Description for <Project> Page 5

2.2 Product Scope

The document only covers the requirement specifications for ACT. This application will be used by deaf and dumb
people to communicate with healthy people in a normal fashion. The device will recognize and generate all the English
alphabets and basic words
For Final year project and CUI WAH Computer Science department
What To provide a device for converting sign language into speech and speech back
into sign language , along with the following features:
• Sensory gloves
• Android App
• Desktop app
The Sensory gloves
Is A wireless glove
That Provides:
• Conversion of motion signals to electric signals

2.3 Product Functionality

The main features of the application are:
• The Sensory glove is connected with the application with the help of Bluetooth.
• Database of some words is maintained at back end of the application.
• When any particular hand gestures are made signals are generated with the help of sensors
mounted on gloves.
• These particulars signals are sent to application for processing with the help of Bluetooth
connectivity.
• These received signals or values of any particular gesture are now analyzed with pre existing
words in database.
• After finding its match with any word of database, it is converted into speech and easily
hearable to healthy or normal persons.

2.4 Users and Characteristics

Following are the user classes and their brief description.
Summary Of User Classes:
The following section describes the types of users of the Speech Synthesizer Software
Application.
Deaf And Dumb User:
The Deaf and Dumb User is the one who actually wants to communicate with the healthy or
normal person with the help of hand glove mounted on his hand and this speech synthesizer
software application.
Normal Person User:
The Normal or Healthy Person User is the one who would communicate with the deaf and
dumb person without any communication barrier with this application.

2.5 Operating Environment

Hardware
Software Requirements Specification & Design Description for <Project> Page 6
The Speech Synthesizer Application operates with the following hardware:
• SENSORY GLOVE: A sensory glove is wore by a deaf and dumb person and all types of sensors
(Flex Sensors and Accelerometer) are mounted on this glove.
• FLEX SENSORS: There are 13 flex sensors used on gloves. All types of hands and fingers bending
and rotations are detected by these sensors and signal is sent to application with Bluetooth signals
and corresponding speech is generated.
• ACCELEROMETER: Accelerometer sensor is mounted on glove which is used to detect the
movements of hands. Any particular movement of hand is recorded and signal is sent to application
with Bluetooth signals and further processing and conversion to speech is done.
Software
• Windows: 7, 8, 8.1, 10.
• IDE: Netbeans And Eclipse.
• Programming language: JAVA and Android.

3 Specific Requirements

Functional Requirements

3.1 Behaviour Requirements

Use case diagram:

Actors:
Primary Actors:
Software Requirements Specification & Design Description for <Project> Page 7
• DAD (Deaf & dumb User)
• Healthy User
Secondary Actors:
• None
Use Cases:
• Perform Actions
• See image representations of the actions
• Convert text or audio to actions
• See healthy persons audio or text as sign language images
• Convert actions to audio or text

3.2 External Interface Requirements

3.2.1 User Interfaces

1. Sign to Speech module:

• The sign to speech module of desktop and android application consists of an interface which
represent the data received from the sensory gloves into a text area which contains a button
to start the speech to sign module.
2. Speech to Sign module:
• In speech to sign module of the desktop and android application we will display both the
text and gestures symbols on the screen as the healthy person speaks.

3.2.2 Hardware Interfaces

• Main hardware interface is the sensory glove which wirelessly communicate to the
application.
• Speech data is collected through a mic and later sent to the speech to text API for further
processing.

3.2.3 Software Interfaces

• To record audio data from the mic by the healthy person into the software.
• To send the audio to the server using a speech to text API to convert the spoken
words into the written text.
• To convert the written text into gestures using a defined database containing words.
• To display these words along with gestures onto a screen.
• To get the signals from the gloves using Arduino with sensors by the deaf and dumb
person.
Software Requirements Specification & Design Description for <Project> Page 8
• To convert these sign signals into words.
• To convert these words into audio data using a text to speech API.

3.2.4 Communications Interfaces

For communication between sensory gloves and android or desktop application we have to use
Arduino Lily pad along with Bluetooth connection between application and gloves.

4 Other Non-functional Requirements

4.1 Performance Requirements

The application is a fast program and will perform communication of data in minimum
possible time
• If the process crash then it will recover in a very small amount of time.
• The quality of the data being transferred will be retained as much as possible.
• The bandwidth of the medium will be utilized in an efficient way in a minimum
possible time.
• The application involves a statistical report of data communicating making it easier
to monitor the system performance requirements.
Software Requirements Specification & Design Description for <Project> Page 9

4.2 Safety and Security Requirements

Safety Requirements:
• The gloves will be thoroughly sealed to prevent the user from experiencing any
electrical shocks.
• Prevent using gloves under extreme weather conditions.
• This application is a fast and responsive program but however if large amount of
data is being sent then there are chances that the application crashes but backup will
be there.
Security Requirements:
• The data sent to the text to speech and speech to text api will be end to end encrypted
and will not be stored on any external server.
• The application .exe file will run as administration requiring a username of
administration and his/her password.
• It will be ensured that the data thus communicated will be protected against spoofing
and sniffing.
• The ip addresses of the mobiles and desktop pcs using the API should not be shared
with unauthorized individuals.
• The android app will access microphone, Bluetooth and other phone utilities through
user’s permission.

4.3 Software Quality Attributes

Reliability Requirements:
• This application is a fast and responsive program but however if large amount of data is being
sent then there are chances that the application crashes but backup will be there.
• If the process crash then it will recover in a very small amount of time.
Supportability Requirements:
• The desktop and android applications will constantly be updated to new versions after a
continuous cycle of receiving feedback from the customers.
• The database of words and gestures will constantly be updated.
Availability Requirements:
• The application can be run anytime on desktop and on pc , however it requires internet
connection for the speech to text and text to speech module to work.
• The database for word and gestures will be available for 24/7 as it will be stored on the device
itself.

Maintainability Requirements:
• The application will be updated and new features will be added to it as the time passes.
Software Requirements Specification & Design Description for <Project> Page 10

5 Design Description

5.1 Composite Viewpoint

Software Requirements Specification & Design Description for <Project> Page 11

5.2 Logical Viewpoint

The State Transition diagram is shown in the figure below:
Software Requirements Specification & Design Description for <Project> Page 12

5.3 Information Viewpoint

The diagram(s) show the higher level description of the application(s), generic working of the
application(s) and interaction with the user. User interacts with the Application using I/O devices
such as Sensory Gloves and Microphone. Our Application then read the user inputs and provide
output in the form of Gestures and Audio.
Software Requirements Specification & Design Description for <Project> Page 13

5.4 Interaction Viewpoint

Sequence Diagrams:
The sequence diagram(s) of Anyone Can Talk is given below:
Sequence Diagram for Healthy User:
Software Requirements Specification & Design Description for <Project> Page 14

Continued Sequence Diagram for the Healthy User..

Software Requirements Specification & Design Description for <Project> Page 15

Fugure: Sequence diag for healthy user

Sequence Diagram for Deaf & Dumb User:

Software Requirements Specification & Design Description for <Project> Page 16

5.5 State Dynamics Viewpoint

Software Requirements Specification & Design Description for <Project> Page 17
The user interface of anyone can talk is as follows:

5.6 Algorithm Viewpoint

ACT is an interactive application which requires multiple types of user interface. Developing
such systems require thorough consideration on the design factors as it might result in
complexity problem. A poorly-designed system results in a system consuming more resources
with very little efficiency and a slower response time which directly affects the experience of
the target user besides this, poor designs make testing and maintenance activities difficult.
MVC pattern will be used for the implementation of this application. General behavior of
MVC is shown below.
Software Requirements Specification & Design Description for <Project> Page 18

Pseudo Code for Components:

Healthy User:
Begin
OpenApplication ()
GetMicrophone ()
Speak
GetAudioBack ()
CloseApplication ()
End

Deaf and Dumb User :

Software Requirements Specification & Design Description for <Project> Page 19

Begin
OpenApplication ()
GetSensoryGloves ()
Perform sign language
GetSignLanguageBack ()
CloseApplication ()
End

Microphone:

Begin
TurnOnMic ()
SetupMic ()
PairCheck ()
MicCheck ()
SendAudio ()
TurnOffMic ()
End

Sensory Gloves:
Begin
SetupSensoryGloves ()
CheckFlexSensors ()
CheckAccelerometer ()
CheckBluetooth ()
PairBluetooth ()
SendSensorData ()
UnpairBluetooth ()
End

Application:
Begin
If User is “Healthy User”:
ConvertAudioToText ()
ConvertTextToSignLanguage ()
DisplaySignLanguage ()
If User is “Deaf & Dumb User”:
ConvertSignLanguageToText ()
ConvertTextToAudio ()
GenerateAudio ()
End
Software Requirements Specification & Design Description for <Project> Page 20
AudioToText:
Begin
Import IBM service
GetAudio ()
ConvertAudioToText ()
End

TextToSigns:
Begin
Send text to sign language database
Get sign language from its database
End

SignsToText:
Begin
Send sign language to its database
Get text from sign language database
End

TextToAudio:
Begin
Import IBM service
GetText ()
ConvertTextToAudio ()
End

SignsDatabaseHandler:

Begin
Open Sign language database
If IncomingData = “SignLanguage”
GenerateText ()
SendText () to signToTextConverter
If IncomingData = “Textual Data”
GenerateSignLanguage ()
SendSignLanguage () to textToSignLanguageConverter