В целом понятно, спасибо!

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

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

Вообще в последнее очень странно читать форум и слушать коллег, потому что с какого-то момента, похоже, люди перестают понимать, что любые инструменты работают в определенных границах, и границы эти задает тот, кто их применяет, и через это не перепрыгнуть, хоть какой супер-крутой метод придумай. Возьмите любое направление хотя бы в работе с требованиями и убедитесь. Но как только доходит до человека - так у нас столбняк и никто не понимает, как с ним работать. Всем бы надо какое-то волшебное ПО, чтобы само как-то без нас все сделало.
Учите психологию! Все инструментальные средства уже достигли потолка в своем развитии, для дальнейшего повышения эффективности надо развивать собственные мозги (а точнее - некие социальные навыки).

ida - здесь речь не идет о каком-то ПО или других инструментах. Речь идет о методах, а они вполне применимы и в общении. Метод утюга и паяльника отлично позволяет эффективно узнавать пароли у пользователей. Кто говорил о том что человек не хочет кого-то слушать?

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

Никто не говорил, что не понимает как работать с заказчиком, если бы это было так, многие были бы без работы. Да и ПО волшебное тоже никто не просит.

IMHO всё-таки Вы не слышите, что Вам говорят, и гнёте свою линию.
нет правильных вопросов, нет и правильной последовательности! нет и всё! всё строго индивидуально.
а чтобы говорить со знанием дела - нужно быть специалистом. однако ни вы, ни я, ни кто-то еще из нас ИТишников не может лучше заказчика знать его предметную область, его проблемы и потребности/хотелки. хорошо знать может, но лучше - вряд ли (иначе б работал на его месте). вот и нужно этого "хорошо" достигать + коммуникативные навыки.
так что единственный способ - грамотно говорить с заказчиком на его языке (как в той рекламе).

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

ответ короткий - stakeholder'ов. тех, кто что-то получает / теряет от внедрения, кого (чью сферу ответственности затрагивает система)
как? искать. изучать процессы, взаимоотношения в организации заказчика, просто внимательно смотреть по сторонам, слушать и слышать разговоры, вроде бы не относящиеся к делу, узнавать о событиях в организации, делать выводы из реакций на ваши (и кого-то еще) действия.
психология тут поможет.

А вот тут я уже, извините, упустил смысл продолжения спора. Если правильно понял, вопрос был о формализованных рекомендациях, которые описаны в стандартах и формальных описаниях процессов типа RUP. Да, они там есть, но в конечном счете сводятся все к тому же - собрать заинтересованных лиц в одной комнате и попытаться привести к согласию:
To conduct a requirements workshop, means to gather all stakeholders together for an intensive, focused period.
Есть еще советы по подготовке и ведению совещения, ничего особо сверъестественного.
А вот рекомендаций, какими словами убеждать участников, и что делать в случае провала там нет.

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

лучше не "при", а "до". договариваться лучше "на берегу", а не "в тонущей лодке" (ну или не в тонущей, а "идущей полным ходом")

Вы уже по-моему на следующий цикл пошли

Главное вовремя остановится.