Difference between revisions of "Proj-2014-2015-SeriousGamev2/SRS"

From air
Jump to navigation Jump to search
 
Line 21: Line 21:
 
| 0.1.0
 
| 0.1.0
 
| TBC
 
| TBC
  +
| Aissanou, Codazzi, Guo
| TBC
 
 
| TBC
 
| TBC
 
| TBC
 
| TBC

Latest revision as of 08:47, 4 May 2015

The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.


Read first:

Document History
Version Date Authors Description Validator Validation Date
0.1.0 TBC Aissanou, Codazzi, Guo TBC TBC TBC


1. Introduction

1.1 Objectif du document d'exigence

Ce document a pour objectif de présenter le projet SeriousGameV2 ainsi que ses objectifs, exigences fonctionnelles et non fonctionnelles, ses risques ainsi que ses critères de qualité.

1.2 Cadre du produit

Le projet SeriousGameV2 est réalisé par 3 étudiants de 4ème année en Réseaux Informatique Communication et Multimédia à Polytech'Grenoble, est tuteuré par Richard Olivier et sa durée est fixée à 7 semaines.

1.3 Définitions, acronymes et abréviations

1.4 Références

  • Nous nous sommes aidés du travail réalisé par les RICM4 de l'année précédente sur le projet SeriousGameV1 : [1]
  • PythonDocumentation.
  • Kivy Documentation.
  • SQlite Documentation.

2. Description générale

Nous devons créer une application comportant une série de mini jeux vidéos pour enfants (de 7 à 10 ans) dont les contraintes seront proches des tests psycho-acoustiques.

2.1 Perspective du produit

Notre produit doit répondre au scénario suivant :

Le parent (ou le médecin) identifie l'enfant par un système de login sur l'application. Il choisit un jeu et commence à y jouer. Les données sont automatiquement enregistrées au fur et à mesure que l'utilisateur joue. Celui-ci peut à tout moment changer les paramètres et/ou changer de jeu. Le médecin chercheur peut ensuite récolter et analyser les données à partir de ses identifiants.

2.2 Fonctions du produit

2.3 Caractéristiques de l'utilisateur

Cette application est destinée à des enfants handicapés de 7 à 10 ans ayant des problèmes d'audition et de parole. L'utilisateur n'a pas besoin d'avoir des connaissances particulières en informatique si ce n'est d'utiliser une tablette. Une personne (un parent ou le médecin) doit pouvoir identifier l'enfant sur le jeux avec ses logins, l'utilisateur doit pouvoir comprendre les règles des jeux.

2.4 Contraintes générales

  • Design épuré, efficace
  • Gameplay travaillé (mise en scène intéressante)

3. Exigences spécifiques, exigences fonctionnelles, non fonctionnelles et exigences d'interface

3.1 Exigence X.Y.Z (en Langage Naturel Structuré)

Fonction: Aider le développement d'enfants malentendants à l'aide d'une série de jeux vidéos dont les contraintes sont proches des tests psycho-acoustiques

Description: Établir une application avec plusieurs jeux vidéos "sérieux".

Inputs: Non renseigné.

Outputs: Non renseigné.

Destination: Enfants malentendants

Action:

  • Mettre en place différents jeux
  • Enregistrer les données dans une base de donnée

Exigences non-fonctionnelles:

  • Réactivité de l'application (instantanée pas de lag).
  • Limitation de l'espace de stockage <centaines de Mo
  • Eviter les pertes de données
  • Eviter les bugs visuels et/ou sonores

-Portage

  • Programme codé en Python
  • Utilisation du framework Kivy

-Persistance

  • Utilisation d'une base de données pour sauvegarder les résultats.
  • Application facile à prendre en main

-Robustesse

  • Temps de traitement des résultats rapide <5 secondes
  • Temps de chargement des mini jeux rapide <5 secondes

Exigences fonctionnelles:

  • Jeux Multi-plateformes.
  • Jeux sonores.
  • Fenêtre d'aide à l'utilisation.
  • Jeux en accord avec les tests psycho-acoustiques effectués en laboratoire.
  • 7 tâches à proposer.
  • Possibilité d'ajouter des jeux facilement.
  • Identification des utilisateurs (enfants).
  • Identification des chercheurs (afin de récupérer les données et de les analyser).

Pre-condition:

  • Avoir une tablette pour utiliser l'application
  • Avoir des log in afin de se connecter

Post-condition: Aucune

Risques: Utilisation d'un langage (Python) et d'un framework (Kivy) inconnus pour les membres du groupe

4.Evolutions du produit

5. Annexes

6. Index