Как известно, ошибка полученная на стадии разработки требований обходится в 200 раз дороже на стадии тестирования и сдачи. Т.о. естественно нужно прорабатывать требования хорошо и они должны отвечать следующим критериям:
• Correct - описаны верно
• Complete - полные, отражать в себе все требования заказчика
• Clear - понятные всем участникам проекта и непротиворечивые сами по себе
• Consistent - не вступать в конфликт с другими требованиями
• Verifiable - требования можно проверить
• Traceable - уникальные и взаимосвязаны между собой
• Feasible - могут быть выполнены в соответствии с планом и бюджетом
• Modular - могут быть изменены без огромных усилий
• Design-independent - в требования не должны быть включены элементы дизайна

Но с другой стороны, даже если мы честно проработаем требования, то они все равно изменяться от:
• Изменения бизнеса
• Нечеткой формулировки Заказчиком и неумышленного умалчиванием чего-то
• Политических причин
• Квалификации аналитика

Так не лучше работать с требованиями по итерациям? Т.е. описали что-то - реализовали, дальше изменили требования, дописали новые требования - опять реализовали и т.д. Тем самым время разработки получаем немного больше, но зато удовлетворенность заказчика на много выше.

Кто что по этому поводу думает?

Итерационная разработка предполагает циклический подход. Однако во всех таких подходах, требования итерационно не уточняются, а итерационно вовлекаются. Т.е. на первой стадии следует выделить самые самые требования при чем их должно быть не больше 10%. Ларман в своей книге "Применение UML и шаблонов проектирования" рассматирвает итерационный подход на примере вариантов использования. Т.е. вначале очень важно определить список требований (читай ВИ), ранжировать их и отделить самые самые, и уже их детально проработать.

Если же требование разрабатывать итерационно в стиле, который ты описал - то у программистов просто крыша съедит.

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

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

Если же проект инновационный, то мне думается тут следует действительно формировать промежуточнные прототипы, моделировать требования - но это будет скорее уже исследовательская часть, чем промышленное написание кода.

Так не лучше работать с требованиями по итерациям? Т.е. описали что-то - реализовали, дальше изменили требования, дописали новые требования - опять реализовали и т.д. Тем самым время разработки получаем немного больше, но зато удовлетворенность заказчика на много выше.

На сколько я понимаю - это принцип напрямую используется в alige методах разработки (Scrum, XP, UP (упомянутый Galogen) )

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

Итерационная разработка предполагает циклический подход. Однако во всех таких подходах, требования итерационно не уточняются, а итерационно вовлекаются.

Это кто тебе такое сказал?? Т.е. если была ошибка в требованиях, то ее не исправляют, а вовлекают новые требования??

Если же требование разрабатывать итерационно в стиле, который ты описал - то у программистов просто крыша съедит.

Вон у Agile программистов не слетают, а там еще хуже, зачастую требования вообще не прорабатывают, а кодят прям по тому что юзер написал (user story) или сказал

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

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

Если же проект инновационный, то мне думается тут следует действительно формировать промежуточнные прототипы, моделировать требования - но это будет скорее уже исследовательская часть, чем промышленное написание кода.

В какой-то мере все проекты инновационны. А то бы  стояли станки по производству ПО.

На сколько я понимаю - это принцип напрямую используется в alige методах разработки (Scrum, XP, UP (упомянутый Galogen) )

В принципе да, но там еще хуже, как я писал выше.

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

Ну это как обычно, выбирай 2 из 3ех: быстро, качественно, дешево.
Но представим, что Вы выполняете проект сами и Вам выбирать процесс, что бы Вы выбрали??