Speech To Text Conversion

SRS

Project By:-
Krishna Rathi 31447
Sanket Patil 31440
Prasad Ramphale 31446
Table of Contents-
1. Introduction
1.1 Purpose
1.2 Scope
1.3 References
1.4 Overview
2.
3. Specific Requirements
3.1 EXTERNAL INTERFACES
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.2 FUNCTIONS
3.2.1 Room Id
3.3 Performance Requirements
3.4 Logical Database Requirements
1.Introduction
1.1 Purpose
• To understand the speech recognition and its fundamentals.
• Its working and application in different areas.
• Development for software that can mainly used for:
• Speech Recognition.
• Speech Generation.
• Tool for operating machine through voice.

1.2 Scope
This project has the speech recognizing capabilities though it is not a
complete replacement of what we call Notepad but still a good text editor to be used
through voice.
1.3 References
[1]”Speech Recognition-The Next Revolution” 5th Edition.
[2] “Fundamentals of Speech Recognition”. L .Rabiner & B.Jaung.
1993
1.4 Overview
The rest of the SRS contains a product overview. The interfaces
required and implementation part, the security and the features of the app. The constraints
and requirements are also mentioned so to keep a check on the performance of the app.
3. Specification Requirements
3.1 External Interfaces
3.1.1 User Interfaces
The Speech To Text user interface should be
intuitive, such that minimum 20 of Speech to Text users are able to use
app without any assist.
3.1.2 Hardware Interfaces
The hardware should have following specifications:
• Touch screen for convenience
• Keypad (in case touchpad not available)
• Continuous power supply
• Ability to connect to network via LAN
• Ability to take input from user

3.2 Functions
3.2.1 Room Id
In order to join the system the user will be given a Room
Id through which it can be connected to server. After that, the request
will be sent to the server to accept the user. If the server accepts the
user then only he/she can join the system otherwise not.

3.3 Performance Requirements

Where will be able to support at most 150
simultaneous users at a time. The capacity can be extended in future if
needed. There will be large amount of information to be handled in
database such as messages, profile information, etc. And the server will
be enough space to handle this occupation.

3.4 Logical Database Requirements

In the database, integer, varchar and date type of information will be
stored.

3.6 Software System Attributes

 There are a number of attributes of software that can serve as
requirements. The following attributes specified below allow the achievement
to be fulfilled.

3.6.1 Reliability
1. The Chat application should not fail under circumstances such as
increase in users of the application.
2. It should not leak the user data to data companies.
3.6.2 Availability
1. The application should be able to learn on any platform.
2. There should be no version conflict between various mobile API.
3.6.3 Security
The mobility domain has a privacy sensitive nature, specifically with
regards to the location tracking of travelers.
In order to create a viable offering for the user we will have to build a
simple, transparent system that can be understood and trusted by the
people that are using it.
In order to build trust with the users of our system, the system can make
use of the following strategies:
• Encryption, for all data that is privacy sensitive, but must be persisted
on the server in order for basic functionality.
• Open source / disclose security policies & practices.
• Do not permit the use of unverified (anonymous) avatars / aliases.
• Give control to end-users over private data (at least a delete private
repository option)
3.6.4 Maintainability
1. The application should be easy to maintain even after the increase of
users.
2. The complexity of database should be less for ease of maintainability.
3.6.5 Portability
1. The user should not be able to transfer the application from one user
device to another.
2. However, provisions to use the application should be made.
3.7 Organizing the Specific Requirements
 For anything but trivial systems the detailed requirements tend to be extensive.
For this reason, it is recommended that careful consideration be given to organizing
these in a manner optimal for understanding.
3.7.1 System Mode
The application will work on API 15 and above.
3.7.2 User Class
1. The user can change settings as per requirements.
3.7.3 Objects
1. User
2. Admin
3.7.4 Features
1. Customizable Design
2. Application for mobile devices.
3. Version for online browsers.
4. The possibility of dealing with several clients at once.
5. Client's history.
6. Analytical tools.
7. Conversion backup
3.8 Additional Comments.
• Multi-lingual Support

• The system should be language agnostic, since portability is a prime

goal of the overall project.
• English, Hindi, and Marathi should be at least being supported
because these are the replication partners.