Ceci n’est pas une exigence … du système

[Cette article est aussi disponible aussi en Anglais]

L’objet de cet article est de mettre en exergue le fort caractère contextuel d’une exigence, et les précautions qu’il est nécessaire de prendre lorsque l’on désire identifier et gérer des exigences dans le cadre de l’ingénierie d’un système donné.

1. Introduction

L’objet de cet article est de mettre en exergue le fort caractère contextuel d’une exigence, et les précautions qu’il est nécessaire de prendre lorsque l’on désire identifier et gérer des exigences dans le cadre de l’ingénierie d’un système donné.

Il n’est pas question dans cet article de paraphraser les innombrables ouvrages[1]sur l’ingénierie des exigences, mais plutôt d’y ajouter un regard épistémologique afin de compléter les techniques que l’on peut trouver dans ces ouvrages avec des principes et bonnes pratiques évitant de tomber dans les écueils classiques lors d’un travail de spécification, comme par exemple :

  • S’engager auprès de son client sur des exigences que l’on ne pourra pas tester.
  • Offrir une visibilité inutile (voire dangereuse) à son client sur des contraintes techniques que l’on impose à ses sous-traitants
  • Ne pas suffisamment cadrer le travail des sous-traitants parce justement l’on ne voulait pas offrir une visibilité inutile (voire dangereuse) à son client sur des contraintes techniques que l’on impose à ses sous-traitants (point précédent)
  • Oublier de cadrer le travail de définition de la stratégie de vérification de votre système.
 

2. Exigence de quel système et pourquoi faire ?

La réponse à cette question est le point clé du caractère contextuel d’une exigence.

Illustrons cela en commençant par synthétiser à dessein schématiquement le chapitre 5 de [POHL-2010]1 :

 

L’ingénierie des exigences consistant en partie à bien définir le contexte du développement d’un système.

La communauté de l’ingénierie système s’accorde à dire que la vérification (branche « remontante » dans le contexte d’un cycle de vie en « V ») est fondamentale, mais ne constitue pas le système mais un autre système (humain, technique, de procédures, …etc) servant à vérifier que le système fourni correspond bien à ce qui a été demandé. Pour ce faire, l’ingénierie du système nous amènera sans doute à ajouter des exigences supplémentaires  à destination du système de vérification (éléments de stratégie, de moyens, etc.):

 

 

De plus, faire de l’ingénierie système est de plus en plus synonyme de répartir la prise en charge de l’ingénierie de différents sous-systèmes par des sous-traitants, il faut donc là aussi que l’ingénierie prenne en charge cet aspect :

 

 

En termes d’ingénierie, le système de vérification peut être considéré comme un sous-système un peu particulier et comme tous les sous-systèmes peuvent aussi être considérés comme des systèmes à part entière, on peut aboutir au schéma suivant qui structurera le discours de cet article :

 

 

C’est pour cela qu’à chaque fois qu’un analyste système manipule quelque chose qu’il pense être une exigence, il est fondamental qu’il se pose la question : « Ceci participe t-il à la spécification mon système ? Du contexte de mon système ? D’un de mes sous-systèmes ? Du contexte d’un de mes sous-systèmes ? Du contexte du système de vérification ?

Une fois que la réponse a été obtenue il est très important de savoir à quoi cette exigence sera t-elle utile.

 

2.1. Pour quel système ?

Dans ce chapitre nous allons analyser en fonctions de réponses possibles à ces questions les bonnes pratiques à mettre en œuvre par l’analyste système.

Considérons qu’un analyste système travaille sur la rédaction de la spécification de son système, en réponse aux besoins formulés par son client dans un cahier des charges, est qu’à ce moment-là il désire ajouter à sa spécification une assertion particulière.

Soit : « un débit minimum de 25 images par secondes sera proposé 7 jours sur 7 ».

Si la réponse à la question « Ceci participe t-il à la définition de mon système ? » est « à priori oui », l’analyste système doit tout d’abord identifier (de manière unique) son assertion comme étant une exigence et lui donner un titre qui soit aussi (de préférence) un identifiant unique.

Cette recherche de titre, si elle est difficile indique le flou sémantique associé à l’assertion et il est fortement recommandé de procéder à une reformulation.

Ensuite, l’analyste système doit considérer la question suivante : « Est ce que le responsable de la vérification de mon système (très souvent c’est de la responsabilité de celui qui spécifie ce système) sera en mesure de vérifier cela sur le système ? »

Si la réponse est oui, il est possible que cette assertion soit effectivement une exigence du système, mais elle doit maintenant être accompagnée d’éléments supplémentaires permettant de définir les besoins du système de vérification associé, comme par exemple que « la vérification devra être faite en conditions opérationnelles au moins pendant 1 mois avant que considérer l’exigence comme vérifiée » ; cette nouvelle assertion spécifie le contexte du système de vérification et non pas le système en lui-même.

Si vous (ou ceux responsables de la vérification du système) n’ont pas les moyens de faire cette vérification, il faut se poser la question si ce ne serait pas le client qui en aurait les moyens.

Si tel est le cas, il est possible que ce que vous croyiez être une exigence du système soit en fait un besoin (donc pas de votre responsabilité, car vous êtes en train de définir le domaine du problème que vous avez à résoudre et non pas votre système).

Si ce n’est pas le cas, Peut–être qu’en fait c’est un de vos sous-traitants dans le cadre d’un des sous-systèmes qui aurait manifestement les moyens de vérifier cela. Si tel est le cas, alors cela veut dire que ce que vous croyiez être une exigence de votre système est en fait un élément de contexte (un besoin) pour un de vos sous-systèmes.

 

Bien entendu, parfois lors de l’analyse de l’assertion on se rend compte immédiatement qu’elle ne définit pas le système considéré, mais le système de vérification du système considéré où bien alors un de ses sous-systèmes.

Voici ci-dessous une vision globale de l’enchaînement des questions/réactions à se poser pour traiter correctement une exigence :

 

  

2.2. Pour en faire quoi ?

Que ce soit :

  • une exigence du système qui fournit à un élément de réponse à un besoin client,
  • un élément de contexte du système de vérification qui constitue une des contraintes pour bâtir le système de procédures de vérifications et éventuellement les appareillages idoines
  • un élément de contexte d’un sous-système qui constitue une demande précise à formuler à un sous-traitant

… tout ceci n’est qu’exigences, ce n’est qu’une question de point de vue.

En effet une demande particulière que vous pourriez faire à un de vos sous-traitant est le résultat de votre travail d’analyse du besoin de votre client en vous basant sur votre savoir-faire.

 

Il est donc très important que vous sachiez ce à quoi devra servir une exigence au moment où vous la rédigez :

Une exigence de votre système doit servir à :

–> Etre un élément de réponse pour votre client. Il faudra donc :

  • Rédiger en termes compréhensibles pour votre client
  • Etablir la traçabilité avec le besoin de votre client
  • Justifier auprès de votre client, si cela ne va pas de soi, votre élément réponse (exigence système)

–> Servir de base à un travail de conception

  • Pour les exigences fonctionnelles : allocation sur les sous-systèmes + éléments de stratégies pour l’obtention d’éléments de contexte pour les sous-systèmes alloués
  • Pour les exigences non-fonctionnelles : définitions des axes d’analyses devant amener à des choix de conceptions particuliers sur les sous-systèmes
  • Définition d’éléments de stratégies de vérifications (allocation de moyens de tests, planification de campagne, etc.)

 

Un élément de contexte d’un des sous-systèmes (définition des besoins sur le sous-système) :

  • Servir de base pour une relation contractuelle

 

Un élément de contexte du système de vérification :

  • Permettre de cadrer les moyens le vérifications à mettre en œuvre afin d’optimiser les coûts de vérifications.

 

3. Conclusion

On considère une assertion comme étant une exigence que parce que l’on a un point de vue particulier sur cette assertion (Une exigence pour vous peut être le résultat du travail de quelqu’un d’autre qui lui-même répondait à d’autres exigences).

L’intention qui anime le travail de l’analyse système lorsqu’il définit l’exigence peut être très variable et les processus de gestions voir la manière de les rédiger (ou décrire) doivent être adaptés.

Si cette considération n’est pas prise en compte le risque est grand que l’activité de gestion des exigences ne se transforme en élaboration de liste à la Prévert sur laquelle il devient difficile de baser un travail d’ingénierie digne de ce nom.

 
Auteur: Joseph ARACIC 

© Crescendo Technologies


[1] Parmi les ouvrages existant sur l’ingénierie des exigences je voudrais cependant en citer un qui je pense se distingue de beaucoup d’autres par sa qualité : « Requirement Engineering » de Klaus Pohl aux éditions Springer – [POHL-2010]. Je vous recommande vivement sa lecture.

 
Share on Facebook
Share it on Viadeo
Share on LinkedIn
Post on Twitter
Google Buzz (aka. Google Reader)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>