Ne pas oublier de définir « en combien de secondes faut-il répondre » : organiser les exigences non fonctionnelles avec le Non-Functional Requirements Grade de l'IPA

« On nous a dit que les transitions d’écran étaient lentes, mais ni le contrat ni le cahier des charges ne précisent d’accord sur le temps de réponse. »

« Le traitement de nuit ne se termine plus avant le matin, mais personne n’avait estimé de combien le volume de données augmenterait au fil des ans. »

« Ce n’est qu’après une panne serveur ayant arrêté le système pendant une demi-journée que nous avons réalisé n’avoir jamais vérifié, au moment de la commande, la configuration prévue pour un rétablissement en combien d’heures. »

Quand on pense aux problèmes de développement logiciel, on imagine souvent un décalage de compréhension sur les fonctionnalités. Pourtant, ce qui provoque réellement des litiges une fois l’exploitation commencée est bien souvent l’oubli de définir ces exigences hors fonctionnalités, ce que l’on appelle les exigences non fonctionnelles.

L’outil public conçu pour prévenir ce type d’oubli est le Non-Functional Requirements Grade de l’IPA (Information-technology Promotion Agency, agence administrative indépendante). Cet article présente son contenu ainsi qu’une méthode d’utilisation réaliste pour le système métier d’une PME, dans des termes accessibles au client.

1. L’essentiel d’abord

• Les exigences non fonctionnelles ne portent pas sur « ce que fait » le système, mais sur « avec quelle qualité et dans quelles conditions » il fonctionne. Elles se répartissent en six domaines : disponibilité, performance, exploitation, migration, sécurité et environnement d’installation
• Le Non-Functional Requirements Grade est un ensemble d’outils (gratuits) de l’IPA qui recense de façon exhaustive les points de ces six domaines et permet au client et au prestataire de s’accorder sur des niveaux progressifs
• Il n’est pas nécessaire de remplir tous les points. L’usage prévu consiste à choisir le « système modèle » le plus proche du sien, puis à ajuster en priorité les points importants selon sa propre situation
• Plus le niveau non fonctionnel exigé est élevé, plus le coût augmente. Plutôt que d’« exiger vaguement un niveau élevé », il faut choisir le niveau en partant de l’impact sur l’activité
• Les décisions doivent être consignées dans le document de définition des exigences. Les hypothèses ainsi fixées permettent de comparer les devis équitablement et d’éviter les désaccords de type « on n’a jamais dit ça » une fois l’exploitation commencée

2. Qu’est-ce qu’une exigence non fonctionnelle — ce qui se situe entre « fonctionner » et « être utilisable »

Les exigences fonctionnelles sont des exigences sur ce que fait le système, comme « pouvoir enregistrer une commande » ou « pouvoir imprimer un état ». Les réunions de développement se concentrent naturellement sur ce type de sujet.

En revanche, les questions suivantes n’apparaissent jamais dans une liste de fonctionnalités.

• À quelles heures ce système doit-il fonctionner ? Qu’en est-il le week-end ? Pendant le traitement de nuit ?
• En cas de panne, dans combien d’heures faut-il rétablir le service pour que l’activité ne soit pas bloquée ? Jusqu’à quel point dans le temps la perte de données est-elle acceptable ?
• Combien d’utilisateurs simultanés, et combien de transactions par jour ? De combien le volume de données aura-t-il augmenté dans cinq ans ?
• Qui surveille le système, effectue les sauvegardes et reçoit la première alerte en cas de panne ?
• Jusqu’où les données de l’ancien système doivent-elles être reprises dans le nouveau ?

Ce sont là les exigences non fonctionnelles. Ce qui les rend délicates, c’est que le système « fonctionne » plus ou moins même sans les avoir définies. Le problème ne se révèle qu’une fois l’exploitation commencée, la charge en hausse, et une panne survenue. Et à ce stade, comme cela touche aux fondements de la configuration serveur et de la conception, la correction coûte très cher.

3. Qu’est-ce que le Non-Functional Requirements Grade

Le Non-Functional Requirements Grade est un ensemble d’outils publié par l’IPA dans le but d’éviter les malentendus entre client et prestataire au sujet des exigences non fonctionnelles. La première version a été publiée en avril 2010, et la version actuelle la plus récente, qui reflète les évolutions autour de la sécurité et de la virtualisation (le cloud), est le « Non-Functional Requirements Grade 2018 » (publié en avril 2018). Il se trouve aujourd’hui sur une page archivée du site de l’IPA, mais reste, en pratique, une référence incontournable pour vérifier qu’aucune exigence non fonctionnelle n’a été oubliée.

Il se compose des outils suivants.

Chaque indicateur dispose d’un ensemble défini de niveaux progressifs, ce qui permet d’exprimer une exigence comme un choix de niveau plutôt que par un mot vague comme « élevé » ou « faible ».

Les trois systèmes modèles

Autre particularité : trois systèmes modèles, répartis selon l’ampleur de l’impact sociétal qu’entraînerait l’arrêt du système.

• Systèmes ayant un impact sociétal quasi nul
• Systèmes ayant un impact sociétal limité (systèmes cœur de métier d’une entreprise, par exemple)
• Systèmes ayant un impact sociétal extrêmement important (infrastructures sociales, par exemple)

Le tableau des niveaux comporte déjà un niveau de référence pour chaque modèle. Autrement dit, plutôt que de partir de zéro, on peut d’abord identifier « notre système est proche de tel modèle », puis ajuster les niveaux à la hausse ou à la baisse selon sa propre situation.

4. Les six grandes catégories — traduites dans le langage du client

En reformulant les six grandes catégories du Non-Functional Requirements Grade en questions auxquelles le client peut répondre, on obtient ceci.

Vu ainsi, on comprend que la plupart de ces six grandes catégories relèvent de questions métier plutôt que de questions techniques. C’est le client, et non la société de développement, qui peut répondre à « que se passe-t-il si le traitement de facturation de fin de mois prend une demi-journée de retard ? ». L’initiative sur les exigences non fonctionnelles appartient en réalité au client.

5. Une utilisation réaliste — ne pas chercher à remplir les 238 points

La liste des indicateurs comporte 238 métriques, mais les discuter toutes une par une n’est pas réaliste pour un projet de PME, et le guide d’utilisation ne prévoit d’ailleurs pas cet usage. Le déroulement prévu est le suivant.

1. Choisir un système modèle
   (à quel niveau d'impact mon système est-il le plus proche ?)
        ↓
2. Pour les points importants du tableau des niveaux,
   ajuster à partir du niveau de référence du modèle selon sa propre situation
        ↓
3. N'approfondir que les parties nécessaires avec la liste des indicateurs

Pour une application métier de PME, l’étape 2 — « la mise en cohérence des points importants » — suffit déjà à elle seule à apporter une réelle valeur. Par expérience, je recommande de documenter au minimum les points suivants lors de la définition des exigences.

• Les plages horaires de fonctionnement et l’impact métier en cas d’arrêt (disponibilité)
• L’intervalle des sauvegardes et, en cas de panne, « jusqu’à quel moment » les données seront restaurées et « en combien d’heures » (disponibilité / exploitation)
• Le volume et le nombre d’enregistrements actuels, et la projection à quelques années (performance / évolutivité)
• Les valeurs cibles pour le temps de réponse et le temps de traitement par lots. Même « au moins équivalent au système actuel » convient, du moment qu’une référence est fixée (performance)
• La répartition des responsabilités pour la surveillance, les sauvegardes et la première intervention en cas de panne (exploitation / maintenabilité)

Il ne faut pas oublier, à ce stade, le compromis entre niveau et coût. Viser par exemple « un système qui ne s’arrête jamais » fait grimper les coûts en flèche à cause de la redondance des serveurs et du dispositif de surveillance. Si l’on peut juger que « tant que l’activité peut attendre le lendemain matin, un rétablissement dans la journée suffit », ce budget peut être réorienté ailleurs. La bonne façon d’utiliser les niveaux du Non-Functional Requirements Grade n’est pas de servir d’outil pour exiger toujours plus, mais de constituer un langage commun pour discuter de l’équilibre entre impact métier et coût.

6. La relation avec les contrats et les devis

Les exigences non fonctionnelles sont aussi directement liées au contrat.

D’abord, la comparaison des devis. Si l’on obtient des devis de plusieurs sociétés sans avoir aligné les hypothèses non fonctionnelles, la société A peut avoir chiffré une configuration redondante, et la société B, un serveur unique. Le client perd alors la capacité de distinguer si un écart de prix reflète une différence de configuration ou simplement une estimation trop optimiste.

Ensuite, la recette et la période suivant la mise en service. Si les accords sur le temps de réponse et les sauvegardes sont documentés, une dispute stérile du type « c’est lent » contre « ce n’était pas prévu » se transforme en une simple vérification des faits par rapport à une référence.

Le Contrat et modèle de transaction pour systèmes d’information de l’IPA prévoit lui aussi que les exigences non fonctionnelles soient documentées comme livrable de la phase de définition des exigences. Le Non-Functional Requirements Grade s’intègre naturellement dans un déroulement contractuel à plusieurs étapes, où la définition des exigences est menée sous forme de quasi-mandat, puis où le développement, une fois le contenu arrêté, fait l’objet d’un contrat d’entreprise. Pour en savoir plus sur cette structure contractuelle, voir notre article sur le Contrat modèle de l’IPA.

Résumé

Récapitulons les points clés du Non-Functional Requirements Grade de l’IPA.

• Les exigences non fonctionnelles portent sur « avec quelle qualité et dans quelles conditions » le système fonctionne. Il fonctionne même sans les avoir définies, mais les problèmes émergent et créent des litiges une fois l’exploitation commencée
• Le Non-Functional Requirements Grade est un ensemble d’outils gratuits de l’IPA permettant d’aligner, à des niveaux progressifs, six grandes catégories — disponibilité, performance/évolutivité, exploitation/maintenabilité, migrabilité, sécurité et environnement système — représentant 238 indicateurs
• En partant des niveaux de référence des trois systèmes modèles, on ajuste d’abord les points importants. Il n’est pas nécessaire de remplir tous les points
• Le contenu des six grandes catégories relève surtout de questions métier. C’est le client qui détient les réponses
• Plus le niveau est élevé, plus le coût augmente. Il faut choisir l’équilibre en partant de l’impact métier, et consigner le résultat dans le document de définition des exigences

Décider à l’avance « avec quelle qualité le système doit continuer à fonctionner », tout autant que « ce qu’il faut construire ». C’est le moyen le plus économique d’éviter à la fois un système qui fonctionne sans être utilisable, et les litiges qui en découlent.

Vous avez du mal à structurer les exigences d’un système métier ?

La mise en cohérence des exigences non fonctionnelles demande d’aller et venir entre la réalité opérationnelle (périodes de pointe, volume de données, impact d’un arrêt) et la configuration système qui doit y répondre.

KomuraSoft LLC (合同会社小村ソフト), lors de consultations sur le développement sous contrat ou la modification d’applications métier Windows et de systèmes web, travaille avec ses clients pour structurer, dès la phase des exigences, la performance, l’exploitation et le comportement en cas de panne, en suivant la logique présentée dans cet article. N’hésitez pas à nous consulter, même dès le stade de « le traitement de notre système actuel devient progressivement plus lent » ou « nous aimerions revoir nos règles d’exploitation à l’occasion d’une mise à jour ».

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Qu'est-ce qu'une exigence non fonctionnelle ?

Ce sont des exigences relatives à « avec quelle qualité et dans quelles conditions » un système fonctionne, par opposition aux exigences fonctionnelles qui portent sur « ce que le système fait ». Cela comprend par exemple : à quel moment le système doit être disponible (disponibilité), combien d'utilisateurs simultanés il doit supporter et en combien de secondes il doit répondre (performance et évolutivité), qui l'exploite et le maintient, et comment (exploitabilité et maintenabilité), comment les données de l'ancien système sont reprises (migrabilité), quelles protections mettre en place (sécurité), et dans quel environnement il est installé (environnement système). Oublier de les définir conduit souvent à un système qui « fonctionne » mais qui n'est pas réellement utilisable.

Le Non-Functional Requirements Grade est-il gratuit ? Où peut-on se le procurer ?

Oui, vous pouvez le télécharger gratuitement depuis le site de l'IPA. L'ensemble comprend un tableau des niveaux, une liste complète des indicateurs, un diagramme arborescent, une feuille de travail, ainsi qu'un guide d'utilisation en trois volumes (explication, usage, application). La version la plus récente est le « Non-Functional Requirements Grade 2018 », publiée en avril 2018. Elle se trouve aujourd'hui sur une page archivée du site de l'IPA, mais reste largement utilisée en pratique comme référence pour vérifier qu'aucune exigence non fonctionnelle n'a été oubliée.

Faut-il définir les 238 points un par un ?

Non. Même le guide d'utilisation ne présuppose pas qu'il faille discuter chaque indicateur un par un. L'approche par étapes qu'il propose consiste à d'abord choisir le système modèle le plus proche du sien pour fixer un niveau de référence global, puis à ajuster les points importants du tableau des niveaux en fonction de sa propre situation, et enfin à approfondir uniquement les parties nécessaires à l'aide de la liste complète des indicateurs. Pour le système métier d'une PME, s'accorder uniquement sur les points importants suffit déjà à éviter la plupart des litiges liés à des exigences oubliées.

Quand faut-il définir les exigences non fonctionnelles ?

Dès la phase de définition des exigences. Les objectifs de disponibilité et de performance touchent aux fondements de la configuration serveur et de la conception, si bien que les modifier une fois le développement engagé a un impact important sur le coût et les délais. Le Contrat et modèle de transaction pour systèmes d'information de l'IPA prévoit également que les exigences non fonctionnelles, et pas seulement les exigences fonctionnelles, soient documentées comme livrable de la phase de définition des exigences. Sans avoir aligné les hypothèses non fonctionnelles avant de comparer les devis, il devient impossible de savoir si un écart de prix reflète une différence de configuration ou simplement une estimation trop optimiste.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.