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 définitions retenues par les standards ISO, IEEE, CMMi sont :

1) Condition ou capacité dont un utilisateur a besoin pour résoudre un problème ou atteindre un objectif.
2) Condition ou capacité que doit posséder un produit ou un composant de produit pour remplir un contrat, se conformer à une norme, une spécification ou tout autre document imposé formellement.
3) Représentation documentée d’une condition ou d’une capacité comme dans (1) ou dans (2).
 
Autre définition d'Alan Davis : « Une exigence est une caractéristique observable de l’extérieur d’une entité souhaitée »

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.

 

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.

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

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

Auteur : Gauthier Fanmuy

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

 

 

Eléments essentiels d’ingénierie des exigences pour la réussite des projets de fabrication d’un produit (système ou logiciel)

Auteur : Stéphane Badreau

A la question, quels sont les éléments incontournables à considérer en ingénierie des exigences indépendamment de tout cycle de fabrication d’un produit, vous répondez quoi ?

En d’autres termes, quels sont les éléments que toute organisation (et donc tout projet) devrait déterminer et analyser quel que soit le mode de fabrication d’un produit ; mode traditionnel (en cascade, en V), mode itératif et/ou incrémental ou mode agile ?

La question peut paraître saugrenue mais avec la diffusion de plus en plus importante des approches et des pratiques agiles au sein des organisations, nous avons l’impression (souvent confirmée malheureusement !) que les bonnes pratiques d’ingénierie des exigences sont quelque peu oubliées par les équipes projet. Par exemple, prenez Scrum, la pratique agile aujourd’hui la plus répandue. Scrum définit des rituels, des rôles et des artefacts, mais Scrum ne fournit aucune indication (ou très peu) sur des éléments comme la vision du produit, les objectifs des parties prenantes, et encore moins sur les activités qu’il faut mettre en œuvre pour les identifier. Nous le savons bien, Scrum comme toute pratique agile n’est pas une méthode !

L’expérience montre qu’il existe des incontournables en ingénierie des exigences pour un projet de fabrication d’un produit. Ces incontournables sont au nombre de trois :

  • La vision du produit
  • Les parties prenantes et leurs objectifs
  • Le périmètre et le contexte du produit

Incontournable n°1 - La vision du produit

Tout projet doit être guidé par une vision. La vision est la raison d’être du projet et elle fixe le cap pour l’ensemble des équipes. La vision est un des objectifs majeurs recherchés dans le cadre du projet et représente souvent un ou plusieurs objectifs des parties prenantes. Bref, la vision c’est LA cible à atteindre et est souvent le résultat d’un compromis. L’atteinte de cette cible permettra de statuer au final si le projet est une réussite ou pas. La cible est unique et invariante dans le temps, mais cela ne veut pas dire qu’il existe qu’un seul chemin pour l’atteindre. 

Si toutefois, il vous arrivait d’être obligé de modifier la vision du produit dans un projet cela voudrait peut-être dire que soit votre vision initiale était erronée, soit que votre projet n’est plus le même ! Plusieurs techniques permettent de décrire cette vision : vision textuelle, Product box, … mais ceci n’est pas le sujet de cet article.

Incontournable n°2 - Les parties prenantes et leurs objectifs

Une partie prenante est une personne physique ou morale qui a un intérêt ou une influence dans le projet de fabrication du produit. On pense évidemment aux utilisateurs finaux du produit, bien entendu, mais les parties prenantes regroupent souvent un nombre beaucoup plus important de personnes. Des parties prenantes seront très proches du système à l’étude (comme par exemple les concepteurs, les testeurs…), tandis que d’autres parties prenantes seront beaucoup plus « éloignées » du produit, si éloignées qu’elles ne verront ou n’utiliseront peut-être jamais le produit (les organismes de réglementation par exemple) !

Une partie prenante sera identifiée comme telle à partir du moment où elle aura un objectif lié au projet, comme par exemple un utilisateur vis-à-vis du futur système. En général, chaque partie prenante aura un et un seul objectif majeur qu’il faudra identifier. Cet exercice n’est pas aussi simple qu’on pourrait le croire, il faut remonter au « pourquoi ? » de plus haut niveau. De cet objectif majeur découleront d’autres sous-objectifs qui seront identifiés par des techniques de questionnement et de scénarisation. Les objectifs des parties prenantes pourront être documentés sous la forme d’un arbre de buts.

La vision dont nous avons parlé plus haut fera vraisemblablement référence à un objectif majeur pour une partie prenante, en général celle qui bénéficiera de la plus grande valeur apportée suite à la livraison du produit final.

Il existe plusieurs manières de documenter les parties prenantes ; tableau (indispensable à mon sens), carte, diagramme en pelure d’oignon… Là encore, je ne détaillerais pas ces techniques ici.

Incontournable n°3 - Le périmètre et le contexte du produit

Le terme « périmètre » est souvent employé lorsque l’on parle d’un produit mais savez-vous à quoi il fait référence ?

En fait, définir le périmètre d’un produit c’est répondre de manière complémentaire aux deux questions suivantes :

  • Que contient mon produit (autrement dit, qu’est-ce qui est à l’intérieur du produit) ?
  • Qu’est-ce qui ne fait pas partie de mon produit (qu’est-ce qui reste à l’extérieur de mon produit) ?

Répondre correctement et complètement à ces questions permet de connaître ce que l’on appelle la limite du produit. Dès lors que la limite du produit sera connue, les éléments constituant son environnement pertinent (c’est-à-dire son contexte) seront identifiés. En fonction du cycle de vie du produit (d’un contexte d’utilisation), ces éléments du contexte interagiront avec le produit. Par là même, les interfaces externes du produit seront déterminées. Au-delà du contexte, nous pourrons parler d’environnement non pertinent pour notre produit et d’une autre notion que l’on appellera la limite du contexte.

Bref, avec un petit schéma comme celui-ci-dessous ce sera mieux !

systeme_contexte_limite.png

Pour documenter le contexte d’un produit, vous pouvez utiliser des diagrammes de contexte, des diagrammes de flux, des diagrammes de cas d’utilisation…

Voilà un petit rappel sur ces éléments essentiels…

Sans ces 3 éléments, il faut savoir que les projets prennent un risque important de figurer dans la catégorie des projets en échec ;-(!

Retrouvez d'autres articles en bas de la page "Publications" de ce site.