Предлагаю делиться опытом, кто с какой детализацией документирует изменения систем.
Как фиксируются требования бизнеса, как документируется техническая сторона реализации этих требований.
Интересует освещение вопроса для систем разного рода, для учетных, транспортных (заливка хранилищ, интеграция)...

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

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

"не вижу связи..."
Как правило, документирование "удлиняет" процесс между появлением потребности и передачей хотя бы в опытную эксплуатацию реализации.
Вот тут конфликт интересов: бизнес хочет "на вчера", не очень понимает ценность документирования (в идеале передать в ИТ требования в виде простого диалога или email); люди, ответственные за систему, понимаю ценность документирования и полезность в перспективе (а могут и не понимать частично).
Кроме того, документированием, согласованием требований можно увлечься и прийти к тому, что это составляет существенную часть работы.

Тема у ходит в сторону "надо / не надо".
А интересует практический опыт.
Особенно интересно в "insite" варианте.
У меня в практике было:
1. Аналитики писали процессы и согласовывали изменения с бизнесом, причем аналитики могли выступить и инициатором изменения / оптимизации процесса.
Аналитики писали ТЗ программистам. Детализация тут уже персональная, но за качеством в целом следил архитектор.

2. Были ситуации, когда начинали по AIM, при переходе от внедрения к сопровождению оставляли только ТЗ.
(спасало, что в AIM в MD050 есть раздел для бизнес-кейса).

3. Бизнес писал процессы, ибо аналитики вроде как не компетентны в этом.
Аналитики писали высокоуровневую постановку задачи, потом ряд согласований по сути, срокам и трудозатратам.
Далее аналитики писали ТЗ программистам.

Во всех случаях общее одно: если есть архитектор, следящий за целостностью разработок и качеством ТЗ, то порядок будет; если его нет, в определенных случаях срабатывает соблазн упростить ТЗ до простого письма.
_______________
Я ожидаю, что коллеги по цеху поделятся своим опытом.
Как правильно, мы многие знаем, а вот как в жизни приживается, это очень интересно.