Как у нас любят говорить: "зависит от контекста" В целом, в зависимости от кейса, требуемой скорости выполнения задач, типа проекта и т.д. зависит глубина документирования.

Где-то, бывало, достаточно алгоритмического описания для внедрения фичи А где-то уже нужны и модель компонент, бизнес-процессы, последовательности и сетевого развёртывания, контракт и erd

В целом, знания полезные, как минимум для того, чтобы держать визуализацию в голове Но можно работать и без них :D

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

Был у меня начальник один. Буквально повернутый на UML. При приеме на работу сказал — у меня к аналитикам одно требование, знание UML. Я ответил — ну хорошо, UML так UML. И весь первый месяц работы штудировал последнюю версию стандарта.

Через месяц штудирования начал видеть грубые косяки в диаграммах начальника.

Он же ведь не сказал сразу, ДО КАКОЙ СТЕПЕНИ нужно понимать этот стандарт.

После двух месяцев штудирования стандарта пришел к выводу, что степень компетентности код-ревью в аналитическом отделе оставляет желать лучшего…

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

Если два человека именно что спорят, что означает та или иная стрелка — это финиш. Есть стандарт. Открываем его и изучаем. Спор может быть лишь при недостаточно однозначном определении того или иного элемента нотации в стандарте. Тогда да, мы можем подискутировать о том, что мы поняли из прочитанного нами текста.