23 OPUS - Specifications Fonctionnelles

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

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.

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.

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.

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.

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

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.

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.

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.

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.


23 OPUS - Specifications Fonctionnelles

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

23 OPUS - Specifications Fonctionnelles

Încărcat de

Drepturi de autor:

Formate disponibile

Rédaction du Document de

 Instruction Générale Qualité

Version : 1.1 Nombre de pages : 12

Historique des évolutions

Version Date Auteur Pages/parties Description

Suivi des diffusions

Nom et qualité Date et visa

Version : 1.1 Page : 2

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

Version : 1.1 Page : 3

L’Instruction Générale Qualité de Document de Spécifications Logiciel décrit ce qu’il est

Version : 1.1 Page : 4

L’Instruction Générale Qualité de Document de Spécifications Produit s’applique à tout

Version : 1.1 Page : 5

3.1.1 Objectifs du document

3.1.2 Champ d’application

3.1.3 Organisation du document

3.2 DESCRIPTION GLOBALE

3.2.1 L’environnement du produit

Version : 1.1 Page : 6

3.2.2 Interfaces utilisateur

3.2.2.1 Interfaces matérielles

3.2.2.2 Interfaces logicielles

3.2.2.3 Interfaces de communication

3.2.2.4 Environnement opérationnel

3.2.3 Fonctionnalités du produit.

3.2.4 Profil des utilisateurs.

Version : 1.1 Page : 7

3.2.5 Contraintes de développement

3.2.6 Hypothèses et Dépendances

3.3 SPÉCIFICATIONS DÉTAILLÉES

3.3.1 Cas d’utilisation 1

3.3.1.5 Action Déclencheur

3.3.1.6 Scénario nominal

Version : 1.1 Page : 8

3.3.1.7 Action de fin

3.3.1.9.1 Remarques ergonomiques (éventuellement)

3.3.1.9.2 Contraintes non fonctionnelles (éventuellement)

3.3.2 Cas d’utilisation 2

3.3.3 Contraintes imposées à la conception

3.3.3.1 Conformité aux règles et standards en vigueur chez le client

3.3.3.2 Caractéristiques mesurables exigées

3.3.3.2.1 Sûreté du système

3.3.3.2.2 Disponibilité du système

Version : 1.1 Page : 9

3.4 DESCRIPTION DES FOURNITURES

Version : 1.1 Page : 10

4 ANNEXE : EXEMPLE DE CAS D’UTILISATION RÉDIGÉ

Domaine : Système de gestion d’une bibliothèque

Titre: Emprunter ouvrage.

Version : 1.1 Page : 11

Contraintes non fonctionnelles

Version : 1.1 Page : 12

S-ar putea să vă placă și