Analyse des exigences non fonctionnelles

Objectif

L'analyse des exigences non fonctionnelles spécifie les critères qui servent à juger le fonctionnement d'une solution plutôt que ses comportements précis. Une exigence fonctionnelle décrit un comportement: le portail émet un décompte de primes, le système enregistre un changement d'adresse. Une exigence non fonctionnelle décrit la qualité de ce comportement: le décompte s'affiche en moins de deux secondes, le portail reste accessible 99,8% des heures de service, les données de santé sont chiffrées au repos. La technique existe parce que cette seconde moitié décide, à elle seule, si les utilisateurs acceptent la solution: un service exact mais lent, indisponible aux heures de pointe ou non conforme à la protection des données échoue en exploitation même quand chacune de ses fonctions est correcte.

Les ENF portent aussi le nom d'attributs de qualité ou d'exigences de qualité de service. On les associe volontiers aux systèmes informatiques, à tort: elles s'appliquent tout autant au volet humain et au volet processus d'une solution. Un processus a une exigence de délai, un poste de travail une exigence d'ergonomie, une équipe une exigence de disponibilité. Une ENF fait l'une de trois choses: elle complète une exigence fonctionnelle, elle lui impose une contrainte ou elle décrit un attribut de qualité que la solution doit exhiber.

La technique répond aussi à une question que les exigences fonctionnelles ne posent jamais: jusqu'où pousser la qualité, sachant qu'elle se paie. Un attribut poussé à son maximum en tend un autre et alourdit le coût. La sécurité et la performance se disputent le même temps de réponse, la disponibilité et le budget se disputent la redondance, l'utilisabilité et la richesse fonctionnelle se disputent l'écran. Le travail de l'analyste est alors de composer le portefeuille d'ENF le plus utile dans un contexte donné, chaque seuil tenu au niveau que le contexte justifie plutôt qu'au maximum atteignable. Déterminer ce portefeuille optimal est au centre de la valeur que la technique délivre.

Le livrable est un catalogue d'exigences non fonctionnelles: un référentiel où chaque ligne porte un attribut de qualité, un énoncé déclaratif, une métrique, un seuil, une source et une méthode de vérification. Sa valeur tient à un enchaînement mesurable = testable = vérifiable. Une ENF assortie d'un seuil devient un critère d'acceptation que l'on rejoue au moment des tests, et son verdict est binaire: le seuil est tenu ou il ne l'est pas. Le bénéfice se mesure à un test simple: le jour de la recette, chaque exigence de qualité produit un test qui passe ou qui échoue, sans arbitrage sur ce que « rapide » voulait dire.

Usage

Quand l'utiliser

• Solution dont l'exploitation porte l'enjeu: la qualité de service décide de l'adoption autant que les fonctions elles-mêmes.
• Exigence de qualité formulée en termes vagues: « rapide », « facile », « fiable » à convertir en seuils testables avant tout développement.
• Attributs de qualité en concurrence: sécurité, performance et coût se disputent la même solution, l'arbitrage doit être posé et tracé.
• Contrainte imposée du dehors: régulateur, norme de certification ou accord de niveau de service qui fixe une qualité minimale opposable.
• Rédaction de critères d'acceptation: chaque ENF quantifiée alimente directement la recette et le plan de tests.
• Décision d'architecture ou d'appel d'offres: les seuils de disponibilité, de performance et de sécurité départagent les variantes techniques.
• Extension internationale ou multilingue: la localisation et la conformité deviennent des exigences chiffrées propres à chaque juridiction.
• Reprise d'un système en exploitation: mesurer les niveaux de service tenus aujourd'hui pour poser les seuils que le successeur devra au moins égaler.

Quand ne pas l'utiliser

• Attribut irréductiblement qualitatif: aucune métrique honnête n'existe, recueillir plutôt un jugement d'acceptation structuré auprès des utilisateurs qu'imposer un seuil arbitraire.
• Prototype ou preuve de concept jetable: la solution ne verra jamais l'exploitation, renoncer au catalogue formel et ne cadrer que les rares contraintes qui bloqueraient la démonstration.
• Source de l'exigence encore instable: réglementation ou périmètre en cours de définition, fixer un seuil maintenant fige une cible fausse, attendre la stabilisation du contexte.

Description

Les catégories d'attributs de qualité

Une ENF appartient toujours à une catégorie d'attribut de qualité, et la liste des catégories est l'inventaire que l'analyste balaie pour ne pas oublier une dimension. Le BABOK en énumère une quinzaine, et le référentiel de rattachement est la norme ISO/IEC 25010, le modèle de qualité des produits logiciels de la série SQuaRE. La révision de 2023 organise la qualité en neuf caractéristiques: aptitude fonctionnelle, efficience de performance, compatibilité, capacité d'interaction (l'ancienne utilisabilité), fiabilité, sécurité, maintenabilité, flexibilité (élargie depuis la portabilité, elle couvre désormais l'adaptabilité, l'évolutivité et la remplaçabilité) et sûreté (nouvelle). Chaque caractéristique se décline en sous-caractéristiques mesurables.

Les catégories que l'on rencontre le plus souvent en analyse d'affaires méritent une définition, parce que c'est la catégorie qui suggère la métrique. La disponibilité mesure la part du temps où la solution est opérable quand on en a besoin, en général un pourcentage sur une plage de service définie. L'efficience de performance mesure la ressource consommée pour rendre un service et se décline par contexte (heure de pointe, heure creuse). La fiabilité mesure la capacité à tenir la fonction sur une durée donnée, souvent par un temps moyen entre pannes. L'évolutivité mesure l'aptitude à absorber une charge accrue. La sécurité protège le contenu et les composants contre l'accès, la modification ou la divulgation accidentels ou malveillants. L'utilisabilité mesure la facilité d'apprentissage et d'usage. La conformité couvre les contraintes réglementaires, financières et légales, qui varient selon la juridiction. La localisation couvre les langues, monnaies, formats et usages locaux. Les accords de niveau de service (ANS), enfin, sont des contraintes convenues formellement entre le fournisseur et l'organisation servie, et ils portent leur propre mesure de succès.

La mesure au cœur de la technique

Une ENF est presque toujours énoncée d'abord en termes vagues, parce que c'est ainsi que les parties prenantes l'expriment: « le processus doit être facile à apprendre », « le système doit répondre vite ». Sous cette forme elle est inutilisable, pour deux raisons qui n'en font qu'une. Le développeur ne sait pas quoi construire, faute de cible. Le testeur ne sait pas quoi vérifier, faute de seuil. La technique consiste à quantifier l'exigence chaque fois que c'est possible, et une mesure de succès appropriée est l'occasion d'une vérification. Les deux transformations canoniques du BABOK l'illustrent:

• « Le processus doit être facile à apprendre » devient « 90% des opérateurs doivent savoir utiliser le nouveau processus après six heures de formation au plus ».
• « Le système doit répondre vite » devient « le système doit fournir 90% des réponses en deux secondes au plus ».

La forme cible porte quatre pièces. Une métrique: ce que l'on mesure (part d'opérateurs autonomes, temps de réponse au 90e centile). Un seuil: la valeur à tenir (90%, deux secondes). Une condition: le contexte de mesure (après six heures de formation, sous charge nominale). Une source: d'où vient le seuil. Pour certaines catégories, la source dicte la mesure sans négociation. La certification renvoie à une norme (une ISO, un standard de branche). La conformité et la localisation sont fixées dans le détail mesurable par leur autorité. Un ANS efficace énonce lui-même sa mesure de succès. L'architecture d'entreprise de l'organisation définit les exigences liées à l'environnement de la solution. La métrique se retrouve souvent auprès de la source qui l'impose.

Le contexte et les conflits entre exigences

La catégorie pertinente et le bon seuil dépendent du contexte. Un régulateur impose de la conformité et de la sécurité, une expansion à l'étranger déclenche de la localisation et de l'évolutivité. Le bon seuil est une propriété du contexte plus que de l'attribut lui-même: une juridiction peut rendre acceptable une cible de performance ou de fiabilité moindre qu'ailleurs, ce qui abaisse légitimement un seuil que l'on aurait cru intangible. Le contexte est enfin dynamique: une ENF se révise ou se retire quand sa source bouge, et l'analyste pèse la stabilité du contexte avant de graver un seuil.

Surtout, l'interaction entre attributs est le vrai sujet. Régler la sécurité au maximum, par un chiffrement lourd et une journalisation exhaustive, dégrade le temps de réponse que vise la performance. Viser une disponibilité extrême multiplie la redondance, donc le coût. Une localisation exhaustive alourdit la maintenabilité, chaque écran existant alors en trois langues. Ces tensions ne se lisent pas ligne à ligne, elles n'apparaissent qu'en regardant le catalogue d'ensemble, et c'est pourquoi la technique produit un catalogue plutôt qu'une collection d'exigences isolées. L'arbitrage se conduit alors explicitement: on nomme les deux attributs en conflit, on désigne celui qui l'emporte dans ce contexte, on consigne le seuil retenu pour chacun et la raison. Une priorité, sur le modèle du classement MoSCoW, rend cet arbitrage lisible: l'exigence impérative tient, l'exigence souhaitable cède la première quand le budget se resserre.

Ce qui fait échouer l'exercice

Laisser l'exigence au stade vague

Une ENF sans métrique ni seuil traverse tout le projet et se règle en litige à la recette, quand la personne qui a dit « rapide » et celle qui a construit « rapide » découvrent qu'elles ne parlaient pas de la même chose.

Inventer un seuil que rien ne fonde

Un « 99,99% » posé pour faire sérieux engage un coût réel sans qu'aucune source ne l'exige. Le seuil se rattache à une attente, un ANS, une norme ou une mesure de l'existant, faute de quoi il est arbitraire.

Surcontraindre

Des exigences trop strictes ajoutent du temps et du coût, et cette lourdeur nuit à l'adoption qu'elles prétendaient servir. Un neuvième chiffre de disponibilité peut coûter davantage que la panne qu'il évite.

Traiter les ENF comme purement informatiques

Le volet processus et le volet humain d'une solution portent leurs propres exigences de qualité, et les ignorer laisse un pan entier de la qualité de service sans cible.

Régler chaque exigence isolément

Les conflits entre attributs (sécurité contre performance, disponibilité contre coût) ne se voient qu'en regardant le catalogue d'ensemble, et une exigence maximisée seule dans son coin en casse une autre en silence.

Oublier de rattacher le seuil à une vérification

Un seuil que rien ne mesure en exploitation est un vœu. Chaque ligne du catalogue nomme la méthode qui prouvera, un jour, qu'elle est tenue.

Considérations IA

Le premier usage utile d'un modèle de langage est la mise en forme de l'exigence vague. À qui lui fournit un énoncé informel (« le portail doit être réactif ») et la catégorie visée, le modèle propose une formulation quantifiée candidate, avec une métrique et un emplacement de seuil à remplir. Il fait la moitié mécanique du travail (la mise au gabarit) et laisse à l'analyste la seule partie qui compte: le choix du seuil et de sa source. Le second usage est le balayage de complétude: on soumet la liste des catégories d'attributs de qualité et la description de la solution, et le modèle signale les catégories pour lesquelles aucune exigence n'est écrite, ce qui remonte les oublis (personne n'avait pensé à la portabilité, à la maintenabilité). Le troisième usage est la détection des conflits: on soumet le catalogue, et le modèle signale les paires d'attributs en tension probable (un seuil de sécurité et un seuil de performance difficilement conciliables), ce qui remonte des arbitrages à instruire que la lecture ligne à ligne laisse passer.

Les limites suivent la nature de la technique. Le seuil est une décision d'affaires, pas une donnée à générer: choisir 99,8% plutôt que 99,9% engage un coût et un risque que seul le métier arbitre, et un modèle qui propose un chiffre plausible masque l'absence de fondement sous une apparence de rigueur. La résolution d'un conflit entre deux exigences (baisser la sécurité pour tenir la performance ou l'inverse) est un arbitrage qui appartient aux responsables concernés, jamais à un outil qui tranche en silence. La subjectivité résiduelle des attributs qualitatifs échappe au modèle: ce qui est « assez rapide » pour un utilisateur ne l'est pas pour un autre, et aucune génération ne remplace la négociation qui aligne les attentes. Enfin, un catalogue d'ENF décrit les défenses d'un système (schémas de chiffrement, seuils de sécurité, points de conformité): le soumettre à un service externe expose une cartographie de vulnérabilités, et ce travail se conduit sur un outillage que l'organisation contrôle.

Exemples

Le catalogue couvre le portail en libre-service d'une caisse maladie de Suisse romande, par lequel les assurés consultent leurs décomptes et déclarent un changement de situation. Il donne une ligne par catégorie d'attribut de qualité, pour montrer la forme cible: chaque exigence porte une métrique, un seuil, une source et une méthode de vérification, et chacune se rejoue comme critère d'acceptation. La colonne qui porte la technique est celle du seuil, parce que c'est elle qui rend l'exigence testable.

Trois lectures sortent du catalogue. La ligne Utilisabilité reprend la métrique canonique du BABOK (90% des opérateurs autonomes après six heures au plus): un attribut réputé subjectif devient une épreuve pratique dont le verdict est binaire. Les lignes Sécurité et Efficience sont en tension, car le chiffrement et la journalisation que la première impose pèsent sur le temps de réponse que la seconde vise, et c'est le catalogue d'ensemble qui rend cet arbitrage visible. La ligne Localisation n'a rien d'accessoire dans un pays à trois langues officielles: les écrans en français, en allemand et en italien et les montants en CHF au séparateur d'apostrophe sont une exigence chiffrée, vérifiée en recette, au même titre que la disponibilité.

Visualisations

Deux artefacts, deux formes. La transformation de l'exigence, du stade vague au seuil vérifiable puis au critère d'acceptation, est un enchaînement orienté: elle se dessine en un diagramme qui montre l'opération centrale de la technique. Le catalogue d'ENF est une grille de lignes et de colonnes: il reste un tableau, lisible, sélectionnable et redimensionnable. C'est la forme juste, puisque toute la valeur tient à la comparaison colonne par colonne: chaque exigence a-t-elle bien sa métrique, son seuil, sa source, sa vérification. Un attribut de qualité sans seuil se repère alors d'un coup d'œil, comme une cellule vide dans la colonne qui porte la technique.

Coût

Outils

Un tableur suffit à porter le catalogue tant que le volume reste modeste: une colonne par pièce de l'énoncé, soit l'attribut, la métrique, le seuil, la source et la vérification. Le tri par colonne fait alors apparaître les seuils manquants. Sa limite est la traçabilité, car un tableur ne relie pas mécaniquement l'ENF à l'exigence fonctionnelle qu'elle contraint ni au test qui la vérifie.

Le cran suivant héberge les ENF dans l'outillage d'exigences que l'organisation possède déjà: un type d'exigence dédié dans un référentiel comme Jama, Polarion ou Azure DevOps ou encore des pages structurées dans Confluence articulées à Jira. Le gain est le lien: chaque ENF se relie à la fonction qu'elle qualifie et au cas de test qui la vérifie, et l'analyse d'impact d'un changement de seuil devient une requête. Les techniques de priorisation, le classement MoSCoW en tête, structurent la colonne de priorité et le débat qui la remplit. Les outils de test (les plateformes de test de charge pour la performance, les scanners de vulnérabilité pour la sécurité, les tableaux de bord de supervision pour la disponibilité) ferment la boucle en produisant la mesure qui prouve, en exploitation, que le seuil est tenu. C'est cet appariement d'un seuil et d'un instrument de mesure qui distingue une ENF finie d'un vœu.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.30 Non-Functional Requirements Analysis.
• ISO/IEC 25010:2023, Systems and software engineering, SQuaRE, Product quality model: le modèle de qualité des produits, référentiel des catégories d'attributs de qualité (neuf caractéristiques).