MODULE No 16

Titre : Exigences ?

But : Fixer un cadre terminologique pour les exigences.

Antécédents : Avoir terminé le TP1

Corps :

La norme ISO 12207 est un cadre de référence pour les processus en GL : elle présente une terminologie et une structuration des activités pour la création d’un logiciel. Nous allons continuer dans la même approche mais avec quelques autres éléments.

Dans le cadre de notre cours où l’on n’aborde que la partie de compréhension et de spécification de ce que les parties prenantes veulent (le « quoi », les exigences) il est fondamental de nous entendre sur ce qu’est une exigence. Voici les deux définitions de la norme IEEE Std. 610.12 :

1. Une condition ou une capacité dont un utilisateur a besoin pour résoudre un problème ou atteindre un objectif.

2. Une condition qui doit être satisfaite ou une capacité que doit être possédée par un système ou par un composant d’un système pour satisfaire un contrat, un standard, une spécification, ou d’autres documents officiels.

Donc une exigence est quelque chose que l’on « attend impérativement » de la machine que l’on doit construire (surtout logiciel en ce qui nous concerne).

Ces définitions, comme toutes les définitions, ont une certaine utilité théorique et sont un moyen pour ne pas trop s’éloigner du sujet. Mais, si on veut quelque chose de vraiment utile pour un travail technique, il faut « creuser » les définitions, les structurer et donner des méthodes qui montrent comment, dans le travail concret, on peut réaliser ce que la définition nous indique.

S’il y a une chose que l’on a appris en quarante ans de GL, c’est bien que, pour diminuer les risques d’avoir un produit final qui ne satisfait pas les parties prenantes (et, en particulier, les utilisateurs), il faut que dans le développement des exigences on n’oublie aucune de ces quatre activités :

1. Élicitation des exigences : il s’agit d’une activité fondée sur l’écoute et qui permet de connaître ce dont les parties prenantes ont besoin. On a déjà parlé plusieurs fois d’élicitation dans le cours.

2. Analyse des exigences : il s’agit d’analyser les exigences pour les structurer, pour voir s’il est possible de les réaliser (faisabilité), pour donner des priorités. À ce propos vous avez vu les éléments des fiches des exigences dans votre TP1 qui favorise l’analyse : champs, Der, Sta, Nec, Pri, Ea…

3. Spécification des exigences : il s’agit de décrire le plus formellement possible, dans des artefacts officiels (documents et/ou prototypes), les exigences élicitées et analysées.

4. Validation des exigences : il s’agit de s’assurer que les exigences spécifiées sont bien les exigences que la machine doit aider à satisfaire.

Note Cette structuration du développement des exigences facilite sans doute la vie, mais elle n’est pas très utile si on ne « touche » pas à ce que cela implique. C’est afin d’apprendre via la pratique que dans le cours nous faisons le TP en classe. Fin de la note

Dans la suite du module nous allons détailler les quatre activités, sans aucune prétention d’être exhaustifs.

Élicitation des exigences :

1. Identifier les classes d’utilisateurs (consignées ensuite dans des fiches des rôles, par exemple). Ceci est fondamentale pour :
1. Savoir à qui s’adresser et comment s’adresser ;
2. Définir l’interface personne machine ;
3. Avoir différents points de vue ;
4. Prendre en considération les caractéristiques personnelles
2. Choisir un représentant pour chaque classe d’utilisateurs. Pour rendre plus efficace le travail. Cela peut avoir des effets pervers si le représentant (Champion) ne présente que sa vision personnelle : nous seront satisfaits mais les autres utilisateurs pourraient refuser le produit.
3. Observer les utilisateurs travailler. Il faut que la présence de l’observateur dérange le moins possible les utilisateurs (caméra cachée… si le syndicat le permet).
4. Travailler avec les utilisateurs. Un approfondissement de 3). Éventuellement en créant un prototype.
5. Extraire les concepts du domaine. En partant :
1. de documents déjà existants,
2. de discussions avec les parties prenantes,
3. de l’observation du travail.
6. Définir les frontières (les interfaces) du système (de la machine) à construire. En définissant : les événements, les « messages » envoyés au système et les réponses de celui-ci.
7. Définir la portée du projet. Histoire de ne pas vouloir régler tous les problèmes du client (ou de l’humanité !).

Analyse des exigences :

1. Mettre des priorités. Un champ est prévu dans les fiches. Il faut une participation de toutes les parties prenantes.
2. Établir la nécessité. Un champ est prévu dans les fiches. Il faut une participation de toutes les parties prenantes.
3. Établir la stabilité. Un champ est prévu dans les fiches. Il faut une participation de toutes les parties prenantes.
4. Structurer les exigences. Lorsque les exigences sont complexes il faut les subdiviser.
5. Assigner les exigences. Assigner les exigences aux différents sous-systèmes (s’ils existent)

Spécification des exigences :

1. Choisir une notation. Par exemple UML. Comme dans notre cas
2. Choisir un gabarit pour les documents. Par exemple en partant de l’une des tables de matières de la norme IEEE 830-1998. Comme dans notre cas.
3. Choisir un moyen pour la traçabilité. Fixer la façon pour suivre les changements et faciliter ainsi la maintenance. Les fiches dans notre cas.
4. Écrire les documents.

Validation des exigences :

1. Inspection et revues officielles. Elles font parties des processus auxiliaires de la norme ISO 12207.
2. Spécification des tests. Tâche importante car le logiciel qui met en œuvre l’exigence doit pouvoir être testé : ceci est particulièrement important pour les exigences de qualité (on non fonctionnelles).

Note Tout cela peut sembler très théorique, et en effet sans du travail concret cela ne sert pas à grande chose. Pour vraiment l’assimiler vous devez donc essayer de « lier » tous ces concepts à votre travail concret dans le TP2 Fin de la note

Conséquent : Avoir un cadre terminologique qui permet de situer les activités pratiques liées aux exigences.

Note :