US 5 En tant qu'utilisateur porteur des bracelets, j'aimerais que mes bracelets détectent des sons particuliers préalablement enregistrés et m'en informe. #7
En tant qu'utilisateur porteur des bracelets, j'aimerais que mes bracelets détectent des sons particuliers préalablement enregistrés et m'en informe.
Description, intérêts et objectifs
Dans le cas où un son dont l'utilisateur aimerait être informé provenant de son "angle mort" de vision, le bracelet se trouvant le plus proche pourra ainsi le prévenir afin d'attirer son attention. L'utilisateur sera prévenu via une combinaison de vibration différente de celle l'avertissant d'un son fort (voir US 1.2). L'utilité ne se limite pas au prénom, surnom, cela peut être un poste au boulot ("serveur/serveuse" pour barman, "patron/patronne" dans une entreprise,...) et plein d'autres utilisations dont l'utilisateur aimerait être informé selon ses préférences et les contextes auxquels il fait face.
Une remarque a été faites par notre client nous attirant sur le fait que la plupart des personnes connaissant des malentendants et étant au courant de leur handicap n'appelle tout simplement pas la personne mais plutôt vont vers elle et priorise un contact physique. C'est pour cette raison que nous avons ouvert l'utilisation de cette fonctionnalité à plus de mots. Cependant il ne faut pas oublier que l'objectif de notre projet est d'offrir un moyen d'alternative à l'ouïe et que il faut en tirer profit. Les personnes connaissant l'existence de ses bracelets auront ainsi un outil en plus d'interaction. Il ne faut pas oublier que la surdité n'est pas un handicap "remarquable" aux premiers abords et que les personnes n'étant pas au courant mais souhaitant interagir avec l'utilisateur auront comme premier réflexe d'appeler oralement la personne. C'est ce dernier argument qui nous a poussé à ouvrir notre fonctionnalité plus loin que le simple prénom.
Critères d'acceptation
Validations
dans le cas où un mot enregistré est prononcé sur la droite. le bracelet de droite vibre selon la combinaison attribuée à cette fonctionnalité. Pareil pour le bracelet gauche si le mot viens de gauche.
le bracelet ne vibre pas si un mot n'étant pas enregistré est prononcé.
si un mot enregistré est prononcé à gauche, seul un des 2 bracelets vibre et ce sera celui de gauche. pareil si c est à droite.
Scénarios
Dans le cas où un mot enregistré est prononcé au delà du seuil activant la US 1.2, la priorité sera donnée à cette dernière et seule celle la s'activera.
dans le cas où le mot enregistré est prononcé à équidistance des 2 bracelets, 1 seul des 2 vibrera arbitrairement.
Apparence/Layout
Emplacement/parties sur lesquelles on travaille
Une partie se fera physiquement avec le branchement des micros ainsi que des vibreurs. Une autre sera de développer le code C du microprocesseur gérant le transfert des données et la réception des instructions. La dernière sera de développer le traitement des signaux reçu du coté de l'app sur le Gsm qui sera également en lien avec la DB SQLite.
Maquettes
Dépendances techniques
( prérequis, utilisation de DB, API?, utilisation de librairies, ...)
Cette fonctionnalité dépend du bon fonctionnement de la connexion Bluetooth entre l'application et les bracelets. Elle dépend également de tout le coté hardware qui doit être finalisé et fonctionnel.
Découpage en taches
traduction des données en données utilisable pour un traitement de signal
comparaison des signaux avec les enregistrements de la base de donnée
ThomasDeceuninck
commented
2 years ago
En tant qu'utilisateur porteur des bracelets, j'aimerais que mes bracelets détectent des sons particuliers préalablement enregistrés et m'en informe.
Description, intérêts et objectifs
Dans le cas où un son dont l'utilisateur aimerait être informé provenant de son "angle mort" de vision, le bracelet se trouvant le plus proche pourra ainsi le prévenir afin d'attirer son attention. L'utilisateur sera prévenu via une combinaison de vibration différente de celle l'avertissant d'un son fort (voir US 1.2). L'utilité ne se limite pas au prénom, surnom, cela peut être un poste au boulot ("serveur/serveuse" pour barman, "patron/patronne" dans une entreprise,...) et plein d'autres utilisations dont l'utilisateur aimerait être informé selon ses préférences et les contextes auxquels il fait face.
Une remarque a été faites par notre client nous attirant sur le fait que la plupart des personnes connaissant des malentendants et étant au courant de leur handicap n'appelle tout simplement pas la personne mais plutôt vont vers elle et priorise un contact physique. C'est pour cette raison que nous avons ouvert l'utilisation de cette fonctionnalité à plus de mots. Cependant il ne faut pas oublier que l'objectif de notre projet est d'offrir un moyen d'alternative à l'ouïe et que il faut en tirer profit. Les personnes connaissant l'existence de ses bracelets auront ainsi un outil en plus d'interaction. Il ne faut pas oublier que la surdité n'est pas un handicap "remarquable" aux premiers abords et que les personnes n'étant pas au courant mais souhaitant interagir avec l'utilisateur auront comme premier réflexe d'appeler oralement la personne. C'est ce dernier argument qui nous a poussé à ouvrir notre fonctionnalité plus loin que le simple prénom.
Critères d'acceptation
Validations
dans le cas où un mot enregistré est prononcé sur la droite. le bracelet de droite vibre selon la combinaison attribuée à cette fonctionnalité. Pareil pour le bracelet gauche si le mot viens de gauche.
le bracelet ne vibre pas si un mot n'étant pas enregistré est prononcé.
si un mot enregistré est prononcé à gauche, seul un des 2 bracelets vibre et ce sera celui de gauche. pareil si c est à droite.
Scénarios
Dans le cas où un mot enregistré est prononcé au delà du seuil activant la US 1.2, la priorité sera donnée à cette dernière et seule celle la s'activera.
dans le cas où le mot enregistré est prononcé à équidistance des 2 bracelets, 1 seul des 2 vibrera arbitrairement.
Apparence/Layout
Emplacement/parties sur lesquelles on travaille
Une partie se fera physiquement avec le branchement des micros ainsi que des vibreurs. Une autre sera de développer le code C du microprocesseur gérant le transfert des données et la réception des instructions. La dernière sera de développer le traitement des signaux reçu du coté de l'app sur le Gsm qui sera également en lien avec la DB SQLite.
Maquettes
Dépendances techniques
( prérequis, utilisation de DB, API?, utilisation de librairies, ...)
Cette fonctionnalité dépend du bon fonctionnement de la connexion Bluetooth entre l'application et les bracelets. Elle dépend également de tout le coté hardware qui doit être finalisé et fonctionnel.
Découpage en taches