You have a choice of koolaid. The waterfall brand is implicit in the statement "We don't write a line of code until we know your business as well as the people who keep it running every day." - it is founded on the assumption that you can finish requirements for the entire system before starting to deliver working software, and no feedback or iteration is needed.

My experience is that for the majority of software projects, this assumption is horribly broken. And even in fairly well known problem domains where it might work, for the majority of business users wanting new software, the ability to communicate every detail of what it is that they want is horribly lacking.

Scope creep, architecture problems, unanticipated requirements etc. can and does break waterfall projects; this was well known 10 years ago. The probably of it going wrong rises with the size of the project, and it's a curve that's well above linear.

There are two ways out: You can plan for change or you can make the penalties against change more severe - roughly, do even even more big upfront design and penalise change requests; or do less of upfront design, iterate and embrace change. In many cases the "big upfront design" way is impractical in time and expense.

Edit: I found the old article on this subject: "Theory P and Theory D of software construction: Which theory fits the evidence?" http://weblog.raganwald.com/2007/06/which-theory-first-evide...