Cahier des spécifications pour Version 1.0 approuvée, préparée par Philippe ZDZIOBECK et Amine TIFAK Octobre 2010
Table des matières I. Introduction...2 1. Introduction...2 2. But du projet...2 3. Références...2 II. globale...3 1. Contexte...3 2. Perspective du logiciel...3 3. Diagramme acteurs-flux...3 III. s du système...4 1. S authentifier sur le logiciel...4 2. Faire pivoter la maison...4 3. Fermer automatiquement les volets...5 4. Gérer les absences du propriétaire...5 IV. Exigences de l interface externe...6 1. Interface utilisateur...6 2. Interface matérielle...6 3. Interface logicielle...6 4. Interface de communication...7 V. Autres exigences non fonctionnelles...8 1. Exigences de performance...8 2. Exigences de sécurité...8 3. Exigences de qualité...8 ANNEXE A. Dictionnaire et modèle de données...9 ANNEXE B. Diagramme état-transition... 11 Page 1
I. Introduction 1. Introduction Ce cahier de spécification décrit les besoins fonctionnels et non fonctionnels relatifs au logiciel Gestion Pivot Manager (GPM). Ce document est destiné à être utilisé exclusivement par tous les membres de l équipe projet qui va implémenter et vérifier le bon fonctionnement du système. Toutes les spécifications notées dans ce document sont hautement prioritaires et exigées pour la version 1.0 2. But du projet Le projet a pour but la réalisation d un logiciel de gestion de maisons pivotantes, afin de modifier l orientation de ces maisons selon plusieurs critères, comme la température ou la position du soleil, ou la zone géographique. Il est destiné à l entreprise SEIKO, qui bâtit des maisons en kit sur pivot. 3. Références 1. http://everinghamrotatinghouse.com.au/ 2. http://atoutcoeurimmobilier.blogspot.com/2008/06/une-maison-pivotant-360-degrsthe.html 3. http://www.youtube.com/watch?v=qp_n8-y7ycm&feature=player_embedded# 4. http://labh-curien.univ-stetienne.fr/~fj/gl/exemplesrequirements/cafeteriaorderingsystem.pdf Page 2
II. globale 1. Contexte Le logiciel intervient dans le cadre de l achat d une maison pivotante. Une maison pivotante est montée sur une plateforme pivotante (voir référence 2). Ces maisons respectent un certain modèle (pas de personnalisation possible) : - de type plein pied (pas d étage) - superficie de 100 à 150m² - pivot seulement sur l axe Z 2. Perspective du logiciel Le logiciel GestionPivotManager doit gérer la rotation automatique et manuelle de la maison selon plusieurs contraintes externes. Le diagramme suivant illustre le fonctionnement et le scénario du système en fonction des différents acteurs qui vont interagir avec ce logiciel. Une première maquette fonctionnelle doit être élaborée, puis validée par le client pour ensuite aboutir à une première version. 3. Diagramme acteurs-flux Page 3
III. s du système 1) S authentifier sur le logiciel Le propriétaire de la maison doit s authentifier au moyen d un identifiant et d un mot de passe. De ce fait, une personne non autorisée (un enfant ou un voisin) ne doit pas avoir accès à l interface et à toutes ces fonctionnalités. Enfin, le mot de passe doit pouvoir être changé autant de fois que nécessaire, à l inverse de l identifiant qui devra rester identique. A. User.login Authentifier l utilisateur B. User.changepassword Changer le mot de passe de l utilisateur 2) Faire pivoter la maison a) Pivoter manuellement ou selon la position du soleil Le système doit être en mesure de faire pivoter la maison selon la position du soleil. Le processus de pivot est le suivant : A. Sun.getPosition Renseigner la position du soleil sur Z B. Sun.setNewPosition Définir la position du soleil désirée C. House.getPosition Déterminer la position actuelle de la maison sur Z D. House.calculateMoves Calculer les mouvements à opérer E. House.sendMoves Envoyer les ordres de pivot b) Régler la vitesse de déplacement L utilisateur doit pouvoir régler la vitesse de déplacement, cette vitesse étant restreinte pour des raisons de sécurité A. House.setSpeed Renseigner la vitesse désirée B. House.alertSpeed Alerter l utilisateur que la vitesse désirée n est pas possible Page 4
c) Gérer le cycle jour/nuit selon les saisons A. House.getSeason Acquérir la saison selon la date du calendrier et les données GPS B. House.calculateCycle Calculer le cycle jour/nuit qui découle de la saison d) Ensoleiller une pièce en priorité A. Room.setPriority Définir la priorité d une pièce pour l ensoleillement e) Définir luminosité/température à atteindre A. House.setLuminosity Définir la luminosité à atteindre B. House.setTemperature Définir la température à atteindre 3) Fermer automatiquement les volets A. Room.AutoCloseShutter Définir un volet à fermer automatiquement selon critères B. Room.CloseShutter Fermer automatiquement un volet 4) Gérer les absences du propriétaire A. House.setAbsentProprietary Définir les dates d absences du propriétaire B. House.getAbsentProprietary Acquérir l absence ou non du propriétaire pour la date du jour Page 5
2) Exigences de l interface externe 1) Interface utilisateur UI-1 : le Logiciel GestionPivotManager doit afficher un écran d accueil avec 4 fonctionnalités principales : - Sélection de la pièce la plus ensoleillée - Définition de la luminosité/température exigée - Gestion des absences de l utilisateur - Ouverture/Fermeture des volets d une pièce - Autres paramètres et réglages - Aide UI-2 : le système doit afficher l écran de gestion de la pièce la plus ensoleillée, avec la représentation 3D de la maison UI-3 : le système doit afficher l écran de gestion de la luminosité/température, réglable par pièce UI-4 : le système doit afficher un calendrier avec des dates de présence et d absences réglables UI-5 : le système doit afficher l écran de gestion des volets, avec la représentation 3D de la maison UI-6 : le système doit afficher l écran Autres paramètres et réglages, qui inclut : - le pivot manuel de la maison - le réglage de la vitesse de déplacement - le réglage du cycle jour/nuit UI-7 : le système doit afficher une documentation complète et simple 2) Interface matérielle MI-1 : le système doit contrôler le pivot de la maison et lui envoyer des ordres de rotation sur Z 3) Interface Logicielle SI-1 : le système doit récupérer la position du soleil de la part du fournisseur de données solaires SI-1.1 : le système doit demander à intervalle régulier très court la position du soleil SI-1.2 : le système doit récupérer la position du soleil à cet instant SI-2 : le système doit envoyer toutes les informations à l interface graphique de l écran tactile Page 6
4) Interface de Communication CI-1 : le système doit être en mesure de communiquer avec SEIKO, dans les cas suivants CI-1.1 : Erreur d exécution ou rapport de plantage CI-1.2 : Données solaires inhabituelles ou non-conformes aux standards CI-1.3 : Demande d aide de la part de l utilisateur CI-2 : le système doit établir une communication constante avec le fournisseur de données solaires CI-2 : le système doit pouvoir, après plantage ou bug, recevoir une éventuelle mise à jour corrective Page 7
3) Autres exigences non fonctionnelles 1) Exigences de performance PE-1 : le Logiciel GestionPivotManager doit avoir un taux de disponibilité de 99,9% entre 7h00 et 22h00. Il doit avoir un taux de disponibilité de 95% de 22h00 à 7h00. PE-2 : toutes les réponses aux requêtes doivent être affichées à l écran dans un délai de 7 secondes maximum. PE-2 : le système doit afficher un message de confirmation à l utilisateur dans un délai de 4 secondes après que ce dernier ait exécuté une commande. 2) Exigences de sécurité SE-1 : la vitesse de déplacement ne doit en aucun cas dépasser les standards saisis par SEIKO. Si une demande de vitesse supérieure était saisie par l utilisateur, le logiciel devrait refuser la rotation et informer SEIKO. SE-2 : l utilisateur doit bénéficier d un bouton d arrêt d urgence en cas de disfonctionnement grave du logiciel et du pivot. SE-3 : aucune personne tierce ne doit pouvoir s identifier sur le logiciel, excepté un technicien de SEIKO. SE-4 : Si le mot de passe est découvert par une personne tierce, l utilisateur doit pouvoir en informer SEIKO, et il sera ainsi changé. 3) Exigences de qualité QE-1 : le Logiciel GestionPivotManager doit avoir un taux de disponibilité de 99,9% entre 7h00 et 22h00. Il doit avoir un taux de disponibilité de 95% de 22h00 à 7h00. QE-2 : Aucune rotation inutile ne doit être effectuée, notamment en cas d absence du propriétaire. Page 8
ANNEXE A. Dictionnaire et modèle de données ICI DEVRAIT APPARAITRE LE DICTIONNAIRE DES DONNÉES Page 9
ICI DEVRAIT APPARAITRE LE MODÈLE DES DONNÉES Page 10
ANNEXE B. Diagramme état-transition ICI DEVRAIT APPARAITRE LE DIAGRAMME ÉTAT-TRANSITION Page 11