Мне кажется, вы путаете итеративный процесс и agile.

Про преимущества итеративного процесса по сравнению с каскадным - все тоже далеко не так очевидно :).

Пример плохого итеративного подхода - code, fix, code, fix, code....

Любая нормальная разработка в чем-то каскад - requirements - design - code - test. Просто, потом наступает обратная связь от заказчика и начинаются новые итерации requirements - design - code - test. Эта схема работает во всех методологиях с небольшими нюансами. От RUP до XP.

Не нужно "мириться" с тем, что требования будут меняться. Нужно этого страстно желать и рассчитывать на это. Если за полгода разработки требования к системе не изменились, значит эта система просто нафиг никому не нужна. Изменение требований не означает бесконечно бесплатно наращивать функционал. Если вы работаете по fixed price, т.е. в самом начале проекта говорите сколько будет стоить проект, то вам нужно четко зафиксировать требования и оценить каждое из них. Если требование меняется, либо появляется новое вы используете формальный механизм управления требованиями
1) оцениваете сколько будет стоит для вас это изменение, и потом либо
2а) договариваетесь с заказчиком об увеличении бюджета (доп. соглашениями к договору, например)
2б) договариваетесь с заказчиком об изменении общего набора требований - вы делаете те требования, которые появились, но зато выкидываете равнозначные по стоимости требования, которые еще не успели реализовать. Оформляется тем же доп. соглашением.

Работа по Time & material переносит риски изменения требований на заказчика, но мало кто соглашается так работать, и судя по всему у вас не такой случай.

Теперь отвечу на самый распространённый в подобных обсуждениях вопрос:
"А что делать, если заказчик спрашивает - сколько это будет стоить, а что конкретно надо будет делать, не понятно?"
1) Очень просто. Нужно понять и решить - что конкретно нужно будет сделать. Описать рамки проекта. Описать то, что вы делать НЕ будете. С помощью различных методик оценить трудоемкость работ (экспертная оценка, functional points, use-case points), накинуть маржу, риски, и выдать сумму и полученное описание. Если остаются мутные места в системе - заложить на них много времени (см. управление рисками).
2) Нужно провести воспитательную работу с заказчиком и пояснить ему на человеческом языке почему нужно заранее обговаривать функционал. Можно провести параллели, например - "вы приходите к строителю и говорите ему что вы хотите большой и красивый дом. И спрашиваете сколько это будет стоить. Пока строитель не согласует с вами чертежи - он сумму не скажет. Тоже самое в разработке - пока не согласованы требования, сумма не определена".
3) Бывает, что написание требований - само по себе трудоемкая и дорогая работа. Тогда есть два пути - выбить деньги на написание требований, либо сделать эту работу бесплатно включив ее стоимость в будущий проект, рискуя тем что проекта может и не быть. Оба варианта на практике случаются.

Резюме.
Если у вас нет никаких зафиксированных требований, вы работаете маленькими итерациями и не знаете будет ли проект бесконечным - называть общую стоимость проекта бессмысленно. Можно сказать, что "он будет стоить N руб. в месяц при работе X человек, а длительность работ будет зависеть от количества требований и скорости их изменений". Это time & material.
Если у вас есть зафиксированные требования, то тут уже не важно - пять у вас будет итераций или одна, главное что вы заранее решили сколько их будет. Вы сможете оценить объемы работ в часах (а значит и в деньгах), а изменениями требований управлять формальным образом.