L'Ingénierie des Exigences

Le bouton d'arrêt d'urgence doit être rouge

Lorsqu’on débute dans une démarche de développement logiciel orienté exigence, il n’est pas rare que concepteurs et développeurs voient des exigences partout, jusqu’au bouton d’arrêt d’urgence qui doit être rouge.


Loin d’être une exigence, « Le bouton d’arrêt d’urgence doit être rouge » est une solution à une problématique d’ergonomie.
Il ne suffit donc pas que le verbe « doit » figure dans une assertion pour qu’elle constitue une exigence. Pas plus, qu’il suffit que l’assertion puisse être reliée (traçable) à une exigence d’ergonomie ou qu’elle soit vérifiable.


Le point central de l’ingénierie de l’exigence est de produire des exigences fonctionnelles et non fonctionnelles applicables au produit à réaliser. Ces exigences sont à la charnière entre l’analyse de la problématique à résoudre (elles constituent le produit de cette activité) et la définition/réalisation de la solution (elles sont la 1ère définition, en tant que boite noire, du produit à réaliser).
Dans une démarche de développement selon le cycle en V, elles sont acquises (mais non figées) au plus tard en fin de phase de spécification.


La génération dans les phases suivantes du cycle de développement de nouvelles exigences obtenues par transformation des exigences applicables aux produits est le symptôme d’une incompréhension des notions d’exigence, de traçabilité et de vérification.


Article également publié dans le forum "Ingénierie des exigences" sur Viadeo

Les activités de l’ingénierie des exigences

Les activités de l’ingénierie des exigences peuvent être regroupées en 2 macro-activités qui consistent en :

  • Développer les exigences, l’objectif de cette macro-activité est d’obtenir un référentiel d’exigences validé par les parties prenantes. Le développement d’exigences est un processus itératif et collaboratif.
  • Gérer les exigences, l’objectif de cette macro-activité est de maintenir ce référentiel stable dans le temps, en particulier en analysant l’impact d’un changement.


Le référentiel CMMi définit ces activités par les domaines de processus RD (Requirements Development) au niveau 3 et REQM (Requirements Management) au niveau 2 de maturité. Chacun de ces domaines de processus est lui-même décomposé en objectifs et pratiques comme par exemple « Développer les exigences produit » et « Identifier les exigences d’interfaces »...

D’autres référentiels comme l’IREB considèrent 4 activités principales :

  • Elucider les exigences
  • Spécifier les exigences
  • Valider les exigences
  • Gérer les exigences

Les 3 premières activités décrites par l’IREB (Elucider, Spécifier, Valider) contribuent à l’atteinte de l’objectif de la macro-activité « Développer les exigences » décrite ci-dessus.

Dans la pratique, et en fonction du contexte, il peut y avoir quelques adaptations, comme par exemple décomposer l’activité « Spécifier » en 2 sous-activités « Analyser » et « Modéliser ». Mais d’une manière générale, il y a consensus sur l’ensemble de ces activités de l’ingénierie des exigences.

 

Qu’est ce qu’une exigence ?

Il y a plusieurs définitions de ce qu’est une exigence, une des plus communément admise est la suivante :

"Une exigence est l’expression d’une condition ou d’une fonctionnalité à laquelle doit répondre un système ou un logiciel."

Les enjeux de l'ingénierie des exigences

Les enjeux de l'ingénierie des exigences sont nombreux, nous pouvons citer les principaux ci-dessous :

  • Satisfaire le client
  • Réduire les coûts du projet (étude, conception, développement, test et maintenance)
  • Améliorer la couverture du besoin
  • Maîtriser le périmètre du projet
  • Augmenter la qualité des livrables (produits et services)
  • Réduire les risques du projet
  • Faciliter les échanges et améliorer la communication au sein du projet
  • Réduire le time-to-market

Un système ou un logiciel de qualité est un système ou un logiciel qui satisfait les exigences des utilisateurs.

Ingénierie des Exigences : Enjeux, Principes et Bonnes Pratiques

Résumé. Les systèmes sont de plus en plus complexes. Il faut toujours faire plus vite, mieux et moins cher. La maîtrise du développement d’un système est plus que jamais au cœur des préoccupations des entreprises. Cette maîtrise passe par la maîtrise des exigences.
Mais si ce constat est largement partagé, nombre de sociétés se trouvent démunies face à cette problématique. Des tests sont généralement définis et exécutés, mais beaucoup s’accordent à dire que les exigences ne sont pas suffisamment précises, que l’on ne sait pas ce que le système doit faire, …

Après avoir présenté des constats et rappelé les principes clés de l’Ingénierie des Exigences, ce papier présente des bonnes pratiques d’amélioration des exigences d’un cahier des charges ou d’une spécification technique. Ces bonnes pratiques sont mises en situation dans le cadre d’une revue.


CONTEXTE

Le Standish Group a mené des études CHAOS [1] par l’interview d’entreprises dans le domaine du logiciel en 1994, 1996, 1998, 2000 et 2002. C’est la plus vaste étude publique connue à ce jour.
Un résultat important de l’étude CHAOS de 1994 est que plus de la moitié des projets vont coûter 189% plus cher que leurs estimations initiales. Plus de 30% des projets sont arrêtés avant leur fin.
Une analyse des résultats de cette étude montre que les exigences y sont pour 40% des facteurs de succès mais aussi d’échec des projets. Viennent ensuite à hauteur de 10 à 15% la gestion de projet et la gestion des données techniques.
15 ans après, qu’en est-il sur le terrain ? Est-ce une réalité ? Les pratiques d’Ingénierie des Exigences ont- elles évoluées ?


DU RAPPORT CHAOS A LA REALITE DU TERRAIN

Si l’on peut faire un constat issu d’échanges avec différents industriels au sein de l’AFIS (http://www.afis.fr) et de l’INCOSE (http://www.incose.org) depuis plus de 9 ans, on peut (heureusement) affirmer que la maturité et donc que les pratiques d’Ingénierie des Exigences ont progressé. Cette maturité se traduit également au travers des offres outils disponibles sur le marché
Mais si cette réalité est rassurante, on constate également que la maturité dépend du type d’industrie et que même dans un secteur dit Mature, la réalité du terrain est très variable.
On constate par exemple que le domaine Aéronautique / Spatial / Défense est historiquement très mature. Les domaines qui progressent fortement sont ceux de l’Automobile, Télécom, Ferroviaire, Dispositifs Médicaux. Ceux qui montent progressivement en maturité sont ceux de la Pharmacie.


Quelques faits issus de retours d’expériences dits matures :

Le discours officiel : « J’ai livré en temps et en heure ma spécification au projet. Elle est disponible dans l’outil d’Ingénierie des Exigences »
La réalité terrain : Manifestement la spécification n’a pas été revue. Les exigences sont identifiées mais leur qualité est à déplorer. Sa mise à disposition permet de passer l’indicateur au vert sans que la qualité y soit.

Le discours officiel : « Je décline les exigences utilisateurs en exigences techniques quantifiables. Ces exigences sont la référence pour la conception des produits de mon projet »
La réalité terrain : Les exigences sont bien transformées en exigences techniques mais par Métier. La cohérence des exigences entre ces Métiers n’est pas vraiment assurée. Les clients de ces exigences ne sont pas connus des spécificateurs.

Le discours officiel : « Les spécifications de besoins utilisateurs du projet ont été validées et sont gelées conformément aux jalons projet »
La réalité du terrain : « Comme la consigne est de ne pas faire évoluer les spécifications besoins, je prends en compte les modifications des besoins dans les spécifications techniques qui y répondent. Je n’informe pas le chef de projet mais cela me permet d’être à jour des besoins utilisateurs ».

Le discours officiel : « Des revues de spécifications et de conception sont menées sur le projet, conformément au schéma de développement standard de l’entreprise »
La réalité du terrain : « Je sais bien qu’en temps qu’acteur de l’équipe projet je dois valider l’ensemble des spécifications, mais vous comprenez bien que j’ai un agenda très chargé et que je n’ai pas le temps de relire des documents de 400 pages. Je demande donc simplement aux Métiers s’il n’y a pas points durs pour la valider. »


Quelques faits issus de retours d’expériences dits peu matures :

Les bonnes pratiques : « Les bonnes pratiques du secteur sont bien décrites. Mes exigences doivent être MUST (Mesurable, Utile, Simple, Traçable). Je dois mettre en œuvre des revues de conception. Les exigences clés doivent être identifiées »

La réalité du terrain : « Comment faire pour appliquer ces bonnes pratiques ? J’ai bien défini des templates, j’ai confié l’écriture des exigences à différents représentants utilisateurs. Je leur ai expliqué les qualités requises d’une exigence. Mais rien n’y fait : mes spécifications sont inhomogènes. Mes exigences ne sont pas toutes explicites. Conformément au planning, le fournisseur a développé un produit sur la base de ces exigences. J’ai de mon côté défini et exécuté des tests sur cette même base. Comme les exigences n’étaient pas claires et incomplètes et évoluent, le fournisseur est contraint à de multiples livraisons de produits. Je suis obligé de reprendre sans cesse la définition et l’exécution des tests.

La réalité du terrain : « Je connais le type de solution qu’il me faut. Je fais donc appel à un intégrateur qui va m’aider à paramétrer le produit compte tenu de mes problématiques. Un cahier des charges global suffira.

La réalité du terrain : « Mes exigences sont figées et ne devront pas être remises en question »

La réalité du terrain : « J’ai vu un fournisseur sur un stand. Les exigences sont les caractéristiques techniques du produit »

 

PRINCIPE D’INGENIERIE DES EXIGENCES

De nombreux facteurs sont à l’origine de ces situations très variables :

  • problème de changement de culture
  • problème de compréhension ou de non assimilation des fondamentaux,
  • fonctionnement dans l’urgence empêchant une mise en application,
  • problèmes politiques pouvant conduire à masquer des situations réelles,
  • peur d’aller de l’avant ne sachant par quel bout traiter le problème
  • etc.

 

Ces facteurs contribuent tous à ralentir voire rendre inefficace la mise en place d’un processus d’Ingénierie des Exigences.

 

Le principe de l’Ingénierie des Exigences est de collecter les besoins et contraintes des différentes parties prenantes intéressées dans le système. Ces besoins sont priorisés et déclinés au travers de la conception en exigences applicables aux différents sous-systèmes. Les arbitrages relatifs à l’équilibrage des différents besoins incohérents sont à mener le plus en amont possible, avant le lancement des consultations fournisseurs.

La maîtrise de la relation fournisseur passe par la maîtrise de la réponse fournisseur en phase de consultation puis par la vérification de la conformité des produits aux exigences émises.

 

Différents stades peuvent être mis en œuvre dans l’implémentation de ces principes :

  • Les fondamentaux : la qualité et la traçabilité des exigences, la structuration et le versionnement des cahiers des charges/spécifications, les revues.
  • La maîtrise des exigences : le pilotage par les exigences, le versionnement des exigences, la maîtrise de la relation fournisseur,
  • La maîtrise des lignes de produits : la réutilisation d’exigences génériques, l’élaboration de spécifications enveloppe adressant des variantes.

 

La mise en œuvre de ces principes peut apparaître comme complexe. Mais l’application de pratiques très simples peut avoir un effet de levier important, notamment par la mise en évidence de bénéfices court terme contribuant à l’adhésion des acteurs.

 

Le paragraphe suivant décrit un cas d’utilisation pour la mise en œuvre de bonnes pratiques.


BONNES PRATIQUES D’INGENIERIE DES EXIGENCES

Le cas d’utilisation : « Vous avez lu une spécification de 125 pages …arrivé à la fin du document vous avez perdu le fil … » 

Que faire ?

Voici 10 bonnes pratiques décrites ci-dessous en réponse à des questions.


Question 1 : « Quel type de système est concerné ? »

Bonne Pratique :
Le type de spécification concerné dépend du type de système.
Un système peut être de type « sur étagère », « configurable » ou « développé à façon ». La liste des spécifications est différente en fonction du type de système :

  • Sur étagère : la maîtrise d’ouvrage émet un Cahier des Charges (.i.e. spécification de besoins).
  • Configurable : la maîtrise d’ouvrage émet un Cahier des Charges, le fournisseur répond par une Spécification Technique. Il élabore une Spécification de Configuration qui décrit le paramétrage réalisé
  • Développé à façon : la maîtrise d’ouvrage émet un Cahier des Charges, le fournisseur répond par une Spécification Technique. Le fournisseur établit un Dossier de Conception. Dans le cas d’un système complexe, le système peut être décomposé en sous-systèmes sur N niveaux. A chaque niveau correspond des livrables Cahier des Charges, Spécification Technique, Dossier de Conception.

Exemple de catégorisation de systèmes issu du référentiel GAMP 5 [2] :

  • Systèmes de catégorie 3 : « sur étagère »
  • Systèmes de catégorie 4 : « Configurables »
  • Systèmes de catégorie 5 : « Développés à façon »


Question 2 : « Quelle est la nature de la spécification objet de la revue ? »

Bonne pratique :
Le type d’information, le détail des exigences dépend de la nature de la spécification.

  • Un Cahier des Charges décrit les besoins des différentes parties prenantes.
  • Une Spécification Technique décrit ce que doit faire le système ainsi que ses interfaces externes. Les exigences doivent être MUST (Mesurables, Utiles, Simples, Traçable) et exemptes de solution. L’ensemble des exigences doit être cohérent et complet.
  • Un Dossier de Conception décrit la solution, dont les architectures et les interfaces internes. Pour un système complexe, les exigences définissent les contributions des différents sous-systèmes.
  • Une Spécification de Configuration décrit le paramétrage de la solution.

Exemples issus du référentiel GAMP 5 [2]:

=> User Requirements Document:
1. Introduction
2. Overview
3. Operational Requirements
3.1 Functions
3.2 Data
3.3 Technical Requirements
3.4. Interfaces
3.5. Environment
4. Constraints
5. Life cycle requirements
6. Glossary

=> Design Specification:
1. Introduction
2. Overview
3. Configuration
4. Hardware design
4.1 The computer system (Architecture)
4.2 Inputs and outputs
4.3 Environment
4.4 Electrical supplies
5. Software design
5.1 Software description
5.2 System data
5.3 Module description
6. Glossary


Question 3 : « La spécification est-elle équilibrée ? »

Bonne pratique :
Le plan d’une spécification est révélateur de la maturité de la spécification et donc du rédacteur.
On doit retrouver les types d’informations attendus selon la nature de la spécification. Le nombre de pages d’un chapitre traduit les points qui sont détaillés / peu détaillés.

Exemple pour une Spécification Technique :

  • Il n’y a pas de documents de références : le rédacteur a-t-il intégré la réglementation, la bonne version du Cahier des Charges, … ?
  • Le terme « interface » ne figure pas : vraisemblablement le rédacteur n’a pas réfléchit au périmètre du système dont il est responsable, il n’a pas spécifié les interfaces.
  • Le paragraphe « Exigences » existe, sans structuration supplémentaire : vraisemblablement la liste des exigences est à plat. Le rédacteur ne s’est pas posé la question des fonctions assurées par le système. Il aurait pu regrouper les exigences fonctionnelles par fonction. Un effort particulier devra être effectué sur l’analyse de la cohérence / complétude de la spécification.
  • Le paragraphe « Exigences fonctionnelles » fait 10 pages. Celui relatif aux « Exigences opérationnelles » fait mois d’une page. Vraisemblablement les exigences relatives aux besoins des utilisateurs finaux sont détaillées. Les exigences relatives à la maintenance, la sûreté de fonctionnement, etc… risquent d’être insuffisantes.
  • L’architecture technique y est décrite : vraisemblablement le rédacteur n’a pas assimilé que la Spécification Technique décrit l’engagement à faire et doit être exempte de solution. Cette architecture doit être décrite dans un Dossier de Conception en réponse à la spécification technique.

 

Question 4 : « Y-a-t-il un diagramme de contexte ? »

Bonne pratique :
Un diagramme de contexte représente le système avec les acteurs / systèmes environnants avec les interfaces de haut niveau.
La présence d’un diagramme de contexte dans une spécification traduit le fait que le rédacteur à pensé à définir le périmètre de son système. Il a identifié les interfaces à spécifier.
A contrario son absence indique qu’il a un risque que :

  • des exigences d’interfaces soient manquantes,
  • des exigences soient hors périmètre du système et qu’elles devraient être sous la responsabilité d’une autre partie.


Question 5 : « Y-a-t-il une description du comment le système sera utilisé ? »

Bonne Pratique :
La compréhension du contexte est toute aussi importante que les exigences. En effet pour avoir un regard critique sur les exigences, il est souvent bénéfique de comprendre comment est utilisé le système.
Cette utilisation peut être formalisée de différentes manières. On peut citer par exemple :

  • les cas d’utilisation, qui permettent de décrire les scénarios d’utilisation du système sous une forme textuelle et graphique
  • les processus Métiers, qui permettent de décrire l’utilisation du système dans une logique « business » orientée Métier.

 

Question 6 : « Comment sont organisées les exigences dans le document ? »

Bonne Pratique :
La compréhension du problème posé nécessite d’expliquer :

  • L’objectif du système: « à quoi ça sert »
  • Dans quel contexte: « pourquoi, dans quelles conditions, pour quel scénario »
  • Avec quelles fonctionnalités : « quels services / fonctions »
  • Avec quelles caractéristiques : « quelles performances »
  • Avec quels systèmes: « quelles interfaces »
  • Sous quelles contraintes: « quelles réglementations, règles Métiers, contraintes industrielles »

Le tout sans tomber dans le piège de description de la solution technique !

Cette compréhension doit être progressive, du global vers le plus détaillé.

 

Question 7 : « Est-ce que les exigences sont identifiées ? »

Bonne Pratique :
Sans exigences, point de salut ! Il est clair que la base est que les exigences doivent être identifiées de manière unique. Si les exigences ne son pas identifiées, la mise en place de la traçabilité des exigences n’est pas possible, la conformité des réponses fournisseurs ou la définition des vérifications/validations sont rendues plus complexes.

Une bonne pratique est que les identifiants d’exigences sont neutres

Exemple d'une mauvaise pratique : Les exigences sont identifiées mais la numérotation dépend des numéros de paragraphes. Si une exigence est déplacée dans un autre paragraphe, la numérotation n’a plus de sens.


Question 8 : « La réglementation est-elle prise en compte ? »

Bonne Pratique :
Comment s’assurer de la prise en compte de la réglementation ? Comment justifier de sa couverture ? Indiquer dans une exigence qu’il faut respecter la réglementation XX n’est pas suffisant et ne permet pas de garantir cette couverture. Les exigences doivent préciser quelles dispositions sont prises pour satisfaire à la réglementation.

L’indication d’une criticité d’exigence vis-à-vis de la réglementation est une bonne pratique, mais pour assurer une couverture formelle de la réglementation, une traçabilité est à effectuer vers les différentes exigences réglementaires.


Question 9 : « Est-ce que les exigences d’interface sont spécifiées ? »

Bonne Pratique :
Les interfaces constituent un risque élevé pour un projet ou programme. Car la plupart du temps soit elles sont purement et simplement oubliées, soit elles sont spécifiées pour partie et de manière inégale. Elles sont systématiquement la source de dysfonctionnement des produits dans leur environnement.

Les interfaces ne sont pas seulement liées au logiciel. Elles couvrent les aspects fonctionnels, mécaniques, électriques, protocoles, messages, données.

L’élaboration d’un diagramme de contexte permet d’identifier les systèmes en interface avec le système d’intérêt et les types d’interfaces à spécifier.

Le niveau de détail des interfaces spécifiées doit être progressif selon la hiérarchie documentaire.

 

Question 10 : « Est-ce que les exigences sont conformes au MUST (Mesurable, Utile, Simple, Traçable) ? »

Bonne pratique :

Une exigence qui respecte les critères de qualité est MUST.

M : Il existe une méthode de vérification du produit par rapport à l’exigence (inspection, analyse, démonstration, test physique ou numérique…)

U : Information unique et explicitement identifiée, strictement nécessaire et précise

S : Pas d’information inutile ou superflue, formulation claire et précise. Comprise de la même façon par les parties prenantes et acceptée

T : Permettre de retrouver la source de l’exigence, retrouver la transformation du besoin à tous les niveaux du développement (allocations y compris). Permettre de retrouver la justification de l’exigence. Permettre de retrouver les tests mis en œuvre vis-à-vis de l’exigence.

 

Exemple de muSt (simple) :

  • Etre le plus synthétique possible
  • Les aspects techniques sont présentés dans un langage ne comportant pas de termes vagues ou ambigus. On utilise les mots les plus précis mais simples. On évite :
  • les termes génériques, vide de sens (exemple : gérer),
  • les adjectifs non mesurables et non quantifiables (ex. certains, plusieurs, rapide, correcte, quelques, divers …)
  • les adverbes non mesurables et non quantifiables (ex. peu, beaucoup, assez, moins, plus, souvent, parfois, longtemps, aussitôt, rapidement…)
  • le recours aux synonymes et utiliser le terme « déposé » (cf. glossaire)
  • les phrases sont simples, concises, courtes. Elles doivent :
    • traiter un seul aspect,
    • ne pas contenir d'ellipse (suppression d'un des éléments nécessaire à une construction sémantique complète),
    • ne pas contenir des clauses multiples. Les phrases comportant des clauses multiples seront converties en phrases séparées.

 

CONCLUSION

Une des particularités du processus d’Ingénierie des Exigences est que les exigences sont au cœur de la gouvernance des projets. Les exigences formalisent à tous les niveaux de décomposition d’un système :

  • l'expression des besoins et des engagements des parties prenantes
  • les attendus d’un système vis à vis de ses sous-systèmes
  • les interfaces entre sous-systèmes
  • les contraintes induites par les sous-systèmes sur le système

La montée en maturité dans le déploiement d’un processus d’ingénierie des exigences doit être progressive. Il n’est pas nécessaire de se doter d’un référentiel de processus complet et d’un outillage associé pour démarrer.

L’application de bonnes pratiques très simples permet de mettre en évidence des bénéfices court terme et visibles sur le plan de la qualité et contribuent à la conduite du changement.

La mise en œuvre d’une démarche en « YU » permet de construire progressivement un processus outillé opérationnel : évaluation de la pertinence des méthodes, amélioration des outils.

Les principaux bénéfices attendus de l’Ingénierie des Exigences sont:

  • satisfaction des clients et autres parties prenantes
  • robustesse: consolidation au plus tôt des exigences
  • parallélisation: élaboration d'exigences cohérentes à plusieurs niveaux de décomposition d'un système, maîtrise des interfaces
  • justification de la conformité à la réglementation
  • construction de tests ciblés


REFERENCES

[1] Rapport CHAOS du Standish Group : http://www.standishgroup.com

[2] ISPE GAMP 5 - Good Automated Manufacturing Practices, ISBN 1-931879-61-3

[3] IEEE Std 830-1998 – IEEE Recommended Practice for Software Requirements Specifications

[4] REGAL – Requirements Guide for All, INCOSE product of the year 2008, http://www.incose.org/regal