Difference between revisions of "Projets-2015-2016-Borne-Interactive-SRS"

From air
Jump to navigation Jump to search
Line 24: Line 24:
 
==1.1 Purpose of the requirements document==
 
==1.1 Purpose of the requirements document==
 
This Software Requirements Specification (SRS) identifies the requirements for project "Borne Interactive". In case of a open source project, we must present the requirement to others potential contributors. This document is a guideline about the functionalities offered and the problems that the system solves.
 
This Software Requirements Specification (SRS) identifies the requirements for project "Borne Interactive". In case of a open source project, we must present the requirement to others potential contributors. This document is a guideline about the functionalities offered and the problems that the system solves.
  +
 
==1.2 Scope of the product==
 
==1.2 Scope of the product==
  +
Intended for any organization wishing to facilitate the reception of hearing impaired people.
Toutes structures voulant proposer un système pour les personnes malentendantes.
 
   
 
==1.3 Definitions, acronyms and abbreviations==
 
==1.3 Definitions, acronyms and abbreviations==
  +
"Borne Interactive" : Interactive display on two screens or two interfaces : one for the speaker and one for the listener.
   
 
==1.4 References==
 
==1.4 References==
  +
Google speech API :
  +
https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html
   
 
==1.5 Overview of the remainder of the document==
 
==1.5 Overview of the remainder of the document==
  +
General desccription of the project followed by all its requirements and the product evolution.
 
   
   
 
=2. General description=
 
=2. General description=
The aim of this project is to design a new interactive system for help impaired hearing people, by writing what the receptionnist is saying.
+
The aim of this project is to design a new interactive system to help impaired hearing people, by writing what the receptionnist is saying.
   
 
==2.1 Product perspective==
 
==2.1 Product perspective==
When deaf(or Impaired hearing) people come at a recpetion stand, to, for example, request informations, they can have difficulties communicating with the receptionist. Our product make a live transcription of the receptionist speech and write it down on a screen to help the people understand the receptionist in a possible noisy environnment where it's hard to communicate. Since voice recognition make mistakes and don't recognise technical terms, our product also offer a mean of correction for the receptionist.
+
When deaf(or impaired hearing) people come at a reception stand, to request informations for example, they can have difficulties to understand the receptionist. Our product intends to make a live transcription of the receptionist speech and write it down on a screen. The person understands the receptionist in a better way, especially in a noisy environnment where it's hard to communicate. Since voice recognition make mistakes and doesn't recognise technical terms, our product also a mean of correction for the receptionist.
   
 
==2.2 Product functions==
 
==2.2 Product functions==
 
Live transcription of the receptionist voice.
 
Live transcription of the receptionist voice.
Possibility to correct the transcription (for mistakes or technical terms)
+
Possibility to correct the transcription (for mistakes or technical terms).
   
 
==2.3 User characteristics==
 
==2.3 User characteristics==
Two types of users, the receptionist and the deaf (or impaired) person.
+
Two types of users, the receptionist and the deaf (or impaired hearing) person.
The receptionist can correct the live transcription.
+
The receptionist can correct the live transcription via his interface.
The impaire person read the live transcription in a easy way.
+
The impaired hearing person read the live transcription in an easy way.
   
 
==2.4 General constraints==
 
==2.4 General constraints==
Only made by using Web technologies suach as HTML/PHP/JavaScript to make it run on almost every devices.
+
Only made by using Web technologies such as HTML/PHP/JavaScript to make it run on almost every device.
Should use the Google Speech Recognition API.
+
Must use the Google Speech Recognition.
   
 
==2.5 Assumptions and dependencies==
 
==2.5 Assumptions and dependencies==

Revision as of 15:58, 19 January 2016

Document History
Version Date Authors Description Validator Validation Date
0.1.0 January 18, 2016 Quentin DUNAND - Elsa NAVARRO - Antoine REVEL Creation of the document TBC TBC


1. Introduction

1.1 Purpose of the requirements document

This Software Requirements Specification (SRS) identifies the requirements for project "Borne Interactive". In case of a open source project, we must present the requirement to others potential contributors. This document is a guideline about the functionalities offered and the problems that the system solves.

1.2 Scope of the product

Intended for any organization wishing to facilitate the reception of hearing impaired people.

1.3 Definitions, acronyms and abbreviations

"Borne Interactive" : Interactive display on two screens or two interfaces : one for the speaker and one for the listener.

1.4 References

Google speech API : https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html

1.5 Overview of the remainder of the document

General desccription of the project followed by all its requirements and the product evolution.


2. General description

The aim of this project is to design a new interactive system to help impaired hearing people, by writing what the receptionnist is saying.

2.1 Product perspective

When deaf(or impaired hearing) people come at a reception stand, to request informations for example, they can have difficulties to understand the receptionist. Our product intends to make a live transcription of the receptionist speech and write it down on a screen. The person understands the receptionist in a better way, especially in a noisy environnment where it's hard to communicate. Since voice recognition make mistakes and doesn't recognise technical terms, our product also a mean of correction for the receptionist.

2.2 Product functions

Live transcription of the receptionist voice. Possibility to correct the transcription (for mistakes or technical terms).

2.3 User characteristics

Two types of users, the receptionist and the deaf (or impaired hearing) person. The receptionist can correct the live transcription via his interface. The impaired hearing person read the live transcription in an easy way.

2.4 General constraints

Only made by using Web technologies such as HTML/PHP/JavaScript to make it run on almost every device. Must use the Google Speech Recognition.

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.

3.1 Requirement X.Y.Z (in Structured Natural Language)

Function:Live transcription

Description: When the receptionist speak a live transcription can be seen by both users.

Inputs: Voice command or button press to start the transcription.

Source: Mouse or microphone.

Outputs: Screen (Touchscreen?)

Destination: This device is designed to used in a reception environment susceptible of welcoming deaf (or impaired) people.(University, Post office...)

Action:

  • Natural language sentences (with MUST, MAY, SHALL)
  • Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
  • Mathematical Notations
  • Tabular notations for several (condition --> action) tuples

Non functional requirements:

Pre-condition:

Post-condition:

Side-effects:


4. Product evolution

5. Appendices

6. Index