Rédaction du Document de Spécifications Logiciel

Transcription

1 Rédaction du Document de Spécifications Logiciel Instruction Générale Qualité Version : 1.1 Nombre de pages : 12 Référence : referentiel_qualite/dsl.plan_type.doc UV UMLP Département ASI INSA-ROUEN BP 08 Avenue de l Université SAINT-ETIENNE-DU-ROUVRAY Cedex

2 Page de service Historique des évolutions Version Date Auteur Pages/parties Description modifiées /03/2004 FBA Toutes Ce document a été établi à partir d éléments initialement rédigés par Arnaud Deromas pour la Junior Entreprise EDIS ( Ils ont été adaptés aux mini-projets proposés dans l UV UMLP /02/2005 FBA Toutes Refonte pour le semestre 2005P Suivi des diffusions Entité Etudiants de l UV UMLP Intervenants de l UV UMLP Nom tous tous Auteur : Vérificateur : Nom et qualité FBA FFI Date et visa le : le : Approbateur : le : Documents associés Document Manuel Qualité du mini-projet UMLP manuel_qualite.doc dans : Référence [MQ] Version : 1.1 Page : 2

3 SOMMAIRE Sommaire Introduction Domaines d application Contenu du DSL Introduction Objectifs du document Champ d application Organisation du document Description globale L environnement du produit Interfaces utilisateur Fonctionnalités du produit Profil des utilisateurs Contraintes de développement Hypothèses et Dépendances Spécifications détaillées Cas d utilisation Cas d utilisation Contraintes imposées à la conception Description des fournitures Annexes Annexe : Exemple de cas d utilisation rédigé Version : 1.1 Page : 3

4 1 INTRODUCTION L Instruction Générale Qualité de Document de Spécifications Logiciel décrit ce qu il est nécessaire d indiquer dans un Document de Spécifications Logiciel (DSL). Le présent document doit être pris comme un guide d utilisation destiné à aider à la rédaction d un DSL. Ce document est adapté au cadre du mini-projet de l UV UMLP. Il permet de comprendre, chapitre par chapitre, ce qui doit figurer dans chacun des chapitres de ce document. Ce document peut servir de base éventuellement dans d autres organisations (au cours d un stage, de votre vie professionnelle ou associative, ) qui ne disposeraient d une telle formalisation de leur processus. En revanche, les étudiants doivent être conscient que chaque organisation ou contexte de développement (PIC, projet MGPI, ) est libre de définir des document-types alternatifs, avec une structure et des modèles d organisation complètement différents. Version : 1.1 Page : 4

5 2 DOMAINES D APPLICATION L Instruction Générale Qualité de Document de Spécifications Produit s applique à tout produit qui suit les plans de développement légers, développés de manière itérative dans le cadre de l UV UMLP. Version : 1.1 Page : 5

6 3 CONTENU DU DSL Chacun des sous chapitres qui vont suivre correspond à un chapitre d un DSL. Ainsi, le chapitre 3.1 décrit le chapitre 1 d un DSL. Le chapitre 3.2.1, décrit le chapitre 2.1 d un DSL. Certains chapitres pourront être omis, en fonction de leur pertinence en rapport avec le domaine étudié. Si des artefacts ne peuvent être insérées dans des chapitres, ils doivent être reportés en Annexe. 3.1 INTRODUCTION L introduction se décompose en cinq sous chapitres qui ont pour but de présenter globalement le projet développé sans entrer dans le détail des spécifications Objectifs du document Préciser l objet de ce document et son audience Champ d application Identifier très clairement le produit à développer en lui donnant un nom. Exemple : site de commerce en ligne, infocentre, didacticiel etc. Expliquer ce que fera et éventuellement ce que ne fera pas le produit. Dire à quoi va servir le logiciel, ce qu il va apporter de bénéfique Organisation du document Expliquer comment le DSL est organisé, et tout particulièrement quelle organisation prévaut pour le chapitre spécifications détaillées (chapitre 3 du DSL). 3.2 DESCRIPTION GLOBALE Tous les facteurs pouvant influer sur le produit et sur le respect des exigences sont recensés ici. On n aborde pas encore le détail des spécifications, mais on décrit le contexte dans lequel le logiciel sera insérer. Préciser dans ce paragraphe l environnement d exploitation et d utilisation des matériels et logiciels (profil des machines, système d exploitation, lieu d installation et d exploitation, protocoles ) L environnement du produit Si le logiciel est imbriqué dans une entité plus générale, ou s il reçoit des données en provenance d autres systèmes ou qu il envoie des données vers d autres systèmes, il sera sans doute utile d inclure un diagramme de déploiement (au sens UML), voire un diagramme de composants (au sens UML) pour représenter ces interactions. Version : 1.1 Page : 6

7 3.2.2 Interfaces utilisateur Description des interfaces utilisateur. Exemple : taille des écrans, disposition des objets graphiques, activation ou non de certaines touches de fonctions Si il y a différents profils d utilisateur on peut aussi expliquer le comportement de l application en fonction de ces profils Interfaces matérielles On décrit comment le logiciel s adapte au matériel sur lequel il tourne. On peut définir la portabilité du logiciel sur différents système d exploitation ou simplement prévoir comment il s adapte à des machines configurés avec des périphériques différents Interfaces logicielles Le logiciel peut s interfacer avec d autres logiciels. Il peut s agir de logiciels «maison» ou de logiciels achetés sur étagère. Dans tous les cas, la liste de ces logiciels et leurs caractéristiques précises (nom, n version/release) doit figurer dans ce paragraphe Interfaces de communication Décrire l architecture réseau sur laquelle s appuie le logiciel, quelles sont les protocoles utilisés et reporter ces informations de manière graphique sur l éventuel diagramme de déploiement du chapitre 2.1 («L environnement du produit») Environnement opérationnel A quel moment effectue t-on les sauvegardes? Y a t-il des périodes où le logiciel est plus sollicité? Quelle est l organisation des utilisateurs? Fonctionnalités du produit. Représentation des principales fonctions assurées par le logiciel. En particulier on doit faire apparaître les évènements externes ou internes qui provoquent l activation des fonctions. Le formalisme du diagramme des cas d utilisation est approprié. Les cas d utilisation les plus pertinents feront l objet d une description pas à pas dans la section suivante (3. Spécifications détaillées) à l aide d une ou plusieurs technique : description textuelle, diagramme d activité, diagramme de séquence système Profil des utilisateurs. Description des compétences et du niveau d expérience des utilisateurs. Version : 1.1 Page : 7

8 3.2.5 Contraintes de développement On décrit ici globalement tous les éléments à prendre en considération par les équipes de développement lors du choix des options techniques. Ces éléments concernent généralement : les normes et législations particulières applicables. Les limitations liées au matériel. Les interfaces avec d autres applications. Le niveau de fiabilité demandé. le niveau de sécurité demandé Hypothèses et Dépendances La possibilité de réaliser certaines exigences peut être soumise à conditions, ou dépendre d éléments bien précis. Il faut énoncer ici ces éléments et ces conditions. 3.3 SPECIFICATIONS DETAILLEES Description détaillée des fonctionnalités du logiciel à l aide de cas d utilisation. Chaque fonctionnalité peut être éclatée en plusieurs cas d utilisation (sous-fonctionalités), ellesmêmes décomposées Un sous chapitre par cas d utilisation. Un exemple de cas d utilisation est proposé en Annexe Cas d utilisation 1 Pour chaque cas d utilisation, on trouve les chapitres suivants: Titre Résumé Acteurs Pré-condition(s) Action Déclencheur Scénario nominal Action du (des) acteur(s) Action du système Version : 1.1 Page : 8

9 Action de fin Post-condition(s) Exceptions Remarques ergonomiques (éventuellement) Contraintes non fonctionnelles (éventuellement) Cas d utilisation 2.mêmes chapitres que pour le Cas d utilisation Contraintes imposées à la conception Conformité aux règles et standards en vigueur chez le client Il peut s agir du format des états, de conventions de nommage des données, de méthodes de mesures ou d audit Caractéristiques mesurables exigées Le client peut exiger que le logiciel livré possède des caractéristiques mesurables très précises. Les caractéristiques les plus souvent rencontrées sont exposées ciaprès Sûreté du système Les méthodes pour déterminer comment mesurer la sûreté du système sont exposées ici Disponibilité du système Les méthodes pour déterminer comment mesurer la disponibilité du système sont exposées ici Sécurité On trouvera la description de méthodes de sécurité telles que le cryptage des données, la restriction des communications entre certaines parties du logiciel, la conservation de fichiers journaux (log) ou historiques. Version : 1.1 Page : 9

10 Maintenabilité Le client peut exiger d avoir un logiciel facile à maintenir. Il peut demander, par exemple, qu on lui livre un logiciel très modulaire, doté d interfaces normalisées, ou de limiter le niveau de complexité des fonctions (en limitant le nombre de sous programmes appelés, par exemple) Portabilité Le client peut exiger d avoir un logiciel plus ou moins portable. Les caractéristiques mesurables de cette portabilité peuvent être : Le pourcentage de composants dépendants de la machine d exploitation. Le pourcentage de lignes de code dépendants de la machine d exploitation. Le client peut aussi exiger l utilisation d un langage réputé portable, d un compilateur bien précis, ou d un système d exploitation. 3.4 DESCRIPTION DES FOURNITURES Préciser de façon exhaustive, quels sont les documents et matériels qui doivent être remis au client au moment de la réception des prestations (Manuel Utilisateur, Exécutable, Code source, CDROM, l ensemble du référentiel de développement ). 3.5 ANNEXES Inclure ici les annexes. On trouvera ici des artefacts très variées allant de l échantillon de formulaires utilisés dans le système ou l organisation existante, en passant par des compte-rendus de réunion, de rencontre avec la maîtrise d ouvrage. Ne pas hésiter à joindre tout document pouvant aider le lecteur à mieux comprendre le DSL. Version : 1.1 Page : 10

11 4 ANNEXE : EXEMPLE DE CAS D UTILISATION REDIGE Domaine : Système de gestion d une bibliothèque Titre: Emprunter ouvrage. Résumé: Liste des actions réalisées par un étudiant se présentant pour emprunter un ouvrage dans la bibliothèque. Acteurs : Etudiant (E), Hôtesse (H) Pré-condition(s): L étudiant est inscrit à la bibliothèque L étudiant a trouvé son ouvrage dans les rayons de la bibliothèque Déclencheur: 0. L étudiant souhaite emprunter le livre qu il a en main. Scénario nominal Action du (des) acteur(s) Action du système 1. E se présente à l accueil 2. H récupère les coordonnées de l ouvrage 3. Le système (S) signale si l ouvrage est dispo (Exception A) 4. H demande la carte d inscription à la bibliothèque 7. H précise la date de retour et demande confirmation 8. E confirme son intention de retirer le livre 9. H valide l emprunt Action de fin: 10. E quitte l accueil avec son ouvrage. Post-condition(s): L ouvrage n est plus disponible pour un autre prêt. 5. S vérifie la validité de la carte (Exception B) 6. S indique la date de retour Exceptions: Exception A : L ouvrage a été réservé H signale la non-dispo de l ouvrage, H invite l étudiant à revenir à la date d expiration de l emprunt. E se retire. Exception B : La carte n est pas valide ou l étudiant est banni pour quelques jours car il a rendu son précédent emprunt trop tard. H précise les causes du refus de prêt E se retire. Remarques ergonomiques H pourra utiliser une douchette (lecteur de code barre) pour récupérer les coordonnées de l ouvrage. Version : 1.1 Page : 11

12 Contraintes non fonctionnelles Type contrainte Temps réponse Fréquence Volumétrie Disponibilité Concurrence Intégrité Confidentialité de de Descriptif Les différentes requêtes doivent prendre moins de 3 secondes On peut compter une dizaine de consultation de ce type dans une heure de travail de H Le nombre de livres est de l ordre de titres. Le nombre d inscrits à la bibliothèque est de l ordre de 5000 personnes. Cette fonction doit être opérationnelle dans les heures d ouverture de la bibliothèque Non applicable. Dans la mesure où l étudiant présente le livre, aucune autre personne ne peut demander des infos sur un même enregistrement de livre. Non spécifique. Non spécifique. Version : 1.1 Page : 12