Preferred methodology

IMHO, there's no one particular "development methodology" which would be applicable to all project sizes & scopes. For me, a mix of the waterfall model & the iterative model would work fine.

Start building on the iterative model, but the phases should be that of a waterfall model. This would ensure that the software is capable of sudden changes & also that everything is well documented.

What makes you want more waterfall?

I would like to wait longer for feedback on any decision.

I would like to discover bugs as late as possible.

I would like to invest in analysis and design for things that might not be built.

I would like to get my software in one delivery, all or nothing.

I'm being sarcastic of course, but I don't want to shut you down. Seriously, what would you like to have more of that waterfall gives you?

I share Stan's puzzlement. I'm especially puzzled by the statement that waterfall is better at allowing sudden changes than iterative development...

Some developers hate change.They will complain when requirements are not fixed. Commonly heard -'Requirements are not known properly. How can we proceed' 'Things have changed suddenly. How can we incorporate it now ?'. I used to think like this before. May be because of this people like waterfall

I would like to wait longer for feedback on any decision.
I would like to discover bugs as late as possible.
I would like to invest in analysis and design for things that might not be built.
I would like to get my software in one delivery, all or nothing.

Great Stan. You've summed up well the mess I'm in

I would like to invest in analysis and design for things that might not be built.

This makes me think about a program I've just finished. For testing purpose, I received a simulation sheet with all data patterns we may have. I was surprised that there were patterns I didn't even think of, and of course, did not support. I asked and I was told that there were no such patterns. So why did you put that in the doc ? "Well, we might have to support that one day. But not now. We just put everything here". I thought that was wasting both their and my time.

I probably remembered most of that list from the wonderful Waterefall 2006 convention site.

The practice of writing complete use cases and putting them under change prevention, er, control encourages us to put everything we can possibly think of in them. We start to think we're being paid by the pound and make up requirements all day long.

I've only gotten a fraction of the way into agile, but the bits that paid off the biggest were breaking use cases into story sized chunks and prioritizing them with real live index cards. At first a fair number of cards fell off the end of the sorting table, right into the trash. Eventually we just quit making up junk requirements.