Le mot « exigence » est entré dans les glossaires des DSI depuis quelques années. Certaines sont en cours de réflexion sur le sujet. Certaines ont défini des définitions adaptées à leur contexte et des typologies d’exigences 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. Il est clair que la notion d’exigences n’est pas claire pour tout à chacun et pourtant il existe des normes, par exemple :
– IEEE 830-1993 : Pratique recommandée par IEEE pour la préparation de spécifications d’exigences de logiciel, et
– IEEE 1233-1998 : Guide de l’IEEE pour la Spécification d’Exigences de Systèmes.
Les normes
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 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.)? »
IEEE1233 présente les exigences avec une vision cycle de vie. Elles 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 que la SES est bien comprise, 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’apparent à l’expression des besoins ou se mêlent des éléments précis, 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
Attributs d’une bonne exigence
Une bonne exigence 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 leurs 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.
La norme IEEE1233 est d’un rang de niveau supérieur (orientée client) à la norme IEEE830 orientée conception. Néanmoins ces deux ont des exigences similaires :
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 eixgences suivant leur criticité. Ces exigences de conception et de exigences de test sont en fait les mêmes et sont testsé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 a effet immédiat vers un client de la 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 champs de saisie du montant accepte deux décimales maximum
– Le champs de saisie du montant est obligatoire
– Sélection du compte destinataire
………….
………….
Modification du virement
Suppression du virement
….
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.
Tous les acteurs du projet utilisent les même 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 certiifcations individuelles REQB et IREB.
En conséquence, le CFTL développe le syllabus REQB Requirement Qualification Board et en propose la certification Fondation.
