MODULE No 20

Titre : IEEE 830

But : Consolider les connaissances par rapport à la spécification des exigences logicielles

Antécédents : Module 16

Corps :

Dans le module 16 nous avons vu que lors de la spécification des exigences il faut : « Choisir un gabarit pour les documents. Par exemple en partant de l’une des tables de matières de la norme IEEE 830-1998. »

Dans ce module nous allons analyser brièvement la norme :

Présentation IEEE 830

Attributs

Pour chaque attribut d’une SEL défini dans la norme IEEE 830 et que nous avons synthétisé dans Présentation IEEE 830, nous présentons quelques commentaires utiles pour la réalisation du TP2.

Correcte.

Pour savoir si une SEL est correcte (c-a-d : chaque exigence décrite dans la SEL doit être satisfaite par le logiciel) il faut la valider par rapport aux besoins initiaux. Une SEL « parfaite » par rapport aux autres attributs de qualité et incorrecte est très dangereuse : tout est parfait mais… ce n’est pas cela que le client veut ! Il faut donc valider la SEL par rapport aux besoins du client/utilisateur, besoins qui devraient avoir été décrits dans d’autres documents. Il faut aussi considérer que, souvent, il y a des besoins implicites qui n’ont pas été décrits mais qu’il faut satisfaire. Définir dans une SEL des besoins implicites est une tâche qui n’est jamais simple.

Non ambiguë

Si la description est en langue naturelle il y aura toujours des ambiguïtés même si on respecte les règles d’écriture qu’on a vues dans un autre cours. La modélisation conceptuelle, les définitions, la structuration avec les fiches favorisent la création d’une SEL qui ne soit pas « trop » ambiguë. Pour avoir une SEL totalement non ambiguë il faut une spécification avec une langue formelle (mathématique).

Complète

Pour savoir si une SEL est complète il faut s’assurer :

· Qu’aucun élément dans la table des matières normalisée n’est absent.

· Qu’aucun champ obligatoire des fiches n’est absent.

· Que les listes des tableaux et des figures sont présentes.

· Que la table des matières et l’index sont présents.

· Que la page titre et l’historique est présente.

Cohérente

Comme on l’a vu dans un des premiers cours, on peut accepter des exigences en conflit pourvu que les fiches des exigences contradictoires soient mises en relation via le champ « conflit ».

Catégorisée

La catégorisation est importante pour la gestion de projet. Les champs « stabilité », « nécessité » et « priorité » ont été introduits dans les fiches pour favoriser la catégorisation. Il y a aussi un autre genre de catégorisation très important : groupement des exigences en exigences fonctionnelles et de qualité. Groupement qui est représenté dans le champ « Type » des fiches des exigences.

Vérifiable

Pour qu’une exigence soit vérifiable il faut qu’elle soit non ambiguë. Dans les fiches le champ « test » renvoie vers une fiche de test qui contient une suite de pas pour tester l’exigence. Si l’on est incapable d’écrire la procédure de test alors l’exigence n’est pas vérifiable. Dans votre TP le champ « Test » doit contenir un renvoi (fictif car vous n’écrivez pas les cas à tester) vers la fiche de test. Fiche de test qui devrait avoir le même nom de la fiche des exigences avec un préfixe T_.

Modifiable

Toute redondance crée une SEL non modifiable car un changement dans une section pourrait causer des incohérences qui ne sont pas des « vrais » conflits mais des conflits « artificiels » dus à des inattentions dans la modification. Ne pas être redondant, par exemple, implique qu’un objet qui est un intrant d’une fonction ne doit pas être redéfini dans la fiche de l’exigence. Cette dernière doit contenir un simple renvoi vers le modèle conceptuel.

Traçable

La traçabilité est fondamentale pour faciliter la maintenance du logiciel. La fiche des exigences contient :

· un champ pour la traçabilité vers l’arrière (origine). À remplir dans votre TP

· deux champs pour la traçabilité en avant :

o vers des exigences plus détaillées (Dérivées). À remplir dans votre TP

o vers la conception (Ec : élément de conception). Vide dans votre TP

· un champ pour la traçabilité vers d’autres éléments d’analyse (Ea)

Chapitre description générale

• Mise en perspective

Dans cette section il faut situer le produit pas rapport à d’autres produits. Il faut pouvoir répondre à des questions du genre : est-ce que le produit fait partie d’un autre produit ? fait-il partie d’une famille de produit ? le produit est-il « seul » ?

• Synthèse des fonctions

Liste des exigences fonctionnelles. Un tableau avec identificateur, titre (renvoi éventuel vers la fiche) et but

• Caractéristiques des utilisateurs (fiches)

Mettre les fiches des rôles.

• Contraintes

Contraintes de conception. Type de OS de BD… tout ce que l’on veut imposer aux concepteurs.

• 3.5 Hypothèses

Les hypothèses sur lesquelles est fondée la SEL. Si les hypothèses ne sont plus vraies alors le document pourrait ne plus être valide.

Conséquents :

· Des points de repère pour l’emploi de la norme

· Le remplissage des fiches des exigences est facilité

Note :