Dans le cadre d’un projet récent nous avons eu de nombreux défis pour s’assurer que l’ensemble des règles fonctionnelles étaient implémentées et couvertes par les tests unitaires, fonctionnels et intégrés. Le client avait un nombre de vieux documents d’analyse mais la vraie source de règles était le système légataire que nous modernisions.Il est surprenant d’apprendre qu’un grand nombre d’entreprises ne connaissent pas l’ensemble de leurs règles d’affaire et n’ont pas la documentation nécessaire pour en déduire l’ensemble. La vérité se trouve, comme c’est souvent le cas, uniquement dans le code.Mais comment s’assurer que l’ensemble des règles sera reporté dans le nouveau système et sera testé adéquatement ?Il n’y a malheureusement pas de solution facile. Il faut :

1. répertorier et analyser toute la documentation existant
2. documenter les connaissances des analystes et autres ressources/spécialistes de l’entreprise
3. utiliser l’application pour en tirer un certain nombre de règles à l’usage
4. compléter le tout avec une analyse du code pour les zones grises.

Mais tout ce travail ne garantit toujours pas que l’ensemble des règles sera répertorié. Ayant fait du mieux qu’on a pu avec les activités énumérées ci-haut la question suivante se posait : où conserver ces règles ?Le problème avec les documents fonctionnels et les use cases c’est que les règles sont éparpillées à un grand nombre d’endroits ce qui met une pression énorme sur les développeurs pour consolider ces différentes sources d’information pour ensuite implémenter l’ensemble.La clé est de centraliser l’ensemble des règles fonctionnelles dans une base de données. Une simple BD Access ou même un chiffrier Excel peut être suffisant pour conserver l’information (dépendant de la taille du projet). Ce qui est important c’est de les définir clairement et d’y attribuer un numéro unique.

Grâce à cette centralisation et à la numérotation on peut obtenir les avantages suivants :

1. Les uses cases peuvent référer à une règle de manière absolue (ceci évite la définition redondante d’une règle à travers plusieurs documents)
2. Les plans de test peuvent être élaborés pour couvrir chaque règle en détail
3. Lors de la réalisation, on associe au code qui implémente la règle un commentaire contenant le numéro de la règle. Ceci permet de retrouver l’implémentation de la règle via une simple recherche (voir grep)
4. Au niveau du gestionnaire de bugs (bug tracker) on peut facilement référer à la règle via son numéro ainsi que référencer le code source qui l’implémente.