Как вы отслеживаете сложные бизнес-правила вне кода?

Мне интересно посмотреть, как другие люди делают это. Особенно в ситуациях, когда несколько разных клиентов используют одну и ту же программную базу с немного разными бизнес-правилами. Какие методы вы используете, чтобы документировать, как все должно работать или бизнес-правила.

По сути, когда в команду приходит новый разработчик, у нее есть простой доступ к информации о том, как все должно работать, потому что очевидно, что есть разница между исправлением ошибок и обеспечением правильной работы.

Было бы очень хорошо иметь возможность обратиться к ресурсу, а не привлекать к беседе архитектора или BSA каждый раз, когда возникает вопрос о том, как что-то обрабатывать.

Это один из вариантов использования каркасов BDD, таких как Cucumber, которые позволяют фиксировать бизнес-требования в коде и часто тестировать их. Другие подходы, которые я видел, включают в себя длинные и сложные технические документы, большие листы бумаги, прикрепленные к стене, слайды и Джо, парень в конце стола, который знает все.

Я бы подумал, что, по крайней мере, они будут задокументированы и сохранены в документе с требованиями.

Я понимаю, что в большинстве мест либо нет письменных требований, либо они не поддерживаются, но это другая проблема. :-)

Мы использовали BPMN для документирования и моделирования наших бизнес-процессов, если вы это имеете в виду.

Мы также пытались использовать механизм рабочего процесса в проекте, чтобы позволить пользователям участвовать в моделировании, но это натолкнулось на некоторое сопротивление, потому что они слишком боялись что-то сломать, даже если это моделирование было выполнено вместе со специалистом по технологическому процессу из нашего ИТ отдел.