bullet1 L'état de l'art

L'état de l'art : l'ingénierie des besoins

La démarche systématique, rationnelle et outillée pour élaborer un cahier des charges et suivre l'évolution des besoins tout au long d'un projet s'appelle ingénierie des exigences ou ingénierie des besoins.

C'est une démarche globale, visant une meilleure adéquation du produit logiciel aux besoins des utilisateurs.

Sur un projet de développement, l’application des techniques de recueil, d’analyse et de spécification des besoins peut apporter des gains substantiels sur les coûts, les délais ou la qualité du produit.

Dans de nombreux cas, la demande reflète très mal le besoin ; de plus, elle est maladroitement formulée et le fournisseur perçoit un message brouillé d'où il extrait des spécifications inadaptées. De plus, client et fournisseur ont rarement la même culture : leurs vocabulaires sont différents et ils ne portent pas attention aux mêmes éléments. A partir de ce message brouillé, le fournisseur réalise souvent une solution qui a peu de chances de satisfaire le véritable besoin de l'utilisateur.


bullet2 La définition du concept et des objectifs

La définition du concept et des objectifs est une étape préalable à l'expression des besoins. Elle permet de spécifier, à larges mailles mais avec précision, les enjeux, la vision, le périmètre et le contexte du produit.

Elle permet de cadrer le projet, de clarifier les enjeux, de tracer la vision du produit, de définir le  périmètre actuel et futur, d'évaluer la complexité du projet.

Si cette étape est bien menée, elle apportera légitimité et aisance au maître d'ouvrage délégué ou à l'assistant à la maîtrise d'ouvrage. Sa mission sera facilitée.

bullet2 Le recueil et l'analyse des besoins

Recueillir, analyser et exprimer les exigences est un métier difficile. L'art du conseiller à la maîtrise d'ouvrage, ou de « l’ingénieur des besoins », consiste à utiliser une ou plusieurs de ces techniques et outils pour faire ressortir les besoins, les expliciter et les formaliser.

Les grandes étapes sont

    1. Recueil des besoins Au moyen techniques diverses : questionnaires interviews, observation directe, réunions, brainstorming…
    2. Analyse des besoins. Lors de cette étape, les besoins « bruts » devront être raffinés, en éliminant les ambiguïtés, incohérences, redondances et incomplétudes entre les besoins exprimés.
    3. Spécification des exigences. Cette étape consiste à rassemble dans un document unique (le cahier des charges ) l’ensemble des exigences du système sous forme cohérente. Ce document tient compte des besoins exprimés par les utilisateurs ou d’autres parties prenantes, des objectifs, du contexte, et des contraintes techniques. Il inclut les exigences fonctionnelles (ce que le système doit faire) ; les exigences non fonctionnelles (fiabilité, ergonomie, …) ; des contraintes techniques.
    4. Validation : Les exigences devront être vérifiées et validées par toutes les parties prenantes. Divers moyens existent pour valider les exigences : revues de documents, les maquettes et prototypes. Larédaction de scénarios de test, le plus en amont possible, est également un excellent moyen de validation.
    5. Négociation. Les besoins peuvent être très différents d’un utilisateur à l’autre, ou entre les utilisateurs et la maîtrise d’ouvrage : le travail sur les exigences est un travail de négociation.
    6. Gestion des évolutions. Les changements dans les exigences, à tous les stades du projet, est un phénomène inévitable, même lorsque tout a été mis en œuvre pour capter, analyser et spécifier les exigences de manière exhaustive. Les techniques qui permettent de limiter les risques sont multiples : établissement de liens de traçabilité entre exigences de différents niveaux ; établissement de processus formalisés et de procédures strictes de gestion des changements ; mise en place d’un comité de gestion des changements, point de passage obligé et unique de toute demande de changement ; systématisation des analyses d’impact, avant toute modification de l’application.

Le processus de définition des exigences est un processus itératif.











bullet2 Les diverses techniques de recueil et d'analyse

Plusieurs techniques existent pour recueillir, formuler, négocier les exigences, et ces techniques peuvent s’utiliser seules, ou se conjuguer, en fonction du domaine d’application, des typologies d’utilisateurs, de la spécificité de l’application ou du produit à développer.

    • Le questionnaire : il permet de recueillir rapidement les avis de plusieurs personnes sur un certain nombre de points. Il est utile pour obtenir des données factuelles et des opinions sur des points précis.
    • L’interview : c’est la technique la plus courante et la plus directe pour découvrir les besoins. Malgré sa simplicité apparente, la technique d’interview est un art difficile demandant une certaine expérience et un réel savoir-faire.
    • Les ateliers de travail : les experts métier se réunissent pour exprimer les besoins. Une session de travail dure une demi-journée à trois jours. Le choix des participants, l’organisation matérielle et l’expérience de l’animateur du groupe sont des facteurs-clés de la réussite.
    • L’observation sur le terrain : c’est un moyen efficace de connaître leurs besoins des utilisateurs. Elle peut prendre plusieurs formes, en fonction du type d’application et de l’environnement.
    • L’analyse de la concurrence : c'est un bon moyen de mettre en lumière des besoins.
    • Les diagrammes d’affinités : un outil qui permet de découvrir, classer, organiser les besoins utilisateurs. C’est un outil faisant appel à la pensée créative et à l’intuition.
    • La méthode de Kano : permet de grouper les caractéristiques d’un produit en fonction du degré de satisfaction qu’elles apportent aux utilisateurs.
    • Les matrices de priorité : ce sont avant tout des outils de négociation. Elles permettent de trouver un compromis entre différents besoins, et entre les manières de les satisfaire, en fonction de critères.
    • Les cas d’utilisation et les scénarios :  un des meilleurs moyens de décrire les besoins des utilisateurs. L’idée est de décrire les interactions entre l’utilisateur et le système, avec la particularité de centrer la description sur l’utilisateur, et non sur le système.
    • La modélisation des données, des  traitements et des processus.
    • les maquettes et prototypes.

Aucune de ces techniques  n'est meilleure que les autres. Chacune a son utilité en fonction du métier du client, du profil des interlocuteurs, du type d'application.

Tout l'art du consultant consiste à sélectionner la bonne technique en fonction du contexte de son client, et à l'appliquer judicieusement.





bullet2 Le cahier des charges

Le cahier des charges est un document constitué d’un ensemble structuré d’exigences, transmis d’un client à un fournisseur, et qui a un caractère contractuel. Son élaboration est un travail collectif nécessitant la collaboration de nombreux acteurs. Le processus de cette élaboration est aussi important que le document qui en résulte.

Un bon cahier des charges est un document clair, facile à lire et à comprendre par les différents acteurs, qui a été établi sur la base d’un consensus. Étant donnée la complexité de certaines situations que cedocument représente, il peut être très complexe, mais il n’est jamais « compliqué » : c’est un document relativement facile à maintenir et à modifier.

Ce document, élaboré de manière participative, définissant clairement les exigences d’un client vis-à-vis d’un fournisseur, sera utile au choix, à la conception, à la réalisation, au paramétrage d’une application ou d’un système informatique, ainsi qu’à sa mise en oeuvre opérationnelle, sa maintenance et son exploitation.

bullet2 La qualité du logiciel

La qualité du logiciel est définie par six caractéristiques principales décrites dans la norme ISO/CEI 9126.

Chaque caractéristique se décompose en plusieurs sous-caractéristiques.

La figure ci-dessous représente la décomposition de la qualité en caractéristiques et sous-caractéristiques.


Comme je l'ai indiqué dans mon ouvrage  et dans plusieurs articles , ce modèle de qualité peut être utilisé non seulement pour l'évalution de la qualité (c'est la raison d'être initiale de la norme) mais également pour sa construction tout au long du cycle de développement du logiciel. La nouvelle version de la norme (ISO 2500 SQuaRE) va d'ailleurs dans ce sens.

bullet2 L'ergonomie du logiciel

L'ergonomie est l'étude des situations de travail et des relations entre l’être humain et un système. Son objectif est d'améliorer le confort, voire le plaisir, de l’utilisateur et par voie de conséquence l’efficacité dans le travail et dans l’utilisation du logiciel.

La norme AFNOR Z-67 133-1 définit l’ergonomie du logiciel par sept critères : la compatibilité ; le guidage ; l’homogénéité ; la souplesse ; le contrôle explicite ; la gestion des erreurs ; la concision.

Ces sept critères sont très utiles, non seulement pour définir l’ergonomie, mais aussi pour construire des applications et des systèmes conviviaux.

Un logiciel ergonomique est très liée à la qualité de fonctionnement (en anglais, quality in use), composée, selon ISO/CEI 9126, de quatre critères :

  • L’ efficacité, capacité du logiciel à permettre aux utilisateurs d’atteindre leurs objectifs ;

  • La productivité, capacité du logiciel à optimiser le temps et l’effort à l’utilisateur ;

  • La sécurité (ou innocuité), capacité à limiter les risques pour les utilisateurs ;

  • La satisfaction, définie par une attitude positive de l’interaction utilisateur-produit ;

bullet2 La gestion et le suivi des exigences

Une fois les besoins recueillis, analysés, et négociés entre les parties prenantes, ils sont spécifiés sous forme d’exigences. Ces exigences sont transmises à l’équipe d’architectes et de concepteurs. Le logiciel passe ainsi de la phase de définition des exigences à la phase de conception.

Le changement des exigences doit être contrôlé pour limiter les risques sur le projet et le produit. La gestion du changement est essentielle pour minimiser ces risques, sans quoi les efforts de recueil, d’analyse et de structuration  des exigences fournis en amont seront perdus.

La gestion des changements des exigences est à la frontière entre plusieurs domaines de processus : la gestion des exigences, la gestion de la configuration du logiciel, la gestion de projet.

Chaque demande de changement devra être enregistrée, puis examinée par une commission de contrôle des changements quu la transmettra à un expert. Suite à cette analyse, la commission de contrôle des changements peut, décider de faire apporter une ou plusieurs modifications au logiciel. Le respect de ces procédures est nécessaire pour préserver une grande partie de l’effort qui a été fait en amont, à savoir le recueil, l’analyse et la spécification des exigences. La cohérence des exigences est à ce prix.

Copyright Yves Constantinidis Consultant
Contact : Yves Constantinidis.
Ce document a été mis à jour le 27/01/2013.