GUI Modeler - SNIper
Spécifications
Supplémentaires
Version <1.1>
Historique des Révisions
|
Date |
Version |
Description |
Auteur |
|
22/11/2001 |
1.0 |
Création |
ISI3_BE1 |
|
11/12/2001 |
1.1 |
Nouvelles caractéristiques
fonctionnelles |
ISI3_BE1 |
|
|
|
|
|
Table des matières
1. Introduction 4
1.1 Objectif 4
1.2 Portée 4
1.3 Documents de Référence 4
1.4 Contenu du document 4
2. Fonctionnalité 4
2.1 Annulation des dernières opérations 4
2.2 Environnement multi-documents 4
2.3 Zoom 4
2.4 Défilement du diagramme SNI 4
2.5 Copier / Couper / Coller des éléments du diagramme SNI 4
2.6 Confirmations et acquittements 4
2.7 Aide en ligne 5
3. Utilisabilité 5
3.1 Temps de formation des utilisateurs 5
3.2 Accès aux fonctions du logiciel 5
4. Fiabilité 5
4.1 Quantité de bogues tolérés 5
5. Supportabilité 5
5.1 Adaptabilité 5
5.2 Maintenabilité 5
5.3 Compatibilité 5
5.4 Installabilité 5
6. Contraintes de conception 5
6.1 Persistance des données 5
7. Contraintes d’implémentation 6
7.1 Outils – technologies de développement 6
8. Contraintes d’interface graphique 6
8.1 Contenu des écrans 6
8.2 Résolution 6
9. Contraintes physiques 6
9.1 Perte d’information 6
9.2 Espace disque 6
10. Composants achetés 6
11. Exigences de licence 6
12. Loi, Copyright, et autres Notices 6
Spécifications Supplémentaires
Ce document est basé sur la notion de F.U.R.P.S (Fonctionnality, Usability, Reliability, Performance, Supportability) introduite par Hewlet Packard et reprise par le processus PILPOIL.
L’objectif de ce document est de décrire les exigences fonctionnelles (hors cas d’utilisation) et non fonctionnelles du logiciel à réaliser qui ne peuvent pas figurer dans les Cas d’Utilisation, ainsi que les contraintes qui s’y appliquent.
Ce document s’adresse à l’architecte et aux développeurs. Il est complémentaire au modèle des cas d’utilisation, et au même que ce dernier, sert de base à la conception de l’architecture.
·
Document Vision v1.1
– ISI3_BE1
·
Glossaire v1.0 –
ISI3_BE1 (pour les termes métier)
Dans les paragraphes suivants seront présentées les exigences fonctionnelles et non fonctionnelles (les « qualités »), ordonnées selon des notions d’utilisabilité, de fiabilité, de performance ou encore de supportabilité. Ensuite seront abordées les contraintes de conception, d’implémentation, d’interface, et enfin les contraintes physiques.
Sont répertoriées ici les caractéristiques non exprimables sous forme de
cas d’utilisation.
L’utilisateur doit pouvoir annuler la ou les dernières opérations qu’il a effectué sur le diagramme SNI en cours d’édition, à l’aide d’une fonction « Undo » (« annuler »). L’utilisation de cette commande remet le diagramme dans l’état où il se trouvait précédant l’opération. On ne peut annuler que les 10 dernières opérations.
SNIper doit offrir une interface de type « multi-documents », c’est à dire que l’utilisateur peut éditer plusieurs diagrammes SNI en même temps, chacun s’ouvrant dans une nouvelle fenêtre indépendante des autres. Lorsque l’utilisateur choisit de quitter l’application, toutes les fenêtres se ferment.
L’utilisateur doit pouvoir zoomer en avant et en arrière sur tout ou partie du diagramme SNI. L’interface proposera des barres de défilement (« scrollbars » ou « ascenseurs ») afin de visualiser les parties du diagramme ne pouvant être affichées dans la fenêtre courante.
Dans le cas où le diagramme SNI est trop grand pour tenir entièrement dans la fenêtre principale de l’application, l’utilisateur doit disposer de barres de défilement horizontales et verticales lui permettant de cadrer la partie du SNI souhaitée dans la fenêtre.
L’utilisateur doit pouvoir dupliquer ou déplacer un ou plusieurs éléments
du diagramme SNI (UD, liaisons, étiquettes…) par simple Copier / Coller ou
Couper / Coller.
L’utilisateur doit être prévenu en cas d’erreur (erreur du logiciel ou erreur de manipulation de sa part) : le système doit afficher une boîte de message contenant une explication claire sur le problème rencontré.
L’utilisateur doit pouvoir accéder à tout moment à une aide en ligne complète sur l’utilisation des diverses fonctionnalités du logiciel. Cette fonction ne doit pas être confondue avec l’aide en ligne sur la méthode SNI, décrite comme un besoin utilisateur dans le Document Vision v1.1.
Un utilisateur moyen doit savoir utiliser les principales fonctions du logiciel en moins d’une heure. L’aide en ligne intégrée dans l’application doit aller dans ce sens.
Toutes les fonctions du logiciel doivent être accessibles sur un seul écran sous forme de barres d’outils et de menus.
Les bogues mineurs, comme les fautes d’orthographes, les erreurs de message, les problèmes d’affichage de couleurs, etc., sont tolérés tant qu’ils ne gênent pas l’utilisation du logiciel. Par contre, les bogues majeurs tels que la perte d’information ou le blocage de l’application doivent impérativement être corrigés.
Ce paragraphe décrit les exigences liées au concept de maintenance et de supportabilité du système à réaliser.
L’application sera conçue pour supporter les modifications et prendre en compte les évolutions, notamment l’ajout de nouvelles fonctionnalités, telles que la génération automatique de diagrammes SEF à partir de diagramme SNI, et l’ajout des prochains modules (éditeur de SEF, visualiseur d’interface …). Ceci est possible grâce à la définition d’une architecture commune et à l’utilisation d’une couche middleware pour la manipulation des fichiers, pour tous les modules.
Le développement du système complet (éditeur SNI, éditeur SEF, visualiseur d’interface) est prévu sur plusieurs années. Ainsi, le code produit par les développeurs devra impérativement être commenté. Si l’application ne devait pas être terminée dans les temps, un document sera produit décrivant précisément les mises à jours à apporter au logiciel pour le terminer.
L’application doit pouvoir fonctionner sur les deux systèmes utilisés à l’UPS, à savoir UNIX et Windows.
Pour que le logiciel fonctionne, il est nécessaire que le système d’exploitation utilisé possède une machine virtuelle Java. Si ce n’est pas le cas, il faudra en installer une. Aucun autre logiciel n’est nécessaire.
Les diagrammes SNI réalisés avec l’éditeur SNIper
sont sauvegardés individuellement sous forme de fichiers. Aucune base de données n’est
donc nécessaire, puisque il n’y a aucune autre information persistante.
·
Les développeurs
utiliseront le langage JAVA pour réaliser l’application.
·
Ceux-ci sont libres
d’utiliser un outil RAD (Développement Rapide d’Applications) tel que Borland
Jbuilder ©, ou Forte, à condition qu’il soit gratuit et libre de droit. Si
c’est le cas, un soin tout particulier doit être apporter aux tests de
l’interface graphique, dans un souci de portabilité du logiciel, puisque en
effet le résultat peut varier d’un système à l’autre.
·
Dans les deux cas,
la version du JDK (Java Development Kit) utilisée doit comporter les
bibliothèques Swing et Awt pour la gestion des interfaces graphiques , et
la bibliothèque Java2D pour les dessins de graphes.
·
Toute autre
bibliothèque Java gratuite et libre de droit peut être utilisée.
·
Le logo « SNIper» et le logo de l’IUP ISI
doivent apparaîtrent à la fois au démarrage de l’application et sur la fenêtre
principale. Le logo de l’IUP ISI doit apparaître dans toutes les pages.
·
Chaque fenêtre
possède un titre qui explique son rôle. Le titre de la fenêtre principale est
le nom de l’application.
Les fenêtres de l’application seront prévues pour
une résolution d’écran de 1024´768 pixels.
Aucune perte d’information ne sera tolérée.
Les comptes des étudiants sur les serveurs de l’UPS étant limités en volume de données, la taille (en Kilo octets) l’application mais surtout des fichiers générés (sauvegardes des diagrammes) doit rester raisonnable, c’est à dire inférieure à 50Ko.
Aucun composant ne sera acheté spécifiquement pour ce projet.
L’application SNIper n’est pas soumise à l’achat d’autres produits ni ne nécessite de posséder une licence.
Le logo de l’IUP ISI apparaissant dans le logiciel est la propriété de
l’IUP ISI.