Rédaction du Document de Spécifications Logiciel

Rédaction du Document de Spécifications Logiciel

Instruction Générale Qualité

Page de service

Historique des évolutions

Version	Date	Auteur	Pages/parties modifiées	Description
1.1	26/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 (http://www.fiifo.u-psud.fr/Actu/Initiatives/EDIS.htm). Ils ont été adaptés aux mini-projets proposés dans l’UV UMLP.
1.1	25/02/2005	FBA	Toutes	Refonte pour le semestre 2005P

Suivi des diffusions

Entité	Nom
Etudiants de l’UV UMLP	tous
Intervenants de l’UV UMLP	tous

	Nom et qualité	Date et visa
Auteur :	FBA	le :
Vérificateur :	FFI	le :
Approbateur :		le :

Documents associés

Document	Référence
Manuel Qualité du mini-projet UMLP manuel_qualite.doc dans : http://asi.insa-rouen.fr/enseignement/siteUV/genie_logiciel/referentiel_qualite/	[MQ]

Sommaire

Sommaire 3

1 Introduction 4

2 Domaines d’application 5

3 Contenu du DSL 6

4 Annexe : Exemple de cas d’utilisation rédigé 11

1Introduction

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.

2Domaines 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.

3Contenu 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.1Introduction

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.

3.1.1Objectifs du document

Préciser l’objet de ce document et son audience.

3.1.2Champ 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.

3.1.3Organisation 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.2Description 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…).

3.2.1L’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.

3.2.2Interfaces 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.

3.2.2.1Interfaces 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.

3.2.2.2Interfaces 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.

3.2.2.3Interfaces 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 »).

3.2.2.4Environnement 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 ?

3.2.3Fonctionnalité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.

3.2.4Profil des utilisateurs.

Description des compétences et du niveau d’expérience des utilisateurs.

3.2.5Contraintes 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é.
  

3.2.6Hypothè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.3Spécifications détaillées

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), elles-mêmes décomposées… Un sous chapitre par cas d’utilisation. Un exemple de cas d’utilisation est proposé en Annexe.

3.3.1Cas d’utilisation 1

Pour chaque cas d’utilisation, on trouve les chapitres suivants:

3.3.1.1Titre

3.3.1.2Résumé

3.3.1.3Acteurs

3.3.1.4Pré-condition(s)

3.3.1.5Action Déclencheur

3.3.1.6Scénario nominal

Action du (des) acteur(s)	Action du système

3.3.1.7Action de fin

3.3.1.8Post-condition(s)

3.3.1.9Exceptions

3.3.1.9.1Remarques ergonomiques (éventuellement)

3.3.1.9.2Contraintes non fonctionnelles (éventuellement)

3.3.2Cas d’utilisation 2

….mêmes chapitres que pour le Cas d’utilisation 1

3.3.3Contraintes imposées à la conception

3.3.3.1Conformité 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.

3.3.3.2Caracté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 ci-après.

3.3.3.2.1Sûreté du système

Les méthodes pour déterminer comment mesurer la sûreté du système sont exposées ici.

3.3.3.2.2Disponibilité du système

Les méthodes pour déterminer comment mesurer la disponibilité du système sont exposées ici.

3.3.3.2.3Sé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.

3.3.3.2.4Maintenabilité

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).

3.3.3.2.5Portabilité

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.4Description 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.5Annexes

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.

4Annexe : Exemple de cas d’utilisation rédigé

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	5. S vérifie la validité de la carte (Exception B)
	6. S indique la date de retour
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.

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.

Contraintes non fonctionnelles

Type de contrainte	Descriptif
Temps de réponse	Les différentes requêtes doivent prendre moins de 3 secondes
Fréquence	On peut compter une dizaine de consultation de ce type dans une heure de travail de H
Volumétrie	Le nombre de livres est de l’ordre de 100 000 titres. Le nombre d’inscrits à la bibliothèque est de l’ordre de 5000 personnes.
Disponibilité	Cette fonction doit être opérationnelle dans les heures d’ouverture de la bibliothèque
Concurrence	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.
Intégrité	Non spécifique.
Confidentialité	Non spécifique.

Version : 1.1		Nombre de pages :
Référence : referentiel_qualite/DSL.plan_type.doc

UV UMLP

Département ASI – INSA-ROUEN

BP 08 – Avenue de l’Université

76801 SAINT-ETIENNE-DU-ROUVRAY Cedex