И если делать UML/ER диаграммы как показать роботодателю и заказчику ихнюю нужность?
Диаграммы — это инструмент:
1. Быстрой передачи информации. В случае, если используются простые неформальные диаграммы или ARIS eEPC/VAD. Не UML, и даже наверное не BPMN.
2. Обеспечения качества требований. Для анализа полноты, что ничего не забыли из того, что должно как-то отразиться в требованиях — входы/выходы, последовательности, связи. Для этого подходят DFD, UML, ER, BPMN.
Диаграммы 1 могут быть понятны и полезны заказчику при прикладывании оправданных усилий с вашей стороны.
Диаграммы 2 — это ваша внутренняя кухня. Заказчику они на фиг не сдались, также как и покупателю современного телевизора схемы его внутренней разводки. Если повезёт, они также могут быть полезны разработчику для цели 1. Но обычно на это рассчитывать не стоит.
Объяснять работодателю необходимость конкретных видов диаграмм — это всё равно, что объяснять необходимость теодолита для геодезиста.
Разумнее вести разговор о составе работ, и рисках для проекта по срокам и деньгам, если какие-то работы не будут сделаны.
В этом составе работ графическое моделирование не должно выделяться как отдельный этап, а быть встроенной частью моделирования и разработки требований — т.е. работ по созданию артефактов, представляющих однозначную ценностью для заказчика и работодателя (Концепция, ТЗ, Регламенты деятельности, Инструкция по использованию программы).