Comment suivez-vous les règles commerciales complexes en dehors du code?

Je voudrais voir comment les autres font ça. Surtout dans les situations où plusieurs clients différents utilisent la même base logicielle avec des règles métier légèrement différentes. Quel type de pratiques utilisez-vous pour documenter comment tout est censé fonctionner ou les règles métier.

Fondamentalement, lorsqu'un nouveau développeur fait partie de l'équipe, il est facile d'accéder à la façon dont les choses sont censées fonctionner, car il y a évidemment une différence entre rendre quelque chose sans bogue et faire fonctionner correctement quelque chose.

Ce serait vraiment bien d'avoir des ressources plutôt que d'avoir à faire appel à un architecte ou à un BSA chaque fois qu'une question se pose sur la façon dont quelque chose doit être traité.

Il s'agit de l'un des cas d'utilisation des infrastructures BDD, comme Cucumber, qui vous permettent de capturer les exigences métier dans le code et de les tester fréquemment. D'autres approches que j'ai vues utilisées incluent des documents de spécifications longs et compliqués, de grandes feuilles de papier collées au mur, des plateaux de diapositives et Joe, le gars au bout de la table qui sait tout.

Je pense qu'à tout le moins, ceux-ci seraient documentés et conservés dans le document des exigences.

Je me rends compte que la plupart des endroits n'ont pas d'exigences écrites ou ne sont pas maintenues, mais c'est un problème différent. :-)

Nous avons utilisé BPMN pour documenter et modéliser nos flux de travail commerciaux si c'est ce que vous voulez dire.

Nous avons également essayé d'utiliser un moteur de workflow dans un projet pour permettre aux utilisateurs de participer à la modélisation, mais cela a rencontré une certaine résistance car ils avaient trop peur de casser les choses, même si la modélisation a été effectuée avec un spécialiste du workflow de notre Département IT.