Вот это часто факапится, если аналитик не отрабатывает.

Тогда как вариант по услугам/продуктам

Значит непонимание было именно между топом и посредником, которым возможно инфу не предоставили, также как и вам. Я к чему, Вы доподлинно знаете, что аналитик до вас не работал с требованиями и их ему дали в полном объеме как вам/ здесь нет ни правых ни виноватых. У вас же конкретные запросы на детализацию. Так почему не вычислить условный минимальный объект в процессе именно с заказчиком, и от сих плясать?

Заказчик один, продукты уровня Plant условия turnkey. Ну это специфика с чем я сейчас. А так да, удобно по продуктам и услугам наверное.

На проекте не было выхода на прямого заказчика. Требования были отданы со стороны БА, цели поставлены ПМ. Подвергать сомнениям работу БА и ПМ я не взялся. Получить доступ к прямому заказчику я не смог. Из стейкхолдеров только были отдельные люди из разных отделов, которые к процессу имели опосредованный интерес.

Он кажется наиболее рабочим.

Как по мне сначала нужно ответить на вопрос о пользователях каталога. Тогда станет понятнее как группировать

Но характер топа вы почему то понимаете. Странно. Ваш ба не может совместно с вами проработать, а вы ему на косяки указать? Обычно же в такой связке работа идет.

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

Я понимаю его характер, но не цели.

Если яработаю один, то так и происходит. Общение идёт напрямую со стейкхолдерами и заказчиками. Формируются их ожидания, цели, MVP. Дальше описываются бизнес-требования, которые порождают архитектурные и системные требования.

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

А точно для решения такой проблемы - дискоммуникаций - нужно описание процессов? Может просто от прецедента идти - в начале нового проекта использовать предыдущий провал (это ведь провал был, нет?) и предложить сверять с заказчиком часы и в рамках требований, и в рамках итераций разработки?

Это точно не тот случай.

В нашей компании подставить кого-либо таким образом даже в голову никому не придёт.
Это вопрос культуры, которая здесь сильно развита.

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

Хотелось бы сперва сделать более простые вещи. Список процессов и их оунеров помог бы упорядочить хаос вокруг. Также была бы возможность аналитикам выходить непосредственно на оунера процесса и был бы человек, принимающий решения со стороны бизнеса.

Пока даже схемы не нужны будут