L’ingénierie des Besoins : Une Etape Clé

Actuellement les systèmes logiciels sont devenus plus complexes, et leur développement est plus difficile et par conséquent leur évolution devient aussi fastidieuse. La mesure primaire du succès d’un système logiciel est le degré auquel il réalise le but pour lequel on l’a construit. Le processus d’Ingénierie des Besoins est un ensemble de tâches bien plus complexe que la simple production en début de projet d’un document spécifiant le système à construire. Définir les besoins pour un logiciel est un processus qui fait appel à des compétences humaines, techniques et méthodologiques très variées, alliant rigueur et créativité. Une étude efficace des besoins réduit très sensiblement le coût du développement et de la maintenance d’une application et accroît sa qualité [Aur 05]. Dans les méthodes d’ingénierie des exigences, deux types d’exigences peuvent être identifiés. Les exigences fonctionnelles qui spécifient les fonctions que le système à concevoir doit être en mesure d’effectuer. Les exigences non‐fonctionnelles qui capturent les propriétés ou les contraintes sous lesquelles le système à concevoir doit fonctionner, telles que les aspects de performance, de qualité ou de sécurité. Les pratiques industrielles actuelles consistent à spécifier les exigences fonctionnelles dès les premières phases de développement logiciel et à laisser la prise en compte des exigences non‐fonctionnelles au 56 niveau de l’implémentation. Ce choix est souvent justifié par l’énorme pression (en termes de temps) pour le déploiement rapide d’un prototype du logiciel [Cys 03].

Définitions

L’expression « Requirements Engineering » semble avoir été utilisée pour la première fois par [Hag 88]. Une traduction exacte devrait être « ingénierie des exigences » mais nous suivons l’usage en utilisant « ingénierie des besoins ». Tous les projets commencent par l’étape des besoins. Les besoins décrivent ce qu’un produit logiciel doit exécuter. Un besoin se rapporte typiquement à un certain aspect d’un nouveau produit ou un service ajouté [Aur 05]. Dans les sciences informatiques, le terme « ingénierie des besoins » est à la fois utilisé pour désigner un thème de recherche, pour référencer une activité du processus de développement de systèmes logiciels ainsi que pour référencer un « processus » de construction d’une spécification des besoins. Plusieurs définitions du terme « ingénierie des besoins », que nous énumérons ci‐dessous, ont été introduites dans la littérature : Le standard IEEE 610.12‐1990 [ANS 90] définit un besoin comme étant : « Une condition ou capacité nécessaire à un utilisateur pour résoudre un problème ou atteindre un objectif », ou comme étant « une condition ou capacité qui doit être reconnue ou possédée par un système pour satisfaire un contrat, un standard, une spécification ou d’autres types de documents formellement imposés ». On trouve dans [Zav 93] une des définitions les plus précises de l’ingénierie des besoins : «L’ingénierie des besoins est la branche du génie logiciel concernée par des buts du monde réel pour des fonctions des systèmes logiciels et des contraintes sur ces derniers. Elle est également concernée par la relation de ces facteurs pour préciser des spécifications du comportement du logiciel et leur évolution avec le temps et à travers des familles de logiciels». Cette définition est attrayante pour certaines raisons. D’abord, elle accentue l’importance sur « les buts du monde réel » qui motivent le développement d’un système logiciel. Puisqu’elle représente aussi bien le « Pourquoi » que le « Quoi » d’un système (Figure 3.1). Par ailleurs, elle se rapporte « à des spécifications précises ». Celles‐ci constituent la base d’analyse des besoins, validant ce que les parties prenantes veulent, définissant ce que les concepteurs doivent construire, et vérifiant qu’ils ont fait le travail correctement à la livraison. 57 Figure 3.1 Le fondement de l’ingénierie des besoins [Rol 03]

Classification des Exigences

La littérature établit une distinction entre différents types de besoins, dans la pratique il n’est pas toujours facile d’identifier de telles différences [Ber 98]. Idéalement les besoins sont indépendants de la conception, montrant le « Quoi » que le système logiciel doit faire, plutôt que le « Comment » il doit le faire. Les besoins peuvent être classés dans plusieurs directions, comme illustré dans la table 3.1 [Aur 05]. Classification Classe des besoins Eclaircissement 1 Besoins fonctionnels Ce que le système doit faire comme fonctions Besoins non-fonctionnels Contraintes sur les types de solutions qui mènent les besoins fonctionnelles. Par exemple : précision, performance, sécurité et fiabilité 2 Besoins niveau but Relié aux buts métier Besoins niveau domaine Relié à l’espace du problème Besoins niveau produit Relié au produit Besoins niveau conception Quoi construire 3 Besoins primaires Elicités à partir des parties prenantes Besoins dérivés des besoins primaires Elicités à partir des besoins primaires 4 Besoins métiers Besoins liés à l’activité de l’entreprise (son métier) Besoins processus Comment les gents interagissent avec le système Besoins basés rôle Par exemple: besoins consommateur, besoins utilisateurs, besoins IT, besoins système, et besoins de sécurité Table

Classification des besoins

Activités de l’Ingénierie des Besoins

On trouve dans [Lam 09] et [Nus 00] une description des activités qui caractérisent une démarche d’ingénierie des exigences. Nous les présentons dans ce qui suit. La compréhension du domaine Cette activité consiste en l’identification des parties prenantes à l’aide d’interviews en étudiant aussi l’environnement du système. Les problèmes du système actuel sont ainsi découverts et les possibilités d’amélioration sont analysées. L’élicitation des exigences Cette activité consiste à découvrir les exigences et les hypothèses candidates pour le système en cours en se basant sur les faiblesses du système actuel, extraites dans l’activité de la compréhension du domaine. Plusieurs techniques peuvent être employées pour avoir les informations appropriées telles que les interviews avec les parties prenantes, les scénarios, les questionnaires, etc. Nous avons sélectionné un noyau de huit techniques et approches qui offrent une couverture appropriée à travers la gamme de techniques et approches disponibles (par exemple Ethnographie comprend l’observation, et JAD est un exemple de travail actuel en groupe), et qui représentent à la fois l’état de l’art et l’état de la pratique.