Exigence systme

Vos projets informatiques respectent trop rarement lenveloppe budgtaire alloue initialement ? Leur planning drape systmatiquement ? Chaque membre de lquipe projet se justifie en accusant lautre dtre responsable de la situation ? Cette problmatique, malheureusement trop courante, est gnre par plusieurs facteurs : Manque dimplication des utilisateurs, dfaut de sponsoring des directions associes, Cette problmatique, malheureusement trop courante, est gnre par plusieurs facteurs :

Manque dimplication des utilisateurs, Dfaut de sponsoring des directions associes, Mauvais nonc des besoins

Le dfaut le plus rpandu est une mauvaise prise en compte des besoins. Une bonne pratique simple, appele Ingnierie des Exigences , permet de fdrer lquipe projet et de sassurer de lexactitude et de la compltude des besoins. Lexprience prouve quune communication efficace allie lIngnierie des Exigences ds la phase amont dun projet est un facteur de succs incontestable. En ingnierie, et plus particulirement dans les procdures d'appel d'offres publiques et prives, les exigences sont l'expression d'un besoin document (Le besoin recouvre l'ensemble de tout ce qui apparat tre ncessaire un tre, que cette ncessit soit consciente ou non) sur ce qu'un produit ou un service particulier devrait tre fait. Elles sont le plus souvent utilises dans un sens et dsigne le contenu conceptuel d'une expression formelle dans l'ingnierie des systmes (L'ingnierie des systmes est une approche scientifique interdisciplinaire de formation rcente, dont le but est de formaliser et d'apprhender la conception (la conception est un processus de cration, de dessin ou de projet, plus spcifiquement dans le cadre de produits matriels ou immatriels) de systmes complexes avec succs et dans l'ingnierie logicielle. Le terme exigence est la traduction de l'Anglais Requirement. "Exigence" 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. Dans l'approche classique de l'ingnierie, les exigences sont considres comme des pr-requis pour les tapes de conception et de dveloppement d'un produit. Dfinition du terme exigence (requis)? Les exigences (requis) dcrivent la raison dtre dun systme.
1

 Les exigences expriment les ides qui doivent tre incarnes dans un systme ou une application en dveloppement. La dfinition varie, mais reste gnralement autour de ces lignes.

Selon la norme IEEE 830-1993 Une exigence est dfinie comme tant : une condition ou capacit dont un utilisateur a besoin pour rsoudre un problme ou atteindre un objectif ; une condition ou capacit qui doit tre satisfaite ou possde par un systme pour satisfaire un contrat, une norme, une spcification, ou tout autre document formellement impos. La phase de dveloppement des exigences peut avoir t prcde par une tude de faisabilit, ou une phase d'analyse conceptuelle du projet. La phase d'exigences peut tre dcompose en : Mettre jour les exigences: rassembler les exigences des parties prenantes; Analyser : vrifier la cohrence et l'exhaustivit ; Dfinir: crire les exigences sous une forme aisment comprhensible pour les utilisateurs et les dveloppeurs ; Spcifier: crer une interaction initiale entre les exigences et la conception. Les diffrents processus des exigences sont : Phase de cration : Dbute le processus (Vision, besoin ou opportunit daffaire, bonne ide). Dossier commercial, tude de faisabilit, tendue du systme, risques, etc. ; licitation des exigences : Les exigences sont dcouvertes en consultant (et parfois mme en provoquant) les diverses parties prenantes. Analyse des exigences et ngociation : Les exigences sont analyses et les conflits rsolus, souvent par ngociation ; Spcification des exigences : Un document prcis dcrivant les exigences est produit ; Validation des exigences : La spcification des exigences est vrifie en termes de cohrence et de compltude. Les parties prenantes : Personnes physiques et organisations concernes directement ou indirectement par le futur systme ; Clients / investisseur ; Acheteurs ;
2

Utilisateur final ; Experts du domaine ; Les fournisseurs de contenu ; Dveloppeurs, Ingnieurs logiciel, gestionnaires de projet, ; Inspecteurs ; Experts dun autre systme en liaison avec le projet ; Tout autre personne qui apporte une valeur ajoute au futur systme.

Les Parties prenantes intresses : Management MOA ; utilisateurs directs, reprsentants de futurs clients (marketing, associations) ; Personnes concernes par le systme (ventes, actionnaires, ) ; Oprateurs exploitants.

OBJECTIFS
Connatre les enjeux relis la comprhension du domaine ; Comprendre la problmatique des exigences et des spcifications des systmes contemporains ; Connatre les principales normes relies aux exigences logicielles ; Connatre les principales pratiques dans le domaine ; Rdaction dun document de concepts doprations ; Rdaction de documents d'exigences et de spcification ; Rendre les tudiants aptes raliser des documents d'exigences ; Sensibiliser les tudiants aux activits postrieures aux exigences. Les exigences abordent 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 matriel du systme, les autres matriels et les autres logiciels c) Performance : quelle doit tre la vitesse, le degr de disponibilit, le dlai de rponse et le dlai de rcupration des diverses fonctions logicielles, (etc.) ? d) Attributs : de quoi faut-il tenir compte sur le plan de la transfrabilit, de la facilit d'excution de la maintenance, de la scurit, etc.? e) Contraintes imposes sur l'implantation : y a-t-il des contraintes dont il faut tenir compte (normes, langages d'implantation, politiques visant l'intgrit des bases de donnes, ressources limites, cadre d'exploitation, etc.) ? L'un des objectifs principaux de l'analyse des exigences de systme tant de garantir qu'elles sont bien comprises. Cette dernire doit tre prsente au
3

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, dveloppeurs, testeurs...). Au dpart, le client a une ide de ce qu'il souhaite. Ce sont les exigences brutes. Cela s'apparente l'expression des besoins ou se mlent des lments prcis avec des ides de conception. Puis en fonction des interfaces externes du systme (transmissions de donnes, interfaces entre logiciels....), de l'environnement, de facteurs organisationnels, commerciaux, le systme de gestion des exigences est cr. Il comporte des "exigences bien formes" : une exigence bien forme nonce la fonctionnalit (capacit) d'un systme. Elle doit pouvoir tre valide et tre remplie ou possde par ce systme pour rsoudre le problme du client ou pour raliser l'un de ses objectifs. Cette exigence doit tre caractrise par des conditions mesurables et limite par des contraintes. Les premires phases dun projet sont primordiales pour anticiper son succs. Beaucoup dquipes se lancent demble dans du dveloppement applicatif avant davoir compltement saisi les enjeux du projet, de les avoir partags, et davoir pass en revue lensemble des besoins. Le rsultat vident est une solution qui nest pas en adquation avec les vritables besoins des utilisateurs. De mme, si les membres de lquipe projet ont lhabitude de documenter les phases amont par un cahier des charges ou des spcifications, ces livrables respectent rarement un standard exploitable. Pourtant, la qualit de ces livrables est dautant plus importante que la relation entre les protagonistes est contractuelle, ie si les acteurs qui ralisent sont prestataires de lquipe formalisant les besoins (ex : cas dun appel doffres). Par ailleurs, leffort pass rdiger une documentation exploitable ne doit pas figer des processus mtiers dont la valeur ajoute pour lentreprise provient de leur pragmatisme. Comment, dans ce cas, russir et maintenir jour linventaire des besoins ?

METHODOLOGIE DE LINGENIERIE DES EXIGENCES Une exigence logicielle est lexpression formalise dun besoin mis par le ou les mtiers qui utiliseront le futur systme. Elle dcrit soit le produit, soit le service rendu par le systme. En phase amont de la conception dun systme dinformation, on qualifie de Spcification des Exigences Logicielles (SEL) le livrable correspondant aux SFD classiques, bas sur lutilisation dexigences.
4

LIngnierie des Exigences est une mthode permettant lensemble des parties prenantes dun projet informatique de saccorder sur lensemble des besoins auxquels devra rpondre le systme construire. Cette approche systmatique et rigoureuse est base sur la spcification et la gestion des exigences permettant :

de connaitre les besoins pertinents du mtier, datteindre un consensus entre les parties prenantes sur ces besoins, de les formaliser en respectant une normalisation, et de les tracer tout au long du projet, de comprendre et de formaliser les demandes des parties prenantes et leurs besoins, de spcifier et de grer les exigences pour minimiser le risque de livrer un systme ne rpondant pas aux attentes des parties prenantes

Processus de dveloppement des exigences Le dveloppement des exigences sinscrit dans une srie de quatre tapes :

llicitation ou collecte du besoin, lanalyse ou formalisation des exigences selon des rgles prcises, spcification : le business analyst doit sassurer de la cohrence globale et de lexhaustivit des besoins, la validation : plusieurs approches permettent de contractualiser les besoins entre les parties prenantes.

La valeur ajoute de lingnierie des exigences consiste transformer un besoin brut mis en un livrable clair et complet. Les exigences peuvent tre types, priorises et restent modifiables et traables tout au long du projet.

Traabilit des exigences selon le cycle en V

INTERETS DE LA METHODE
Lorsque lquipe projet est scinde en deux points de vue priori opposs MOA vs MOE , cette mthode est trs utile. De mme, dans le cas dun SI dont les utilisateurs appartiennent des mtiers distincts, le pilotage du projet par les exigences facilite la validation de la cohrence globale du SI. Cette approche peut galement tre mise en uvre dans le cadre dun projet agile, les exigences tant dcoupes en domaines fonctionnels indpendants les uns des autres.

Une exigence bien forme doit tre :

o Abstraite : elle doit tre indpendante de la mthode de mise en uvre ; o Non ambigu : elle doit tre nonce de manire n'tre interprtable que d'une seule manire ;

o Traable : il doit tre possible d'tablir une relation entre la dclaration prcise des besoins du client documente et les noncs spcifiques de la dfinition du systme. Cette relation indique ainsi la source de l'exigence. o Testable/Validable : elle doit offrir un moyen de prouver que le systme satisfait son nonc.

Pour permettre leur analyse, les exigences doivent tre catgorises 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 qualits attendues (fiabilit, maintenabilit, scurit, performance, ergonomie (tude des conditions de travail et des relations entre lhomme et la machine)...). Une fois les exigences bien formes crites, un systme de gestion d'exigences sera cr et pourra tre prsent diffremment suivant que le destinataire est le client ou la communaut technique.

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 intressant de savoir concernant la qualit d'un systme en tests est la couverture des exigences suivant leur criticit. Ces exigences de conception et les exigences de test sont en fait les mmes et sont testes diffrents niveaux ou phases de tests. Ds lors les exigences peuvent tre reprsentes sous la forme d'arborescences.

Au premier niveau, les exigences qui seront testes au niveau mtier 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, cellesci seront au second niveau, et qualifies en tests systmes tout comme les exigences d'architecture. Finalement le niveau le plus bas verra des exigences qui pourront tre valides en tests unitaires. Le systme sera valid au fur et mesure de l'excution des tests couvrant les exigences du plus bas niveau au plus haut. Par exemple :
7

Le client effectue un virement effet immdiat vers un client de sa banque L'application fait un appel au webservice SA_Virement Un cran propose la saisie d'un virement Slection du compte d'origine - Le compte est slectionn dans une boite ou liste ; - Le champ de saisie du montant accepte deux dcimales maximum ; - Le champ de saisie du montant est obligatoire. Slection du compte destinataire : Modification du virement ; Suppression du virement.

Conclusion
La notion d'exigence se rfre donc une reprsentation, criture du besoin du client et de la conception, dont les rgles de gestion sont dfinies. Elle permet de mieux communiquer car les phrases sont classes, 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 vrifiant. Tous les acteurs du projet utilisent les mmes exigences, MOA, concepteur, dveloppeur, testeur, ce qui vite les manques et les incomprhensions. LES DIFFERENTES SORTE DEXIGENCES Les projets sont soumis trois sortes d'exigences : Les exigences mtiers qui dcrivent le quoi dans les termes du mtier. Elles dcrivent ce qui doit tre fourni ou ralis pour produire le systme logiciel ; Les exigences produits qui dcrivent le produit ou le systme un haut niveau. Elles rpondent aux exigences mtier et sont couramment formules comme les fonctionnalits que le systme doit raliser. On les appelle galement exigences fonctionnelles ou spcifications fonctionnelles ; Les exigences de processus qui dcrivent le comment. Ces exigences prescrivent les processus que l'on doit suivre et les contraintes auxquelles on doit se conformer pour la ralisation du systme. Dans ce cas, on

trouve par exemple des exigences de scurit, d'assurance qualit, ou de management. Les exigences produits et de processus sont lies. Les exigences de processus sont souvent imposes pour atteindre les exigences produits de haut niveau. A ces exigences produit sajoutent galement les exigences mtier (qui dcrivent le quoi ) et les exigences processus (qui dcrivent le comment , cest dire les contraintes). Lensemble des exigences dfinit les caractristiques exiges/dsires pour le systme/logiciel. La gestion des exigences consiste grer les exigences hirarchises d'un projet, dtecter les incohrences entre elles et assurer leur traabilit. Par exemple un cot maximum de dveloppement (qui est une exigence de processus) peut tre impos afin d'atteindre une exigence sur le prix de vente minimum (qui est une exigence produit). Une exigence de maintenabilit du produit (exigence produit) est souvent accompagne d'exigences de suivre un certain style de programmation (exigence de processus) telles que la programmation oriente objet, les motifs de conception. NB : Les trois types d'exigences sont vitales pour tout dveloppement de systme. La problmatique MOA = Matre douvrage (ou matrise douvrage). Cest linitiateur du projet. Il est donc le reprsentant des utilisateurs finaux qui louvrage est destin. MOE = Matre duvre (ou matrise duvre). Cest lentit retenue pour raliser louvrage Le MOA est client du MOE qui il passe commande dun produit ncessaire son activit. Gnralement le MOA recueille lexpression des besoins de lutilisateur et rdige des spcifications fonctionnelles et un cahier des charges destination du MOE. Le MOE fournit ce produit ; soit il le ralise lui-mme, soit il passe commande un ou plusieurs fournisseurs qui laborent le produit sous sa direction. Il peut galement parfois y avoir des intermdiaires entre MOE et MOA. Quelques facteurs pour une bonne dfinition des exigences Dans l'ingnierie systme/logiciel, une exigence est gnralement la description de ce que le systme/logiciel livr doit tre capable de faire (exigence fonctionnelle). A cela, il faut aussi ajouter les exigences non fonctionnelles , portant sur la manire dont le systme/logiciel doit excuter ses fonctions ou encore les exigences de performance , les exigences de qualit de service , etc.
9

Les exigences sont classes gnralement en trois catgories : 1) Exigences fonctionnelles - Elles dcrivent les caractristiques du systme ou des processus que le systme doit excuter. Une exigence fonctionnelle est une exigence dfinissant une fonction du systme dvelopper ou est une exigence dfinissant une fonction du systme dvelopper. Ce que le systme doit faire. Dcrit le quoi, c.--d. ce que le systme doit faire. On trouve dans cette catgorie les rgles mtier, et les exigences fonctionnelles de scurit informatique (confidentialit,...) ; Exemples dexigences fonctionnelles : Lutilisateur doit tre capable de chercher dans lensemble des bases de donnes des informations. Le systme doit enregistrer la commande du client. Chaque commande doit avoir un identifiant unique (ORDER_ID). 2) Exigences non fonctionnelles - Elles dcrivent les proprits que le systme doit avoir ; elle caractrise une proprit ou une qualit dsire du systme telle que sa performance, sa robustesse, sa convivialit, sa maintenabilit, etc. ou est une exigence qui caractrise une proprit (qualit) dsire du systme telle que sa performance, sa robustesse, sa convivialit, sa maintenabilit, etc. par exemple les exigences techniques de scurit informatique (confidentialit, intgrit, disponibilit), de performance, d'accessibilit, selon des critres dfinis ; Les exigences non-fonctionnelles peuvent tre difficiles spcifier de manire prcise, et ces exigences ambiges deviennent difficiles vrifier. Un but offre une intention ou un objectif gnral tel que la convivialit de lapplication. Les buts peuvent guider la dcouverte dexigences non-fonctionnelles vrifiables, qui peuvent tre testes objectivement. Contraintes - Les limites du dveloppement en quelque sorte: comme dfinir un systme d'exploitation sur lequel le systme doit fonctionner, ou dfinir quel langage de programmation doit tre utilis pour mettre en uvre le systme. Une contrainte est une restriction sur une ou plusieurs valeurs dune partie du systme ou de tout le systme. Un but est un objectif ou une proccupation utilis pour dcouvrir et valuer des exigences fonctionnelles et non fonctionnelles. Exigences non-fonctionnelles
10

 Lutilit dun systme logiciel est dtermine par ses exigences fonctionnelles et ses caractristiques non-fonctionnelles ; Lensemble des fonctionnalits nest pas utilisable sans certaines caractristiques non fonctionnelles ; Doivent tre vrifiables ; Sinon, elles ne sont que des buts ; Catgorie lie lusage, lefficacit, la fiabilit, la maintenance et la rutilisation ; Objectifs Exigences Non-Fonctionnelles : tre en mesure de comprendre les exigences Non-Fonctionnelles (ENF) et leur importance sur les dcisions architecturales ; Identifier les problmes de dfinition, classification et reprsentation des ENF ; Explorer les diffrentes approches de caractrisation des ENF ; Dcouvrir quelques exemples ; Comprendre la gestion des ENF. Les exigences sont notoirement difficiles prsenter un niveau idal. Souvent, des experts sont employs pour tablir la relation entre les utilisateurs et les dveloppeurs. Ces experts sont en principe capables d'exprimer des exigences fonctionnelles d'une faon qui soit facilement interprtable dans les caractristiques de conception du systme, et de plus comprhensible par les utilisateurs finaux. Exemples dexigences fonctionnelles Lutilisateur doit tre capable de chercher dans lensemble des bases de donnes. Le systme doit enregistrer la commande du client. Chaque commande doit avoir un identifiant unique (ORDER_ID). Buts Les exigences non-fonctionnelles peuvent tre difficiles spcifier de manire prcise, et ces exigences ambiges deviennent difficiles vrifier. Un but offre une intention ou un objectif gnral tel que la convivialit de lapplication. Les buts peuvent guider la dcouverte dexigences non-fonctionnelles vrifiables, qui peuvent tre testes objectivement.

11

Exemple de but : Un but du systme : o le systme doit tre facile utiliser et devrait tre organis de faon minimiser les erreurs dutilisation ; o Exigences non-fonctionnelles vrifiables, infres de ce but ; o Les utilisateurs expriments doivent tre capables dutiliser les fonctions du systme aprs une formation de 3 heures ; o Le nombre moyen derreurs faites par les utilisateurs expriments ne doit pas excder 2 par jour.

Problmes gnraux de lingnierie des exigences :

Manque dexpertise (ingnieurs logiciels, experts de domaines, etc.) ; Ides initiales trop souvent incompltes, trop optimistes, et fermement prsentes dans les ttes des personnes grant le processus dacquisition ; Difficults utiliser les outils et mthodes complexes et varies associes la cueillette dexigences peuvent effacer les bnfices escompts dune approche complte et dtaille ; Difficults trouver le profil psychologique adquat.

12