La délégation de vérification d’exigence

[Cette article est aussi disponible aussi en Anglais]

Le propos dans cet article se focalise sur une bonne pratique de gestion très profitable lorsque :

  • la demande d’un client (le contexte du système) est exprimée de manière « pléthorique »
  • les moyens de vérifications systèmes sont coûteux

1. Introduction

Cet article est le second d’une série d’articles sur l’ingénierie des exigences publiée par Crescendo Technologies et dont le premier « Ceci n’est pas une exigence … du système »  invitait à se poser les bonnes questions lorsque l’on rédige une spécification système, c’est-à-dire la réponse technique à une demande formulée par le client (le contexte) :

Figure 1: Engagements en réponse à une demande client (le contexte)

Le propos dans ce second article se focalise sur une bonne pratique de gestion très profitable lorsque :

  • la demande d’un client (le contexte du système) est exprimée de manière « pléthorique »
  • les moyens de vérifications systèmes sont coûteux

Ces caractéristiques sont souvent présentes dans les domaines de la défense ou de l’aéronautiques dont est issu la bonne pratique exposée dans cet article.

Cette pléthore d’exigences dans l’expression de sa demande par un client est souvent le résultat de son passé très industriel; il a tendance souvent à formuler son besoin en imposant un grand nombre de contraintes[1][3].

Le propos ici ne sera pas d’aborder la gestion de la pertinence de ces contraintes, tant aussi bien d’un point de vue du fond que de celui de la forme,  qui relève en ingénierie des exigences de techniques d’élucidations et/ou de négociations[2].

Dans ce qui suit, nous allons nous préoccuper du mode de traitement d’une exigence provenant d’un client selon la nature de l’effort de vérification à effectuer, et ce sous le prisme d’une technique dite de « délégation de vérification d’exigence ».

Correctement appliquée, cette technique permet d’éviter un écueil classique dans le traitement des exigences du client (le contexte), lorsque l’on définit l’engagement système que l’on est prêt à prendre  pour répondre à sa demande, et ce au travers de la rédaction d’une spécification de son système.

Cet écueil est de vouloir formuler systématiquement son engagement en rédigeant des « exigences systèmes » satisfaisant l’ensemble des « exigences clients ».

Le fait de définir son engagement satisfaisant les contraintes techniques du client de la même manière que celui satisfaisant ses besoins techniques risque de créer une inflation de l’effort de vérification technique au niveau système.

Le fait de traiter une contrainte technique du client en « déléguant » sa vérification permet de définir un engagement de l’équipe système à contrôler que cette contrainte technique sera correctement testée par les sous-traitants des sous-systèmes cibles de la délégation.

2. Distinguer les contraintes des autres exigences du contexte

Qu’est ce qu’une contrainte[1][3]?

C’est une exigence qui est exprimée dans le domaine de la solution.

Plus prosaïquement, c’est une exigence qui ne définit pas un besoin, mais une manière de répondre à un besoin, qui lui-même n’est peut être pas exprimé. Exemple :

« La source d’énergie électrique doit pouvoir être obtenue par deux piles alcaline type LR6 »

Outre le fait que la contrainte imposée par le client n’est peut-être pas justifiée (mais c’est un autre débat : cf. élucidation et négociation des exigences), on voit bien que cette exigence impose dans la solution des choix précis.

Partons du principe que l’on décide d’accepter la contrainte du client telle quelle :

Dans ce cas l’ingénieur système fera sans doute (c’est même fortement conseillé) un travail d’analyse d’impact système pour alimenter sa spécification système au travers des engagements de type « exigences systèmes »:

  • « Le système disposera d’un accès direct et sans outillage au compartiment de puissance, sur la façade arrière »
  • « Le système sera utilisable en continu et à pleine puissance pendant au moins 24 heures »

Mais l’on ne pourra pas considérer que ces exigences systèmes répondent à l’exigence du client énoncée plus haut.

L’exigence du client « La source d’énergie électrique doit pouvoir être obtenue par deux piles alcalines type LR6 » est donc une contrainte.

Le parti pris de la bonne pratique présentée dans cet article est de ne pas chercher à formuler une exigence système répondant à une contrainte du client.

 Figure 2: Les exigences systèmes ne satisfont pas les contraintes du client

Le fait de ne chercher à satisfaire par des exigences systèmes QUE les besoins clients entraîne les effets bénéfiques suivants sur la rédaction des exigences systèmes :

1. Il y en a moins

2. La lecture par le client de la spécification système est plus agréable car il n’y perçoit pas de paraphrase de son besoin (voire des copier/coller).

    a. Il en résulte aussi un sentiment de cohérence et de forte valeur ajoutée de la réponse système par rapport à sa demande.

3. Une plus grande facilité à définir la stratégie de vérification système car elle ne devra pas prendre en compte des exigences de bas niveau dont on n’a pas souvent (ou difficilement) les moyens de vérifier à notre niveau système.

Une technique de base (mais quoique faillible) permettant de repérer qu’une exigence client est une contrainte est de faire une analyse d’allocation de l’exigence du client sur les sous-systèmes de niveau juste inférieur à notre système.

Si l’on arrive à allouer sur plusieurs sous-systèmes, il y a des chances que l’exigence du client ne soit pas une contrainte. Attention toutefois de ne pas en faire un dogme. Exemple :

« L’avion doit être complètement rose », car cette exigence client par exemple s’alloue très facilement aux sous-systèmes « fuselage », « ailes », et « roues », et pourtant on ressent bien la nature de contrainte de l’exigence et qu’il n’est pas pertinent d’y apporter une réponse système ; nous allons donc déléguer à ces trois sous-systèmes la vérification de cette contrainte client.

3. La technique de délégation

Une fois la nature de contrainte d’une exigence client établie, et bien que l’on n’essaiera même pas d’y apporter une réponse en mettant en face des exigences systèmes (cf. chapitre précédent), il est toutefois hors de question de ne pas la traiter dans la démarche d’ingénierie système, et il est impératif de prouver à votre client votre engagement sur ses exigences pour lesquelles vous n’avez pas fourni une réponse système (avec des exigences système)

Ce traitement, consiste à :

  • « transférer » la contrainte en un besoin pour un (ou plusieurs des sous-systèmes)
  • mettre en place les moyens de valider la stratégie de vérification que votre (vos) sous-traitant(s) envisagera (envisageront)
  • mettre en place les moyens de s’assurer pour votre client de la remontée des preuves de vérification que vous aura (auront) fournies votre (vos) sous-traitant(s)

3.1. Transfert de la contrainte

Ce transfert s’effectue sur la base du travail d’allocation qui a été effectué sur les exigences du client (cf. chapitre 2 « Distinguer les contraintes des autres exigences du contexte »), nous allons maintenant transférer la contrainte sur les sous-systèmes alloués.

Il s’agit en fait de faire en sorte que la contrainte client devienne une exigence pour les sous-systèmes alloués, et ce sans passer par une exigence système intermédiaire :

 Figure 3: Transfert d’une contrainte à un sous-système par délégation

 

Une traçabilité entre l’exigence dans le cahier des charges pour le sous-système X et la contrainte client doit bien entendu exister mais sa sémantique (« correspond à la délégation de » par exemple) doit être différente de celle entre les exigences systèmes de votre réponse et des besoins du client (« satisfait » par exemple). Ceci permettra une meilleure maîtrise de votre système d’informations.

Il est tout à fait possible (voire souvent recommandé) de devoir reformuler la contrainte telle qu’elle a été formulée par votre client avant de la transférer à votre (vos) sous-traitant(s).

La contrainte de votre client :

« La source d’énergie électrique doit pouvoir être obtenue par deux piles alcaline type LR6 »

… peut donc être reformulée :

« Il est impératif de pouvoir utiliser des piles de type LR6 pour alimenter le système » :

 

Figure 4: transfert d’une contrainte à un sous-système par délégation avec reformulation

Il est important de noter que cette reformulation n’est à priori pas visible par le client (celui-ci aura connaissance de la délégation sur le sous-système et des moyens de vérifications de sa contrainte).

Cette reformulation, dans certains cas, peut-être plus profonde :

« Il est impératif, pour alimenter le système, de pouvoir utiliser des piles de type LR6, LR3, LR4 »

et dans ce cas doit trouver une justification supplémentaire qui peut se trouver dans une exigences de votre spécification système :

« Il faut pouvoir alimenter le système en utilisant des batteries très communément disponibles dans les grandes surfaces commerciales »

 Figure 5: Délégation d’une contrainte avec reformulation et justification au niveau système

D’une manière générale, le travail de délégation de la vérification d’une contrainte client ne doit pas vous affranchir d’une analyse d’impact système qui pourrait vous amener à produire des exigences système et/ou modifier votre architecture système.

Dans le cas d’une contrainte client, votre engagement réside dans le fait que :

  • vous mettrez en œuvre les moyens de valider les moyens de vérifications qui seront mis en œuvre pour la contrainte client
  • vous allez remonter au client les preuves de la bonne vérification de sa contrainte.

Vous devrez donc, en guise d’engagement, fournir à votre client :

  • une matrice de réponse système permettant de présenter la traçabilité de ses besoins avec vos exigences systèmes
  • une matrice de délégation permettant de présenter l’allocation de ses contraintes avec les sous-systèmes, ainsi que le moyens que vous avez définis pour la vérification des ces contraintes.

Figure 6: Les matrices de traçabilité à fournir au client du système 

3.2. Remontée de preuves et traçabilité

Un de vos rôles vis-à-vis de votre client est de lui assurer que le système que vous allez lui livrer corresponde bien à ce sur quoi vous vous êtes engagé (et pour lequel il était d’accord).

Vos engagements techniques sur le système sont définis dans votre réponse (Spécification système), et vous avez aussi défini un ensemble de procédures de vérification destinées à vérifier que votre système respecte bien ces engagements.

Grâce à la traçabilité que vous aurez mise en place entre les exigences du client et vos propres exigences systèmes (engagements techniques) il vous sera possible de compiler un rapport à destination de votre client prouvant que le système respecte bien vos engagements :

Figure 7: Chemin de traçabilité de preuves systèmes

Or, cette traçabilité ne prend pas en compte les contraintes du client.

Vous devrez donc pour ces contraintes, puisque vous en avez délégué la vérification aux responsables de vos sous-systèmes (cf. chapitre précédent), utiliser un autre schéma de traçabilité :

Figure 8: Chemin de traçabilité des preuves sous-systèmes 

C’est pour cela qu’il est important que vous demandiez à vos sous-traitants (ceux responsables de vos sous-systèmes) de vous fournir la liste des preuves de vérifications qu’ils ont obtenues avec la traçabilité avec vos exigences (celles du cahier des charges du sous-système) afin de pouvoir remonter les preuves à votre client.

Il est bien entendu que la remontée des preuves fournies par vos sous-traitants ne s’effectuent pas « telles quelles », et selon la nature de la délégation doivent être formatés et/ou reformulées.

4. Conclusion

La délégation de la vérification d’exigences est une technique relativement simple à mettre en place en termes de système d’informations, et elle permet d’améliorer très substantiellement la qualité des processus d’ingénierie des exigences et d’ingénierie système :

  • Par une amélioration du processus de négociation/élucidation, car il permet de détecter des contraintes risquées en termes d’implémentation mais sans trop d’impact d’un point de vue « fonctionnel »
  • Le fait de distinguer parmi les exigences de votre client les contraintes des réels besoins utilisateurs, permet de faciliter l’écriture de la réponse système, la rendant ainsi plus claire, tout en renforçant le sentiment de confiance dans l’engagement pris car vous avez de manière bien plus sûre les moyens et les compétences pour le vérifier.
  • En conséquence, les plans de vérification système seront eux aussi plus simples à appréhender, car vous n’aurez pas à faire un grand écart en vérifiant, par exemple, d’un côté le respect d’une performance opérationnelle et de l’autre côté le respect de la procédure de fabrication d’une pièce enfouie de votre système.
  • En outre, cette dichotomie effectuée afin de distinguer les vérifications devant être menées au niveau système de celles devant être menés au niveau sous-système permet d’éviter substantiellement des redondances de vérifications qui au final alourdissent la note au niveau système.

Il est important de noter que cet article propose une démarche « simplifiée » à des fins pédagogiques.

Dans le monde réel de l’ingénierie système, il faut mettre en perspective cette démarche avec :

  • les processus de négociations avec les clients et fournisseurs
  • la gestion des risques sous-traitants
  • la gestion des interfaces entre sous-systèmes et les techniques d’intégration de systèmes

5. Références bibliographiques

[1]        IEEE Std 1233-1998, IEEE Guide for Developing System Requirements Specifications, 1998.

[2]        IREB Certified Professional for requirement engineering. Syllabus – Fundation Level –

[3]        Guide to the Systems Engineering Body of Knowledge (SEBoK) 

 

Auteur: Joseph ARACIC 

© Crescendo Technologies

 

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>