Exigences fonctionnelles, attributs de qualité et contraintes

Trois types d’exigences

Une exigence est tout ce qu’un système doit satisfaire pour être acceptable aux yeux de ses parties prenantes. Les architectes trouvent utile de classer les exigences en trois types, car chaque type influence la conception d’une manière différente. Une exigence fonctionnelle indique ce que le système doit faire : « un client peut ajouter un article au panier », « le système de la pharmacie vérifie chaque nouvelle ordonnance au regard des allergies du patient », « un passager peut voir la position du chauffeur sur une carte ». Les exigences fonctionnelles décrivent le comportement, les données et les règles qui les relient. C’est ce que capturent la plupart des récits utilisateur (user stories) et des cas d’utilisation.

Un attribut de qualité indique à quel point le système doit bien le faire. « Les résultats de recherche s’affichent en moins d’une demi-seconde », « le service de réservation est disponible 99,95 % du temps », « un nouveau prestataire de paiement peut être ajouté en moins de deux semaines », « les dossiers des patients ne sont lisibles que par les cliniciens qui traitent ce patient ». Les attributs de qualité sont des propriétés du système dans son ensemble ou d’une fonction, et ils n’ont de sens qu’assortis d’une mesure : assez rapide pour qui, sous quelle charge, mesuré comment ?

Une contrainte est une décision qui a déjà été prise pour vous. « Le système doit tourner dans le tenant Azure existant de l’entreprise », « toutes les données à caractère personnel restent dans l’Union européenne », « l’équipe connaît Java et n’a pas de budget pour se former à autre chose », « la première version doit être en production avant le début de l’exercice fiscal, le 6 avril ». Les contraintes suppriment des options plutôt que de décrire un comportement. Elles ne sont pas négociables au sein du projet, même si un bon architecte vérifie que chacune est réellement une contrainte et pas seulement une habitude ou une hypothèse.

Les frontières ne sont pas toujours nettes, et ce n’est pas grave. Le but de la classification n’est pas l’ordre bureaucratique ; il est de s’assurer que personne ne recueille cinquante récits utilisateur en oubliant de demander combien d’utilisateurs il y aura, combien de temps l’entreprise peut survivre à une panne, ou quel régulateur surveille.

Pourquoi de nombreux architectes évitent le terme « exigences non fonctionnelles »

Les documents d’exigences séparent traditionnellement tout en exigences fonctionnelles et exigences non fonctionnelles (NFR). Le terme est partout, dans les contrats, les dossiers d’appel d’offres et les offres d’emploi, il faut donc savoir le reconnaître. De nombreux architectes et chercheurs l’évitent pourtant, pour trois raisons.

Premièrement, il définit une catégorie vaste et importante par ce qu’elle n’est pas. Tout ce qui n’est pas une fonction finit dans le même sac : temps de réponse, règles de chiffrement, choix du fournisseur de cloud et couleur du logo. L’article de Martin Glinz On Non-Functional Requirements (IEEE International Requirements Engineering Conference, 2007) a montré que les définitions publiées ne s’accordent pas sur ce qui appartient à cette catégorie, et qu’un même besoin peut être classé d’un côté ou de l’autre selon sa formulation : « seul le personnel autorisé peut voir les salaires » se lit comme une fonction lorsqu’il est écrit comme une règle d’accès, et comme une qualité lorsqu’il est écrit comme un objectif de sécurité.

Deuxièmement, le nom laisse entendre que ces exigences sont séparées des fonctions et peuvent être ajoutées plus tard. Ce n’est pas le cas. Un attribut de qualité qualifie une fonction : c’est l’étape de paiement qui doit être rapide, le paiement qui ne doit jamais être perdu, le dossier médical qui doit rester confidentiel. Bass, Clements et Kazman, dans Software Architecture in Practice, parlent donc d’exigences d’attributs de qualité et traitent les contraintes comme une catégorie distincte.

Troisièmement, « non fonctionnel » semble facultatif, comme si un système qui marche mais qui est lent, peu sûr ou impossible à modifier « fonctionnait » quand même. En pratique, ce sont exactement ces systèmes-là que l’on réécrit. Certaines équipes préfèrent « exigences de qualité » ; d’autres, notamment chez Thoughtworks, disent « exigences transverses » (cross-functional requirements) pour souligner qu’elles traversent toutes les fonctionnalités. Ce cours parle d’attributs de qualité et de contraintes. Si votre organisation parle de NFR, inutile de se battre sur le mot ; assurez-vous simplement que chaque NFR est soit une qualité mesurable, soit une contrainte clairement formulée.

Contraintes : techniques, organisationnelles, réglementaires, de délai et de budget

Les contraintes méritent plus d’attention qu’on ne leur en accorde habituellement, car elles déterminent souvent une plus grande part de l’architecture que n’importe quelle fonctionnalité. Une contrainte est simplement une exigence qui ne laisse plus aucune liberté. Il est utile de les regrouper selon leur origine.

Deux habitudes aident. D’abord, notez la source de chaque contrainte (une réglementation, un contrat, un décideur nommément désigné) afin qu’elle puisse être vérifiée et, si les circonstances changent, réexaminée. Ensuite, distinguez les vraies contraintes des préférences déguisées en contraintes. « Nous devons utiliser des microservices » est rarement une contrainte ; c’est une décision de conception que quelqu’un a prise tôt, et elle doit être justifiée par des attributs de qualité comme toute autre décision. La section du chapitre 1 sur les décisions et les compromis explique pourquoi les choix précoces et difficiles à défaire méritent cet examen.

Exigences architecturalement significatives

La plupart des exigences n’affectent pas l’architecture. Que la facture affiche le code postal du client au-dessus ou en dessous du nom de la rue est un détail ; cela peut se changer en un après-midi. Une exigence architecturalement significative (ASR) est une exigence qui a un effet mesurable sur l’architecture : si elle changeait, la structure du système devrait changer. Repérer les ASR tôt est important, car il coûte cher d’en tenir compte tardivement. Ajouter une salle d’attente à un site de billetterie la semaine précédant une mise en vente est possible ; partitionner l’inventaire des places sur plusieurs serveurs après le lancement revient à tout réécrire.

Lianping Chen, Muhammad Ali Babar et Bashar Nuseibeh ont interrogé des praticiens sur la façon dont ils reconnaissent les ASR (Characterizing Architecturally Significant Requirements, IEEE Software, 2013). Leurs conclusions rejoignent l’expérience de la plupart des architectes. Les ASR sont généralement difficiles à satisfaire, elles concernent souvent le système dans son ensemble plutôt qu’une seule fonctionnalité, elles entrent fréquemment en conflit les unes avec les autres, et elles sont souvent formulées de façon vague, voire pas du tout. Les attributs de qualité et les contraintes en constituent la majorité, mais certaines exigences fonctionnelles sont aussi significatives.

Exemples d’ASR fonctionnelles : « chaque modification d’un dossier patient doit pouvoir être rattachée à une personne et à un moment » (il faut un mécanisme d’audit dans tous les composants), « les utilisateurs peuvent collaborer sur le même document en temps réel » (cela exige un modèle de synchronisation et probablement un autre style de communication), et « les clients peuvent annuler un virement bancaire dans les 30 minutes » (cela affecte la façon dont l’argent circule entre les comptes). Chacune impose une décision structurelle, pas seulement davantage de code.

Pourquoi les qualités façonnent l’architecture davantage que les fonctions

Voici l’idée centrale de ce chapitre. Si seule la fonctionnalité comptait, presque n’importe quelle structure ferait l’affaire : vous pourriez écrire tout le système comme un seul gros programme, et il calculerait toujours les bonnes réponses. Bass, Clements et Kazman le disent directement : la fonctionnalité ne détermine pas l’architecture, car de nombreuses architectures différentes peuvent fournir les mêmes fonctions. Ce qui les distingue, c’est la manière dont chacune atteint les qualités.

Prenons deux systèmes de billetterie aux fonctionnalités identiques : parcourir les événements, bloquer des places, payer. L’un vend des billets pour une salle des fêtes de 300 places ; l’autre vend une tournée dans des stades de 60 000 places. Le moment le plus chargé de la salle des fêtes apportera peut-être quelques requêtes par seconde, et une seule application web avec une seule base de données est la bonne réponse : bon marché, simple et facile à modifier. La tournée des stades doit absorber un afflux des milliers de fois plus important, ne doit jamais vendre deux fois la même place et doit empêcher les bots de tout acheter dans la première seconde. Ce système a besoin d’un réseau de diffusion de contenu, d’une file d’attente devant la boutique, d’un inventaire des places soigneusement conçu, d’un stockage partitionné et d’un flux de paiement capable d’attendre un prestataire surchargé. Mêmes fonctions, architectures complètement différentes, et la différence vient entièrement des attributs de qualité et des contraintes.

Les qualités implicites que personne n’écrit

Certaines des qualités les plus importantes ne sont jamais énoncées, car toutes les parties prenantes les tiennent pour acquises. Ces exigences implicites n’apparaissent que lorsqu’elles sont violées, généralement en production. Personne n’écrit « ne pas perdre de commandes », « ne pas débiter deux fois le client », « continuer à fonctionner lors du passage à l’heure d’été », « afficher le même solde sur le téléphone et sur le site web » ou « ne pas divulguer les données d’un client à un autre ». Pourtant, chacune est une ASR aux lourdes conséquences : traitement idempotent des paiements, écritures durables, planification robuste aux changements d’heure, cohérence entre les canaux et isolation stricte entre clients.

Les exigences implicites se cachent pour des raisons sociales. Les parties prenantes métier les jugent trop évidentes pour être mentionnées ; les développeurs supposent que quelqu’un d’autre s’en est occupé ; et les gabarits d’exigences y font rarement penser. Voici des questions utiles pour les débusquer : « Qu’est-ce qui vous mettrait hors de vous si cela arrivait ? », « Qu’est-ce qui nous ferait passer dans les journaux ? », « Qu’est-ce qui a mal tourné avec le système que nous remplaçons ? » et « Pour quoi réveille-t-on l’équipe d’exploitation ? ». Les rapports d’incident et les tickets de support des systèmes précédents en sont une source riche ; il en va de même des recommandations publiées par les régulateurs et des obligations figurant dans les contrats clients.

Comment les professionnels travaillent avec les ASR

Les architectes expérimentés tiennent une liste courte et vivante d’ASR, généralement de cinq à quinze éléments, plutôt qu’un long document d’exigences. Chaque élément formule la qualité sous forme de scénario testable (section 2.3), nomme la partie prenante concernée, consigne sa priorité et renvoie aux décisions qu’il a orientées. Le modèle arc42, par exemple, demande les trois à cinq principaux objectifs de qualité dès sa première page, puis une liste plus complète des exigences de qualité plus loin. La liste est revue chaque fois qu’une décision importante est prise ou que l’entreprise change de cap, et les éléments les plus importants finissent par être adossés à des vérifications automatisées appelées fonctions d’aptitude, présentées à la section 2.8.