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

From air
Jump to navigation Jump to search
(Created page with "The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard. '''Read first:''' * http://www.cs.st-an...")
 
Line 30: Line 30:
   
 
=1. Introduction=
 
=1. Introduction=
==1.1 Purpose of the requirements document==
+
==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 Scope of the product==
 
==1.3 Definitions, acronyms and abbreviations==
+
==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 tueuré par Richard Olivier et sa durée est fixée à 7 semaines.
==1.4 References==
 
  +
==1.5 Overview of the remainder of the document==
 
  +
==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 : [http://air.imag.fr/index.php/Serious_Game:_Handicap,_parole_et_geste]<br/>
  +
*[http://www.python.org/ Python] for definitions and documentation.
  +
*[http://kivy.org/#home Kivy] for definitions and documentation.
  +
*[http://www.sqlite.org/ SQlite] for definitions and 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 : <br>
  +
  +
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 et de parole.
  +
  +
==2.4 Contraintes générales==
  +
  +
=3. Exigences spécifiques, exigences fonctionnelles, non fonctionnelles et exigences d'interface=
  +
  +
==3.1 Exigence X.Y.Z (en Langage Naturel Structuré)==
  +
  +
=5. Annexes=
  +
  +
=6. Index=
  +
 
=2. General description=
 
=2. General description=
 
==2.1 Product perspective==
 
==2.1 Product perspective==

Revision as of 16:30, 3 February 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 TBC 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 tueuré 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]
  • Python for definitions and documentation.
  • Kivy for definitions and documentation.
  • SQlite for definitions and 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 et de parole.

2.4 Contraintes générales

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

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

5. Annexes

6. Index

2. General description

2.1 Product perspective

2.2 Product functions

2.3 User characteristics

2.4 General constraints

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:

Description:

Inputs:

Source:

Outputs:

Destination:

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