Vous êtes sur la page 1sur 12

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é
76801 SAINT-ETIENNE-DU-ROUVRAY Cedex
Rédaction du Document de Spécifications Logiciel

Page de service

Historique des évolutions

Version Date Auteur Pages/parties Description


modifiées
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 : le :
FBA

Vérificateur : le :
FFI

Approbateur : le :

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

Version : 1.1 Page : 2


Référence referentiel_qualite/DSL.plan_type.doc
Rédaction du Document de Spécifications Logiciel

SOMMAIRE

Sommaire.........................................................................................................3

1 Introduction................................................................................................4

2 Domaines d’application..............................................................................5

3 Contenu du DSL........................................................................................6
3.1 Introduction..............................................................................................................6
3.1.1 Objectifs du document.....................................................................................6
3.1.2 Champ d’application.........................................................................................6
3.1.3 Organisation du document...............................................................................6
3.2 Description globale..................................................................................................6
3.2.1 L’environnement du produit..............................................................................6
3.2.2 Interfaces utilisateur.........................................................................................7
3.2.3 Fonctionnalités du produit................................................................................7
3.2.4 Profil des utilisateurs........................................................................................7
3.2.5 Contraintes de développement........................................................................8
3.2.6 Hypothèses et Dépendances...........................................................................8
3.3 Spécifications détaillées..........................................................................................8
3.3.1 Cas d’utilisation 1.............................................................................................8
3.3.2 Cas d’utilisation 2.............................................................................................9
3.3.3 Contraintes imposées à la conception.............................................................9
3.4 Description des fournitures....................................................................................10
3.5 Annexes.................................................................................................................10

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

Version : 1.1 Page : 3


Référence referentiel_qualite/DSL.plan_type.doc
Rédaction du Document de Spécifications Logiciel

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


Référence referentiel_qualite/DSL.plan_type.doc
Rédaction du Document de Spécifications Logiciel

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


Référence referentiel_qualite/DSL.plan_type.doc
Rédaction du Document de Spécifications Logiciel

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.

3.1.1 Objectifs du document


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

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

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

3.2.1 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


Référence referentiel_qualite/DSL.plan_type.doc
Rédaction du Document de Spécifications Logiciel

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.

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

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

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

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

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

3.2.4 Profil des utilisateurs.


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

Version : 1.1 Page : 7


Référence referentiel_qualite/DSL.plan_type.doc
Rédaction du Document de Spécifications Logiciel

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

3.2.6 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 SPÉ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.1 Cas d’utilisation 1


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

3.3.1.1 Titre

3.3.1.2 Résumé

3.3.1.3 Acteurs

3.3.1.4 Pré-condition(s)

3.3.1.5 Action Déclencheur

3.3.1.6 Scénario nominal


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

Version : 1.1 Page : 8


Référence referentiel_qualite/DSL.plan_type.doc
Rédaction du Document de Spécifications Logiciel

3.3.1.7 Action de fin

3.3.1.8 Post-condition(s)

3.3.1.9 Exceptions

3.3.1.9.1 Remarques ergonomiques (éventuellement)

3.3.1.9.2 Contraintes non fonctionnelles (éventuellement)

3.3.2 Cas d’utilisation 2


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

3.3.3 Contraintes imposées à la conception

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

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

3.3.3.2.1 Sû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.2 Disponibilité du système


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

3.3.3.2.3 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


Référence referentiel_qualite/DSL.plan_type.doc
Rédaction du Document de Spécifications Logiciel

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

3.3.3.2.5 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


Référence referentiel_qualite/DSL.plan_type.doc
Rédaction du Document de Spécifications Logiciel

4 ANNEXE : 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 5. S vérifie la validité de la carte (Exception
bibliothèque 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.

Version : 1.1 Page : 11


Référence referentiel_qualite/DSL.plan_type.doc
Rédaction du Document de Spécifications Logiciel

Contraintes non fonctionnelles

Type de Descriptif
contrainte
Temps de Les différentes requêtes doivent prendre moins de 3 secondes
réponse
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 Page : 12


Référence referentiel_qualite/DSL.plan_type.doc