[lostcolony]

Requirements are hard upfront, period, to the point I'd say that any organization trying to set them upfront is dysfunctional, tautologically. Making all the decisions when you have the least amount of information is a Bad Idea.

[sharken]

Also, how long will it take to build and how much will it cost? :)

This is where Agile ought to improve things, but then SAFE came along and we were back to square one.

[kenniskrag]

but there are some architectual significant requirements, which have to be known upfront.

[lostcolony]

I both agree and disagree with you.

There are requirements that will affect architecture that, if they're guessed at and turn out to be wrong, will lead to massive refactoring and/or large amounts of effort being thrown out. 100%.

Where I disagree from most businesses is in the implicit belief they have that seems to be "better for devs to be idle than for devs to work on code that will be thrown away". I'd rather take a guess and start work; best case we're right and are ahead; worst case we're wrong and have learned some useful lessons.

Which you'll note is the same dilemma as every other decision related to the project, with the only difference being the scope.