ее можно немного смягчить, если формулировать требования будет возможность только у _ключевого_ пользователя, тогда он выполняет роль почти внутреннего консультанта;
но регламент принятия запросов на разработку и список лиц их формулирующих должен быть прописан обязательно, а то, действительно, получится, что "да мне Марь Иванна сказала, что не хочет эту галочку каждый раз включать, поэтому месяц и портил стандартные транзакции.."

Не. это плохо.

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

Ага, а еще есть консультанты, которые так и не поняли концепции системы SAP и пытаются из него MS Office сделать

Ну что все так навалились на Тимофея?

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

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

А зачем с этим бороться? Итерационный процесс - скорее правило. Бизнес меняется, появляется новая информация, естественно, возникают новые требования.
Или хоцца скульптуру из мрамора ваять "на века"?

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

вообще-то на итерационности построены некоторые методологии проектирования\разработки. Экстремальное программирование например. Да и дяденька Буч к этому тяготеет.

Главное - не перейти тонкую грань, которая отличает итерационность от бардака.

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

Да есть в классике спиральные и каскадные модели разработки ПО и прочее... ну там же и итерациооность;) однако сложно назвать итерацией изменение логики программы, причем нормальное такое изменение, просто, потому что у нас оказалось все сложнее чем мы думали, и как оказалось никто не знает как оно есть:)))) Сразу вспоминается стори, бродившая по инету про аллегория построения ПО и здания, когда при возведении крыши перестраиваем фундамент

А в этом доме уже живут жильцы
Если бы программисты строили самолеты

Апсалютна в дырочку!