Quels modèles pour définir les buts, les besoins et les contraintes ?

La première étape de la construction du système²⁴ consiste à identifier et à formaliser les exigences

que le système doit satisfaire. Ces exigences sont rassemblées au sein d’un référentiel, désigné

référentiel d’exigences. Ce référentiel est défini à partir des besoins des utilisateurs du système et des contraintes à respecter. En d’autres termes, ce référentiel formalise le problème à résoudre. Il établit le contrat entre la personne physique ou morale pour le compte de laquelle le système est réalisé (maître d’ouvrage) et la personne physique ou morale qui le conçoit et en contrôle la réalisation (maître d’œuvre) [AFIS, 12].

Depuis les années 80, deux catégories de travaux traitent de la définition du référentiel d’exigences. Les travaux de la première catégorie concernent l’analyse fonctionnelle (ou analyse de la valeur) des produits manufacturés [AFNOR, 91]. Ceux de la deuxième catégorie concernent l’ingénierie de définition des besoins dans les domaines du génie logiciel [Sommerville, 92] et du système d’information [Rolland et al., 01] [Nuseibeh et al., 00]. Plus récemment, les travaux relatifs à l’ingénierie système proposent une approche globale qui s’applique à tout système, qu’il soit tangible (produits manufacturés) ou intangible (logiciel et système d’information) [AFIS, 12].

Parmi les différentes définitions existantes [IEEE, 90] [Sommerville et al., 97] [Wiegers, 00] nous

retenons celle proposée par l’AFIS pour définir ce qu’est une exigence [AFIS, 12]. Une exigence* est

un énoncé qui spécifie une aptitude, une caractéristique ou une limitation d’un système, d’un produit ou d’un processus pour contribuer, dans des conditions d’environnement données, à la satisfaction d’un but donné [AFIS, 12].

Cette définition met en lumière la notion de but. Il est courant de s’appuyer sur des questions pour

différencier les concepts de « but » et « d’exigence ». Le but permet de répondre à la question « Pourquoi le système existe ? » tandis que l’exigence répond à la question « Que doit faire le système ? ». Plusieurs travaux considèrent qu’il est nécessaire de comprendre les buts pour pouvoir exprimer correctement les exigences. Ils proposent donc des méthodes d’ingénierie de définition des besoins dirigées par les buts [Dardenne et al., 93] [Anton, 96] [Mylopoulos et al., 99] [Rolland, 03]. Ces méthodes préconisent une démarche pour construire une hiérarchie des buts attribués au système. Une fois cette hiérarchie déterminée, les exigences sont identifiées à partir des buts du plus bas niveau de la hiérarchie [Rolland, 03].

Comme exemples de buts, nous pouvons citer « diminuer le nombre d’utilisations de la mauvaise version d’un document », « diminuer le temps de recherche de documents », « sécuriser les données », « augmenter la réutilisation de modèles géométriques existants », etc.

Comme exemples d’exigences, nous pouvons citer « le système permet à l’utilisateur de créer des versions de documents », « le système permet à l’utilisateur de changer le statut d’un document », etc.

Pour être convenablement formalisée, une exigence doit répondre à plusieurs caractéristiques de

qualité [AFIS, 12] qui sont :

 L’unicité : l’exigence ne traite que d’un sujet,

 La précision : l’exigence est rigoureuse dans son expression,

 La non-ambiguïté : l’exigence ne permet qu’une interprétation possible,

 La pure prescription de résultat : l’exigence répond à la question « Quoi ? » et non à la question « Comment ? »,

 La vérifiabilité : l’exigence est vérifiable,

 La faisabilité : l’exigence doit pouvoir être satisfaite dans le contexte de l’état de l’art technologique à l’horizon envisagé,

 Le réalisme : l’exigence doit pouvoir être satisfaite dans le contexte des contraintes du projet.

24

Ce paragraphe reste volontairement général sur la formalisation des buts, des besoins et des contraintes. Même si un certain nombre de points sont issus de travaux orientés sur les systèmes d’information, les principes généraux énoncés s’appliquent généralement à tout système. Ils devront donc être pris en compte, par le système PLM, lors de la définition du référentiel d’exigences des produits. Les exemples proposés pour illustrer nos propos sont toujours liés au système PLM.

Chapitre 3 : Méthode d’élaboration du cahier des charges du système PLM

73

La non-ambiguïté nécessite de décomposer l’exigence jusqu’à un niveau qui garantisse la bonne compréhension entre les différentes parties prenantes liées à la construction du système. Prenons l’exemple de l’exigence « le système permet à l’utilisateur de créer des versions de documents ». La mise en œuvre de cette exigence n’implique pas forcément les deux aptitudes suivantes : « le système demande à l’utilisateur de rédiger un commentaire pour chaque nouvelle version d’un document existant » et « le système stocke les anciennes versions d’un document ». Si ces deux aptitudes sont requises, il est nécessaire de les formaliser dans le référentiel d’exigences. En effet, les juger implicites serait une erreur. Cela pourrait avoir pour conséquence une non-satisfaction du besoin.

La vérification des exigences garantit que les exigences sont écrites selon les règles de l’art, c’est à dire qu’elles respectent les caractéristiques de qualité définies.

Dans le cadre de l’ingénierie de définition des besoins, [Wiegers, 03] préconise de séparer les exigences relatives au système, des exigences relatives au projet de construction du système (coûts, délais, etc.). Pour construire le référentiel d’exigences, il est nécessaire de définir les buts, les besoins et les contraintes. Pour faciliter cette définition, il est possible d’utiliser la classification suivante

[Wiegers, 03]²⁵ :

Les buts (exigences d’affaires) sont formulés sous forme de phrase avec un verbe à l’infinitif, par exemple « augmenter de 10% la ré-utilisation de modèle 3D existants ». Le verbe sous-entendu est le

verbe vouloir. Ils répondent à la question pourquoi veut-on mettre le système en place ?

Les besoins utilisateurs (exigences d’utilisation) sont décrits sous forme de cas d’utilisation ou de scénarios. Ils sont formulés sous forme de phrase avec un verbe à l’infinitif, par exemple « Gérer des

versions de documents ». Le verbe sous-entendu est le verbe avoir besoin de. Ils répondent à la

question quoi, c’est à dire ce que le système doit faire.

Les règles d’affaires correspondent à des besoins et à des contraintes métiers ou réglementaires. Le

verbe sous-entendu est le verbe devoir. Par exemple, « un utilisateur du service production n’a accès à

un plan que si ce dernier est en état valide ».

Les exigences fonctionnelles expriment les comportements attendus du système. Elles dérivent des trois catégories précédentes.

Cette classification définit également trois catégories d’exigencesnon fonctionnelles :

Les exigences de qualité expriment des propriétés attendues pour des aptitudes telles que la rapidité, l’efficacité, la robustesse, l’ergonomie, etc.

Les exigences d’interface définissent les communications entre le système à l’étude et son environnement.

Les exigences techniques déterminent des contraintes relatives à l’utilisation d’un langage particulier, de technologies spécifiques. Par exemple, les exigences sur les formats de données identifient qu’un code postal est composé de cinq chiffres.

Les buts, les besoins utilisateurs et les exigences fonctionnelles concernent la perception organisationnelle de l’entreprise tandis que les exigences non-fonctionnelles sont plutôt liées à la perception informationnelle (exigences d’interface, exigences de qualité, exigences techniques, etc.). Toutes ces catégories expriment la perception « boite noire » du système. Elles définissent en effet sa finalité et elles identifient les interfaces du système avec son environnement (cf. chapitre 2, § 3.1). Il est à noter que la définition des exigences non fonctionnelles est aussi importante que la définition des exigences fonctionnelles. En effet, le non-respect d’exigences techniques peut être un frein majeur à l’adoption d’un nouveau système.

25

Pour cet auteur, toute formulation (d’un but, d’un besoin, d’une contrainte, etc.) est considérée comme une exigence. Afin de ne pas amener de confusion dans ce mémoire et pour être en adéquation avec la définition de l’exigence que nous avons retenue, nous n’utilisons ce terme que pour l’énoncé d’aptitudes du système qui répondent aux caractéristiques de qualité définies. Dans un souci de compréhension les différentes classes ont été renommées (les noms proposés par l’auteur sont affichés entre parenthèses et en italique).

74

La figure 3.1 décrit les relations existant entre ces catégories. Elle identifie également trois modèles du futur système : le document de vision et de portée, le document de cas d’utilisation et le référentiel d’exigences. Chacun de ces modèles constitue une perception répondant à un objectif précis. Le

document de vision et de portée décrit les buts qui sont la raison d’être du système. Le document de cas d’utilisation formalise les comportements du système attendus par les utilisateurs. Les exigences

fonctionnelles sont dérivées de ces cas d’utilisation. Le référentiel d’exigences décrit les exigences

fonctionnelles et non fonctionnelles. Il constitue le contrat entre le maître d’ouvrage et le maître d’œuvre et il sert à vérifier que le système livré possède les aptitudes attendues.

buts besoins utilisateurs Document de vision et de portée Document des cas d’utilisation Référentiel d’exigences exigences non fonctionnelles exigences fonctionnelles règles d’affaires

Figure 3.1 : Formalisation des buts, des besoins et des contraintes (adapté de [Wiegers, 03])

Cette figure détermine les relations entre les buts, les besoins et les exigences. Un « besoin utilisateur » répond à un « but ». Cependant, aucune antériorité n’est préétablie. En effet, le processus d’identification et de formalisation des exigences est itératif. Un « but » peut être identifié suite à la définition d’un « besoin utilisateur » pour lequel on se sera posé la question suivante : « Pourquoi ce besoin utilisateur a-t-il lieu d’exister ? ». Ainsi, la détermination des buts, des besoins et des contraintes a une chronologie variable. Cependant, il est nécessaire d’identifier un minimum de buts pour initialiser le projet d’élaboration du futur système.

Les exigences peuvent être décomposées en plusieurs niveaux. Par exemple, l’exigence « le système gère des versions de documents » peut être décomposée en « le système permet à l’utilisateur de créer des versions de documents », « le système demande à l’utilisateur de rédiger un commentaire pour chaque nouvelle version d’un document existant » et « le système stocke les anciennes versions d’un document ».

Les caractéristiques suivantes permettent de vérifier que le référentiel d’exigences est formulé selon les règles de l’art [Constantinidis, 10] :

 Complétude: l’ensemble des exigences couvre la totalité du problème,

 Cohérence : il n’y a ni conflit ni de redondance entre deux exigences,

 Traçabilité : toute exigence peut être tracée vis à vis d’une exigence de plus haut niveau ou d’un but,

 Maintenabilité : un historique des modifications permet de réécrire une exigence,

 Priorisation : il est possible d’indiquer un ordre de priorité entre les exigences,

 Monosémie : tout terme utilisé a la même signification pour tous les lecteurs dans tout le document.

Chapitre 3 : Méthode d’élaboration du cahier des charges du système PLM

75

Pour être cohérent, le référentiel d’exigences ne doit pas contenir d’exigences redondantes. Il doit ainsi être composé d’exigences d’un seul niveau de décomposition. Le référentiel d’exigences ne doit pas contenir d’exigences en conflit. Il est ainsi le résultat d’un consensus entre les différentes parties prenantes qui peuvent avoir des besoins contradictoires.

La caractéristique de traçabilité exprime la capacité du référentiel à être validé. Dans le processus

d’ingénierie de définition des besoins, la validation d’une exigence consiste à s’assurer qu’elle est en

adéquation avec le but dont elle est dérivée. Au regard des trois modèles présentés précédemment [Wiegers, 03], le document de vision et de portée sert à valider le document des cas d’utilisation et le référentiel d’exigences. Ainsi, chaque cas d’utilisation doit contribuer à l’atteinte d’un but [Cockburn, 00].

Le référentiel d’exigences constitue une partie du cahier des charges (CDC) du futur système. Le

CDC formalise les buts et les besoins des utilisateurs représentés par le maître d’ouvrage ainsi que les contraintes à respecter. Ce document a plusieurs fonctions [AFNOR, 91]. Il constitue un contrat entre le maître d’ouvrage et le maître d’œuvre. Il est également un document de communication. En effet, en supportant le dialogue entre les différentes parties prenantes, il favorise chez le maître d’œuvre une conception et une réalisation efficientes. Enfin, le CDC est la formalisation pérenne qui identifie les buts, les besoins et les contraintes définis pendant le projet. Cette formalisation s’avère utile lorsque des modifications sont envisagées sur le système ou lorsqu’un changement de ce dernier est étudié au vu de nouvelles opportunités sur le marché. La construction du CDC doit ainsi permettre une compréhension du besoin et des contraintes la plus juste possible entre les parties prenantes. Pour cela, le CDC est composé des trois modèles du futur système (buts, cas d’utilisation, exigences), de glossaires, etc. Il inclut le référentiel d’exigences du système mais également les exigences liées au projet (coûts, délais, formation…). Il est à noter que, dans ce document, chaque exigence fonctionnelle doit être justifiée par l’identification du but et des cas d’utilisation dont elle est dérivée.