Projet-2014-2015-OpenHAB-ExtendedGUI/SRS: Difference between revisions

From air
Jump to navigation Jump to search
 
(6 intermediate revisions by the same user not shown)
Line 44: Line 44:
* Mais aussi du projet des RICM5 2014 :[http://air.imag.fr/index.php/Extensions_XBMC]<br/>
* Mais aussi du projet des RICM5 2014 :[http://air.imag.fr/index.php/Extensions_XBMC]<br/>


==1.5 Présentation du restant du document==
=2. Description générale=
=2. Description générale=
Nous devrons créer, une interface simple adaptée à des personnes d’un certain âge. L’utilisateur devra décrire sa maison sous forme hiérarchique (voir ci-dessous). Le système détectera les composants de domotique avec l’aide du protocole UPnP, configurera le composant dans le réseau. L’utilisateur devra alors ajouter dans la pièce le matériel détecté. La plupart du temps le composant entre dans une certaine catégorie, de se fait nous lui proposerons différentes action disponible (type IFTTT) pour un composant.
L'objectif de ce projet est de concevoir un système d'information innovant pour la classe de demain. Le but de ce projet est de faciliter mais surtout d'automatiser des tâches quotidiennes effectuées en salle de cours. Bien qu'il y ait quatre projets gravitant autour de la classe intelligente et réalisés par des élèves de l'ENSIMAG, notre module doit s'intégrer avec les autres afin d'obtenir une réelle infrastructure innovante.
==2.1 Perspective du produit==
==2.1 Perspective du produit==
Notre produit doit répondre au scénario suivant : <br>
Notre produit doit répondre au scénario suivant : <br>
L'utilisateur donne un plan de sa maison sous forme hiérarchique. Il place ses composants de domotique compatible UPnP dans sa maison. Un serveur UPnP va alors détecter l'ensemble des appareils dans la maison. Ce dernier via l'interface utilisateur fera apparaitre les composants qu'il a détecté. L'utilisateur devra alors les placer dans la catégorie qui lui convient. L'utilisateur pourra ensuite modifier les informations sur les composants c'est à dire les mettre en marche, etc...
Les élèves entrent en classe et signalent leur présence puis s'installent à leur poste de travail. L'enseignant fait de même, et accède à sa plateforme de travail où il dispose des cours et examens qu'il a éventuellement pu préparer à l'avance.

L'enseignant peut alors soumettre un QCM aux étudiants. Ceux-ci y répondent de manière individuelle, puis soumettent leur réponse à l'enseignant. Ce dernier a alors la possibilité de consulter les résultats, et les afficher de manière thématique. De ce fait, il dispose du droit de revenir sur un point du cours qu'il lui parait intéressant de souligner (notamment si une majorité d'élèves n'en a pas bien saisi le sens), et il peut également réorganiser les étudiants en groupe de travail.
==2.2 Fonctions du produit==
==2.2 Fonctions du produit==
* Création d'une interface graphique
* Identification sécurisée et individuelle
* Création d'éléments de cours (slides de cours, QCM,...)
* Création d'une hiérarchie d'une maison de façon dynamique
* Détection et affichage automatique des composants
* Réponse au QCM par les étudiants
⚫
* Réorganisation des composant en groupe selon leur lieu
* Affichage des résultats
⚫
* Réorganisation des élèves en groupe de travail selon leur niveau


==2.3 Caractéristiques de l'utilisateur==
==2.3 Caractéristiques de l'utilisateur==
Au niveau des utilisateurs, cette applications est destinée à des personnes débutant, afin de leur permettre de simplifier la gestion de leur maison. C'est cet utilisateur qui personalisera ca maison et pourra réalisé les opérations détaillé ci-dessus.
Il y a deux types d'utilisateur pour ce produit et en deux entrées différentes. Le premier est l'enseignant qui peut éditer des cours et des examens et les soumettre à ses élèves. Il y a ensuite les élèves qui répondent au QCM via leur plateforme de travail et soumettent leurs réponses à l'enseignant.


==2.4 Contraintes générales==
==2.4 Contraintes générales==
* Le développement des applications doit être fait sur des tablettes.
* Le développement de application doit être flexible (utilisation d'HTML5).
* Besoin d'une connexion wifi relativement stable au sein de la classe.
* Besoin d'une passerelle vers internet(wifi, 3G, 3G+, 4G).

==2.5 Hypothèses et dépendances==
* Le wifi environnant filtre les sites internet accessibles (pour éviter la triche; on suppose ça ou bien on considère que le temps de la question est trop court pour aller voir google?)
* L'environnement de la salle permet de relier les tablettes au serveur de moodle.


=3. Exigences spécifiques, exigences fonctionnelles, non fonctionnelles et exigences d'interface=
=3. Exigences spécifiques, exigences fonctionnelles, non fonctionnelles et exigences d'interface=
Line 77: Line 71:


==3.1 Exigence X.Y.Z (en Langage Naturel Structuré)==
==3.1 Exigence X.Y.Z (en Langage Naturel Structuré)==
'''Fonction''': Réalisation et gestion de QCM dans le cadre de la SmartClassroom
'''Fonction''': Simplification de l'interface utilisateur OpenHab


'''Description''': Notre projet consiste à développer un système qui permette d'une part à un professeur de préparer ses cours et de créer des examens sous forme de QCM et d'autre part à ses élèves de répondre à ces examens. Il faudra également gérer l'identification de chaque élève afin de contrôler les présences de chacun lors des cours
'''Description''': Notre projet consiste à développer un système qui permette à l'utilisateur de simplifier la gestion de sa maison intelligente, avec notamment la détection automatique des appareils de domotique. Et la proposition d'action sur un composant.


'''Inputs''': Tablettes des étudiants et du professeur
'''Inputs''': Tablette, smartphone, ordinateur, équipement de domotique.


'''Source''': Tag NFC, écran tactile
'''Outputs''': interface d'administration

'''Outputs''': Identification, réponses aux questions de chaque élève


'''Destination''':
'''Destination''':
Destiné à toutes personnes possédant une maison intelligente mais rencontrant des difficultés dans la gestion.
Ce projet est destiné à être intégré au sein de l'environnement d'une Smart Classroom et est à destination des enseignants et des étudiants.


'''Action''':
'''Action''':
* Ajout d'équipement
* Natural language sentences (with MUST, MAY, SHALL)
* Modification des règles sur un équipement
* Graphical Notations : UML Sequence w/o collaboration diagrams, Process maps, Task Analysis (HTA, CTT)
* Modification de la hiérarchie de la maison <br>
* Mathematical Notations
* Tabular notations for several (condition --> action) tuples <br>


Côté enseignant :<br>
'''Côté utilisateur''':
* Doit permettre la création des QCM
* Doit permettre de gérer ca maison
* Doit permettre la récupération des résultats
* Doit donner un affichage hiérarchique des groupes de sa maison.
⚫
* Doit permettre d'effectuer des modifications.
* Pourrait effectuer le tri des résultats en fonctions des élèves/ des questions/ des réponses
* Doit permettre l'identification à l'aide d'un ID personnel ou d'un tag NFC
* Doit permettre l'identification à l'aide d'un ID user.
<br>
Côté étudiant :
* Doit permettre de répondre au QCM
* Peut donner un accès direct au résultat
⚫
* Doit permettre d'effectuer des modifications avant envoi du QCM
* Doit permettre l'identification à l'aide d'un ID personnel ou d'un tag NFC


'''Exigences non-fonctionnelles''':
'''Exigences non-fonctionnelles''':
* Facilité d'utilisation : Pas d'expérience utilisateur requise
* Facilité d'utilisation : Pas d'expérience utilisateur requise
* Portabilité : Utilisation sur tablette
* Portabilité : Utilisation sur tout appareil électronique ayant un accès internet
* Taille : L'application ne dépasse pas quelques Mo
* Taille : Pas de restriction au niveau de la taille
* Utilisabilté : Interface claire et travaillée, de façon à pourvoir une expérience utilisateur efficace
* Utilisabilté : Interface claire et travaillée, de façon à pourvoir une expérience utilisateur efficace
* Robustesse: Pas nécessaire d'avoir un accès lorsque le réseaux est coupé.
* Robustesse: L'application doit continuer à fonctionner et surveiller lors d'une panne du réseau

'''Exigences fonctionnelles''':
* Interface web en HTML5 dans le but pouvoir activer le système, réglage de l’application, dialoguer avec les capteurs domotiques (caméra, badge)
* Gestion de composant de domotique (arrêt/mettre en marche)
* Ajout/retrait de matériel ou de disposition de la maison.



'''Pre-condition''':
'''Pre-condition''':
* Côté matériel :
* Côté matériel :
::- l'utilisateur doit avoir un appareil (smartphone, tablette, pc)
::- une tablette doit être disponible pour chaque élève et pour le professeur
::- chaque élève doit être muni d'un badge afin de l'identifier
::- l'utilisateur doit avoir un id pour la gestion de sa maison
* Côté application :
* Côté application :
::- De préférence toujours avec un accès vers Internet
::- une connexion WiFi doit être maintenue dans la salle de classe


'''Post-condition''':
'''Post-condition''':
* l'utilisateur d'administre sa propre maison
* le professeur est capable de créer des supports pour son cours et des QCM via l'application
* les élèves sont identifiés grâce à leur badge
* les utilisateurs sont identifiés grace à un ID


'''Effets secondaires''':
'''Risques''':
* Ne pas être accepté dans la communauté OPENHAB


=4. Evolution du produit=
=4. Evolution du produit=
* Ajout de nouvelles fonctionnalités
Le projet SmartClassroom est basé sur un ensemble de scénarios réalisés par plusieurs groupes, la partie réalisée ici n'étant que l'un d'entre eux.<br>
* Permettre à l’utilisateur lui même de créer ses règles
De futures améliorations de cet environnement pourront être proposées et implémentées par de prochains groupes en charge du développement de cette classe.


=5. Annexes=
=5. Annexes=
* OpenHAB
* IFTTT
* Wikipedia
* Les clients


=6. Index=
=6. Index=

Latest revision as of 15:11, 1 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 Janvier 2015 Sébastien TOUSSAINT, Thibault SAUSSAC Présentation des exigences du projet OpenHAB Extended GUI TBC TBC


1. Introduction

1.1 Objectif du document d'exigence

Ce document présente l'objectif du projet OpenHAB Extended GUI, ainsi que les exigences fonctionnelles et non fonctionnelles, les risques, et les critères de qualité.

1.2 Cadre du produit

Ce projet est réalisé pour deux étudiants en RICM4 (Réseaux Informatiques et Communication Multimédia) à Polytech' Grenoble dans le cadre de leur projet tuteuré par Didier DONSEZ. La durée est fixé à 7 semaines a compté de 13 janvier 2015.

1.3 Définitions, acronymes et abréviations

  • GUI : Graphical User Interface. est un dispositif de dialogue homme-machine, dans lequel les objets à manipuler sont dessinés sous forme de pictogrammes à l'écran, que l'usager peut utiliser en imitant la manipulation physique de ces objets avec un dispositif de pointage, le plus souvent une souris.(src. Wikipédia).
  • UPnP : Universal Plug and Play. Le but de l'UPnP est de permettre à des périphériques de se connecter aisément et de simplifier la mise en œuvre de réseaux à la maison (partages de fichiers, communications, divertissements) ou dans les entreprises. UPnP le permet en définissant et en publiant les protocoles de commande UPnP au-dessus des standards de communication de l'Internet.(src. Wikipédia).

1.4 Références

  • Nous avons pu nous aider d'un travail réalisé par les RICM4 de l'année précédente : [1]
  • Mais aussi du projet des RICM5 2014 :[2]

2. Description générale

Nous devrons créer, une interface simple adaptée à des personnes d’un certain âge. L’utilisateur devra décrire sa maison sous forme hiérarchique (voir ci-dessous). Le système détectera les composants de domotique avec l’aide du protocole UPnP, configurera le composant dans le réseau. L’utilisateur devra alors ajouter dans la pièce le matériel détecté. La plupart du temps le composant entre dans une certaine catégorie, de se fait nous lui proposerons différentes action disponible (type IFTTT) pour un composant.

2.1 Perspective du produit

Notre produit doit répondre au scénario suivant :
L'utilisateur donne un plan de sa maison sous forme hiérarchique. Il place ses composants de domotique compatible UPnP dans sa maison. Un serveur UPnP va alors détecter l'ensemble des appareils dans la maison. Ce dernier via l'interface utilisateur fera apparaitre les composants qu'il a détecté. L'utilisateur devra alors les placer dans la catégorie qui lui convient. L'utilisateur pourra ensuite modifier les informations sur les composants c'est à dire les mettre en marche, etc...

2.2 Fonctions du produit

  • Création d'une interface graphique
  • Création d'une hiérarchie d'une maison de façon dynamique
  • Détection et affichage automatique des composants
  • Réorganisation des composant en groupe selon leur lieu

2.3 Caractéristiques de l'utilisateur

Au niveau des utilisateurs, cette applications est destinée à des personnes débutant, afin de leur permettre de simplifier la gestion de leur maison. C'est cet utilisateur qui personalisera ca maison et pourra réalisé les opérations détaillé ci-dessus.

2.4 Contraintes générales

  • Le développement de application doit être flexible (utilisation d'HTML5).
  • Besoin d'une passerelle vers internet(wifi, 3G, 3G+, 4G).

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

  • document external interfaces,
  • describe system functionality and performance
  • specify logical database requirements,
  • design constraints,
  • emergent system properties and quality characteristics.

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

Fonction: Simplification de l'interface utilisateur OpenHab

Description: Notre projet consiste à développer un système qui permette à l'utilisateur de simplifier la gestion de sa maison intelligente, avec notamment la détection automatique des appareils de domotique. Et la proposition d'action sur un composant.

Inputs: Tablette, smartphone, ordinateur, équipement de domotique.

Outputs: interface d'administration

Destination: Destiné à toutes personnes possédant une maison intelligente mais rencontrant des difficultés dans la gestion.

Action:

  • Ajout d'équipement
  • Modification des règles sur un équipement
  • Modification de la hiérarchie de la maison

Côté utilisateur:

  • Doit permettre de gérer ca maison
  • Doit donner un affichage hiérarchique des groupes de sa maison.
  • Doit permettre d'effectuer des modifications.
  • Doit permettre l'identification à l'aide d'un ID user.

Exigences non-fonctionnelles:

  • Facilité d'utilisation : Pas d'expérience utilisateur requise
  • Portabilité : Utilisation sur tout appareil électronique ayant un accès internet
  • Taille : Pas de restriction au niveau de la taille
  • Utilisabilté : Interface claire et travaillée, de façon à pourvoir une expérience utilisateur efficace
  • Robustesse: Pas nécessaire d'avoir un accès lorsque le réseaux est coupé.

Exigences fonctionnelles:

  • Interface web en HTML5 dans le but pouvoir activer le système, réglage de l’application, dialoguer avec les capteurs domotiques (caméra, badge)
  • Gestion de composant de domotique (arrêt/mettre en marche)
  • Ajout/retrait de matériel ou de disposition de la maison.


Pre-condition:

  • Côté matériel :
- l'utilisateur doit avoir un appareil (smartphone, tablette, pc)
- l'utilisateur doit avoir un id pour la gestion de sa maison
  • Côté application :
- De préférence toujours avec un accès vers Internet

Post-condition:

  • l'utilisateur d'administre sa propre maison
  • les utilisateurs sont identifiés grace à un ID

Risques:

  • Ne pas être accepté dans la communauté OPENHAB

4. Evolution du produit

  • Ajout de nouvelles fonctionnalités
  • Permettre à l’utilisateur lui même de créer ses règles

5. Annexes

  • OpenHAB
  • IFTTT
  • Wikipedia
  • Les clients

6. Index

Retrieved from "https://air.imag.fr/index.php?title=Projet-2014-2015-OpenHAB-ExtendedGUI/SRS&oldid=20655"