Les objectifs d'impact d'un projet nous donnent un état cible. Où voulons-nous être à la fin ? Quels sont les objectifs du projet ? Les objectifs de mise en œuvre fournissent les conditions cadres. Quelles sont les ressources dont nous disposons dans le cadre du projet ? Quel chemin devons-nous prendre pour atteindre l'objectif ? Les objectifs du projet, c'est-à-dire les objectifs d'impact et d'exécution, sont définis au début du projet - généralement. Mais que signifient ces exigences ? Et quand entrent-ils en jeu ?

Les exigences sont des objectifs concrets...

Dans un projet, il n'y a que quelques objectifs, du moins par rapport aux exigences. Les exigences existent généralement sous forme de listes. Souvent, cependant, la relation entre les exigences et les objectifs n'est pas vraiment établie. Après tout, que sont les exigences autres que les objectifs ventilés ? Objectifs détaillés du projet. La concrétisation des objectifs du projet. Les exigences sont définies au cours des premières phases du projet, par exemple lors de la phase de conception ou d'élaboration du concept. Cela fait partie de la discipline du projet "Ingénierie des exigences". Et les objectifs du projet constituent le point de départ de cette démarche. C'est du moins la théorie.

...et les objectifs sont des exigences abstraites

Examinons cela de plus près. Retournons le calendrier et revenons de la liste des exigences aux objectifs. Les objectifs sont essentiellement le résumé des exigences et forment un niveau d'abstraction plus élevé. En fait, les objectifs et les exigences sont les mêmes. Juste à des altitudes ou des niveaux de considération différents. Un exemple illustre cette situation. Disons que nous voulons construire un système logiciel qui nous permette de mieux planifier nos ressources humaines (un objectif d'impact du projet). Et il ne devrait pas non plus coûter plus de 200 000 francs suisses et être mis en œuvre d'ici un an (deux objectifs d'exécution du projet). Il s'agit probablement davantage d'objectifs de projet du point de vue de la gestion (haute altitude).

Le chef de projet et son équipe ne seront probablement pas encore entièrement satisfaits de ces objectifs de gestion : Que signifie précisément "être en mesure de mieux planifier les ressources humaines" ? Et que signifie "introduit dans un délai d'un an" ? L'équipe du projet doit le savoir plus précisément et décomposer ces objectifs à son propre niveau de vol. Cette concrétisation se fait dans les premières phases du projet. Mieux pourrait signifier, par exemple, qu'une vue d'ensemble de l'utilisation des ressources existantes est obtenue plus rapidement. Ou que l'on peut enregistrer les besoins en ressources dans le système. Encore plus concret : Le système devrait montrer graphiquement à un chef de service les courbes de charge de travail de ses employés au cours des 3 prochains mois, en appuyant sur un bouton. Dans le monde du développement de logiciels, cela correspond en quelque sorte à une histoire d'utilisateur ou à un cas d'utilisation. (Cette analogie devrait suffire pour cette approche approximative).

Les objectifs sont le QUOI, les exigences le COMMENT

En décomposant les objectifs du projet en exigences dans le cadre de l'ingénierie des exigences, il devient rapidement évident qu'il peut y avoir plusieurs concrétisations pour de nombreux objectifs. L'objectif "mieux" peut être compris comme "plus rapide", "plus clair" ou aussi "plus rentable". Il s'agit de différentes approches (conceptions) pour atteindre un objectif. Ainsi, beaucoup de décisions doivent être prises dans cette phase du projet : Chaque objectif (QUOI) peut être atteint avec des solutions différentes (COMMENT). Et quelqu'un doit décider, dans cette phase, laquelle de ces solutions sera retenue. Ce sont des décisions de conception qui sont souvent prises insidieusement et pas vraiment consciemment dans le cadre du projet.

De l'objectif à la décision de conception à l'exigence, à l'infini

Une fois que les objectifs du projet (QUOI) ont été transformés en exigences (COMMENT) par le biais de décisions de conception, l'ensemble du processus peut bien sûr être répété. Ces exigences peuvent à présent être considérées comme des objectifs détaillés. Après tout, qu'est-ce que des exigences, sinon des objectifs concrets ? Ils peuvent donc se concrétiser encore davantage. Pour revenir à notre exemple, cela signifie que l'histoire de l'utilisateur ci-dessus peut être concrétisée davantage. En matière de développement de logiciels, on pourrait probablement dessiner ici un écran qui montre où l'utilisateur peut appuyer sur quel bouton, afin d'obtenir ensuite un diagramme à barres, etc.

Cependant, nous ne voulons pas poursuivre cet exemple de manière aussi détaillée ici. Le fait est plutôt que nous voyons ici que la répartition des objectifs en exigences peut, en principe, être répétée plusieurs fois. Chaque exigence (COMMENT) peut être considérée comme un objectif (QUOI) à un niveau plus profond, qui à son tour peut être décomposé en détails. Cela pourrait être répété à volonté. Dans le développement de logiciels, les objectifs pourraient être décomposés par des décisions de conception à tel point qu'un pseudo-code ou même un code exécutable émerge à la fin et que les exigences sont ainsi si concrètes que la solution finie est presque déjà devant vous. À ce niveau de détail, on parle souvent de spécifications techniques. Mais au fond, il s'agit simplement d'objectifs très, très détaillés.