я вот предложил, например добавить поле в таблице (документ Word) которое определяет поле новое или старое, удаленное

Так документ будет ещё больше

Вы с задачей-то определитесь, вам или сложность анализа надо снизить, или управляемость повысить или что-то ещё.

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

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

"Должный уровень культуры" должен откуда-то взятся)

ох начитался я ТЗ в стиле: взять поле А, добавить в поле Б и прибавить В.
Потом никто вообще не понимает как система работает,
так как не осталось знания о решаемой задаче,
лишь история изменений реализации...

А культура составления документов это большая проблема, да.
Соблазн написать в задаче "добавьте быстренько поле А к полю Б" слишком велик,
чем сделать описание решаемой задачи вида "для учета пользователей такой-то категории необходимо в суточный расчет включить операции произведенные агентом таким-то"

Также замечено что заказчик часто пытается подсунуть свое видение решения задачи вместо того чтобы корректно определить саму задачу.
Аналитик определяет постановку задачи, а не способ ее решения.
Задача аналитика разобрать поток сознания заказчика и корректно сформулировать постановку задачи.
А грамотный разработчик уже сам знает как правильно реализовать задачу.
У каждой специальности своя масса нюансов: аналитик не знает тонкостей разработки, разработчик не желает тратить время на то чтобы копаться в голове заказчика, пытаясь понять что тот от него хочет.
Проще говоря, по моему опыту, когда аналитики занимаются написанием псевдокода в Word,
результат получается так себе.

Документируют что должно быть сделано, а не как.
Если оставить всё на код, то не останется инфы как должно было быть. Не с чем будет сравнивать реализацию. Проект превратится в каргокульт в котором все боятся всё менять, а концов не найти)

👍 воистину!

в контексте MSA подкину аргумент что прикладной процесс становится надсервисной сущностью, понять его "по коду" зачастую просто невозможно

Начните пожалуйста с цели документирования) Если для постановки задачи изготовителю системы - да. Если тому, кто диагностирует - как должно сделано, если тому кто ищет возможности развития,  то пожалуй и то и то)

Извините за дурацкий вопрос, посоветуйте курсы по solution архитектуре?

У Люксофта есть, только не знаю отзывов

Я прошу прощения, а что вообще делает аналитик, если он вдруг определяет структуру БД?! Это же уже, с моей точки зрения, детали реализации.

Не совсем структуру, он описывает сущность на руском языке в виде таблицы

А что мешает справа или снизу от таблицы сохранить такую же, но прошлую с подзаголовком: «а раньше было вот так» ?

А зачем описывать сущность в виде таблицы, если потом это может быть совсем не таблица, или не одна таблица?

выражу свое скромное мнение, что описываемая ситуация (постановка в ворде в виде описания таблиц от аналитика) - это исторически сложившийся артефакт и причины этого плачевны, и это вполне понятно. говоря сленгом программиста - абстракция "протекла". раз аналитик пишет требования к бд, то аналитик должен иметь фундамент знаний в области проектирования бд. развивать эту "протечку" можно и дальше, но не к месту. кажется, что нужно развернуть эту зависимость и доверить проектирование бд тем, кто в этом специализируется, и кажется, это не аналитик.

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