La gestion des exigences dans le cadre des développements de logiciels : une mise en place aidée par des référentiels normatifs

IEEE830 et E 1233, le point sur les référentiels de normes permettant de structurer le processus de gestion des exigences dans le cadre des projets de développement logiciel.

Le mot "exigence" est entré dans les glossaires des DSI depuis quelques années. Certains logiciels de gestion des tests ont un onglet Exigences. Certaines organisations sont en cours de réflexion sur ce que sont les exigences, leur utilité et leur mise en place. Certaines ont défini des définitions adaptées à leur contexte et des typologies d'exigences de type sécurité, fonctionnalité, performance et autres en relation avec la norme ISO/IEC 9126. D'autres DSI utilisent des outils de gestion des exigences pour traiter les demandes de leurs clients. D'autres encore voient une différence entre exigences de conception et exigences de tests.

La notion d'exigences n'est pas claire pour tout à chacun et pourtant il existe des normes, par exemple celles de l'IEEE. Ces dernières ne sont pas récentes, 1993 pour l'IEEE830, et ont été développées pour répondre aux problématiques de qualité de l'informatique embarquée. Aujourd'hui, pour accompagner  l'industrialisation de la fabrication des systèmes d'information, nous pouvons appliquer ces normes pour atteindre des niveaux de qualité équivalents.

L'objectif de cet article est d'introduire les concepts de ces référentiels afin d'aider à mettre une gestion des exigences dans une organisation.

Tout d'abord, le terme exigence est la traduction de l'Anglais Requirement. "Exigence" est un terme fort en français et pourrait être traduit plus simplement par "Ce qui est requis". Il s'agit donc de ce qui est requis pour satisfaire le client. Le client lui pouvant être le client final utilisateur du logiciel, ou le service informatique qui exploite le logiciel. Ces exigences peuvent être décomposées en plusieurs catégories et sous catégories tel que le propose la norme ISO 9126 (capacité fonctionnelle, fiabilité, facilité d'utilisation, efficacité, maintenabilité, portabilité). Si ce référentiel ISO est connu, d'autres normes existent également.


Voici deux référentiels de l'IEEE, l'institut des ingénieurs électriciens et électroniciens.

- IEEE 830-1993 : pratique recommandée par IEEE pour la préparation de spécifications d'exigences de logiciel - IEEE 1233-1998 : guide de l'IEEE pour la spécification d'exigences de systèmes.

IEEE830 présente ce qu'il faut pour ne rien oublier dans un document décrivant "les exigences d'un logiciel, d'un programme ou d'un progiciel en particulier, qui exécute certaines fonctions dans un environnement précis".  Ce standard présente ce que devrait contenir une spécification d'exigences de logiciel et ce que sont des exigences bien rédigées et plusieurs plans de documents type. Son objectif est d'aborder les questions fondamentales suivantes:

a) Les fonctions : que doit faire le logiciel ?

b) Les interfaces externes : quelle types de liens doit-il y avoir entre le logiciel et les utilisateurs, le matériel du système, les autres matériels et les autres logiciels?

c) Performance : quelle doit être la vitesse, le degré de disponibilité, le délai de réponse et le délai de récupération des diverses fonctions logicielles, (etc.) ?

d) Attributs : de quoi faut-il tenir compte sur le plan de la transférabilité, de la facilité d'exécution de la maintenance, de la sécurité, etc.?

e) Contraintes imposées sur l'implantation : y a-t-il des contraintes dont il faut tenir compte (normes, langages d'implantation, politiques visant l'intégrité des bases de données, ressources limitées, cadre d'exploitation, etc.) ?

IEE830 est idéal pour ne rien oublier quand on se retrouve à devoir décrire ce que l'on attend d'un logiciel. Les modèles de document proposés sont directement exploitables.

IEEE1233 présente les exigences avec une vision Système Informatique plus que logiciel. Elle prend en compte que les exigences seront modifiées dans le temps, devront prendre en compte les conditions d'intégration, des concepts opérationnels, des contraintes de conception et de configuration technique. Ce guide fait le distinguo entre les exigences de système "ce que le système doit faire", et "comment construire le système", tel qu'un cahier des charges ou plan projet.


"L'un des objectifs principaux de l'analyse des exigences de système étant de garantir qu'elles sont bien comprises. Cette dernière doit être présentée au client dans un langage qu'il est susceptible de comprendre, et qui est complet, concis et clair. Elle doit être également transmise à la communauté technique (MOE, concepteurs, développeurs, testeurs...)."

Au départ, le client a une idée de ce qu'il souhaite. Ce sont les exigences brutes. Cela s'apparente à l'expression des besoins ou se mêlent des éléments précis avec des idées de conception.

Puis en fonction des interfaces externes du système (transmissions de données, interfaces entre logiciels, IHM....), de l'environnement, de facteurs organisationnels, commerciaux, le système de gestion des exigences est créé.

Il comporte des "exigences bien formées" : une exigence bien formée énonce la fonctionnalité (capacité) d'un système. Elle doit pouvoir être validée et être remplie ou possédée par ce système pour résoudre le problème du client ou pour réaliser l'un de ses objectifs. Cette exigence doit être caractérisée par des conditions mesurables et limitée par des contraintes.

Exemple :

Exigence : Permettre aux clients d'une banque de faire un virement vers d'autres comptes de cette même banque à effet immédiat.

Capacité : Permettre au client de faire des virements

Condition : à effet immédiat  (cela doit être mesurable)

Contrainte : à des clients de la même banque


Une exigence bien formée doit être :

- Abstraite : elle doit être indépendante de la méthode de mise en oeuvre

- Non ambiguë : elle doit être énoncée de manière à n'être interprétable que d'une seule manière

- Traçable : il doit être possible d'établir une relation entre la déclaration précise des besoins du client documentée et les énoncés spécifiques de la définition du système inclus dans la SES. Cette relation indique ainsi la source de l'exigence

- Testable/Validable : elle doit offrir un moyen de prouver que le système satisfait à son énoncé.


Pour permettre leur analyse, les exigences doivent être catégorisées selon leur identification, priorité, criticité, faisabilité, risque, source et type. La notion de type dans la norme est exhaustive. Le type peut être basé par exemple sur des qualités attendues (fiabilité, maintenabilité, sécurité, performance, ergonomie...),  ou autres.

Une fois les exigences bien formées écrites, un système de gestion d'exigences sera créé et pourra être présenté différemment suivant que le destinataire est le client ou la communauté technique.

Pour cela, il est possible de s'appuyer sur des logiciels du marché ou des Open Source dont GENSPEC.


Ces deux référentiels IEEE sont complémentaires et ont des propriétés similaires :

IEEE830 Caractéristique                     IEEE 1233 1998
d'une spécification d'exigences       - Propriétés d'un recueil
de système                                             d'exigences

Exacte                                                   Ensemble unique
Non ambiguë                                          Normalisé
Complète                                               Ensemble lié
Cohérente                                              Complet

Hiérarchisée en fonction                          Homogène
de l'importance
et/ou de la stabilité
   
Vérifiable                                                  Limité
Modifiable                                                 Modifiable
Traçable                                                   Configurable
                                                                Granulaire
 

Les exigences vues du testeur

D'un point de vue testeur de logiciel, il est important de pouvoir identifier les impacts d'une modification du besoin client sur les tests. Ce qui est intéressant de savoir concernant la qualité d'un système en tests est la couverture des exigences suivant leur criticité. Ces exigences de conception et les  exigences de test sont en fait les mêmes et sont testées à différents niveaux ou phases de tests. Dès lors les exigences peuvent être représentées sous la forme d'arborescences.

Au premier niveau, les exigences qui seront testées au niveau métier et qui valideront le besoin utilisateur, dont le bout en bout ou tests de flux. Comme le besoin utilisateur a été traduit en exigences plus fines par les concepteurs, celles-ci seront au second niveau, et qualifiées en tests systèmes tout comme les exigences d'architecture. Finalement le niveau le plus bas verra  des exigences qui pourront être validées en tests unitaires. Le système sera validé au fur et à mesure de l'exécution des tests couvrant les exigences du plus bas niveau au plus haut.

Par exemple :

Le client effectue un virement à effet immédiat vers un client de sa banque

L'application fait un appel au webservice SA_Virement

Un écran propose la saisie d'un virement

Sélection du compte d'origine

- Le compte est sélectionné dans une boite liste

- Le champ de saisie du montant  accepte deux décimales maximum

- Le champ de saisie du montant  est obligatoire

Sélection du compte destinataire

Modification du virement

Suppression du virement


Conclusion

La notion d'exigence se réfère donc à une représentation, écriture du besoin du client et de la conception, dont les règles de gestion. Elle permet de mieux communiquer car les phrases sont classées, simples et mesurables. Les informations sont non redondantes. Le travail du testeur est simplifié car les exigences sont directement testables. Le test vise à couvrir ces exigences en les vérifiant.

Tous les acteurs du projet utilisent les mêmes exigences, MOA, concepteur, développeur, testeur, ce qui évite les manques et les incompréhensions.

L'ingénierie des exigences est un secteur en plein développement et le besoin de formations se vérifie par le besoin de reconnaissance dans le domaine. Celles-ci peuvent être validées aujourd'hui par les certifications individuelles REQB et IREB.