Les exigences sont déjà une interface
Avant de devenir du logiciel, une exigence devient le modèle mental de celles et ceux qui devront la comprendre.
J’ai récemment travaillé sur une évolution réglementaire décrite par plus de quarante exigences. Chacune était nécessaire, mais aucune ne pouvait être comprise complètement sans les autres. Ensemble, elles formaient un seul mécanisme.
La difficulté ne venait pas uniquement de la règle métier. Elle venait de la lecture. Après quelques lignes, je revenais déjà en arrière pour relier les règles générales aux exceptions. À la dixième exigence, comprendre la suivante dépendait de la mémoire des neuf précédentes. La logique était cohérente. Sa représentation l’était beaucoup moins.
Une liste fonctionne bien lorsque les éléments sont indépendants. Un algorithme, lui, contient des dépendances, des priorités et des exceptions. Si ces relations restent implicites, le lecteur doit les reconstruire mentalement.
Le document contenait toute l’information nécessaire, mais pas encore la forme qui permettait de la raisonner comme un ensemble.
Parfois, une table de décision vaut mieux qu’une liste. Parfois, il faut regrouper les règles ou rendre les dépendances visibles. L’objectif n’est pas d’appauvrir le métier, mais de réduire l’effort nécessaire pour en construire un modèle mental juste.
Bien avant l’écran final, analystes, développeurs et testeurs rencontrent le produit à travers ses exigences. Cette expérience mérite elle aussi d’être conçue.