Так в большинстве случаев формулируют задание для Веб-разработчиков

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

Может кому-нибудь мой подход покажется странным, но скажу вот что. Не нужно ждать от заказчика внятного или просто вменяемого тех. задания. Можно просто его не дождаться.
Нужно совместно с заказчиком понять его потребности, изучить основыне особенности его деятельности и предложить к выполнению т.з. собственного написания. Осмелюсь заявить, что эта работа (по вниканию и изучению) должна оплачиваться отдельно, как отдельная услуга. Можно (наверное не в России) даже организовать outsource-компанию, которая будет такие услуги предоставлять. Чем не бизнес?

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

Очень полезный абзац — заказчики, берите на заметку!

Вы бы стали такое задание выполнять, если бы вам его вот так поставили?

Да, конечно. Иначе, как уже сказал выше  redhummer, можно остаться без заказчиков.
Суровые реалии таковы, что ТЗ для разработчиков вынужден готовить уже менеджер проекта.

Заказчики тоже разные бывают. Для некоторых это просто манна небесная когда исполнитель приходит и говорит "Вы торгуете шинами, и мне абсолютно ясно, что Вам нужно". Ибо этим заказчикам нужен сайт, чтобы был, причем достаточно большая вероятность, что они получат "то, что им нужно" (добавленную стоимость). Но лично для меня это дико, когда мы заказываем сайт (который еще год назад я бы сделал сам, да теперь уже задачи не те), и исполнитель со скукой выслушав мои requirements говорит мне "я сейчас скажу Вам, что Вам нужно" и начинает пихать какой-то default :( К сожалению пока это большая редкость, когда исполнитель имеет "прослойку" (не знаю как назвать sales и project manager или еще как) между кодером и заказчиком.

Согласен с первыми двумя ораторами на 100%. Беда в том, что работаю я в относительно большой (60 человек) конторе, а задание в приблизительно таком виде, да еще «облагороженное» родными нашими менеджерами, докатывается до нас, работников клавиатуры и мыши. Для менеджера никаких проблем нет, у него стояла задача написать ТЗ - он эту задачу выполнил. «Согласовал с заказчиком, все довольны. Один только ты, дизайнер/программер/верстальщик/кто ты там еще, вы***ваешься.» А то, что качество его (менеджера) продукта крайне невысоко, и работать по такому заданию в лучшем случае сложно - это никого не трогает. Оценивается только конечный результат - даже не сайт, а (!) удовлетворенность клиента этим сайтом. А клиент, напоминаю, составлял на пару с менеджером ТЗ, из которого нельзя понять, зачем ему сайт вообще.

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

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

В большинстве случаев ТЗ можно составить только с помощью специалистов, при этом нужно дать заказчику базовые знания, чтобы он понимал вообще о чем речь идет при составлении ТЗ (Обучайте заказчиков).

Можно использовать анкету с наводящими вопросами, ведь заказчик может знать ответ, но забыть включить его в свое ТЗ.

Составление адекватного ТЗ для каждого заказчика, это одна из задач студии, не менее важная и профильная чем и сама разработка сайта.

Заказчик никогда не знает, чего хочет, обычно у него есть ИДЕЯ, которая каждую секунду мутирует. Если ему задать вопрос, каким он видит свой ресурс в начале беседы и через 10 минут - ответы могут быть противоположными. Задача разработчика в первую очередь сформулировать конечный результат из того бреда, который принесет заказчик. Обычно это называется техническим заданием, именно оно описывает конечный результат и чем подробней, тем лучше. ТЗ пишется разработчиком за дополнительную плату, по сути это часть проектной документации и процесс проектирования, что в принципе тоже должно быть оплачено. Если ТЗ пишет заказчик, то стоимость проекта должна увеличиваться за счет появляющихся рисков, обычно от 1 до 30%. Риски эти связаны с недопониманием и неопределенными моментами, которые заказчик наверняка не учел.

раз уж выше цитировали Лебедева, то еще цитата: "Дизайнера легко парализовать вопросом: «А что если заказчик умнее тебя?»"
Это утверждение во много раз вернее для менеджеров проектов, которые работают в большинстве студий.

Я бы ставил десятки плюсов постам из серии "выслушать, что хочет заказчик, вместе решить его проблему и т.п.", если бы не был знаком с реальность. А в реальности после "выслушать" стоит "втюхать свои стандартные наработки", обычно не вникая в особенности бизнеса заказчика и т.п. и т.д. И это в массовом порядке, исключения настолько редки, что только подтверждают правила.