One reason that waterfall method I mentioned actually managed to produce a working system was that the customer (together with all the companies working on the

One reason that waterfall method I mentioned actually managed to produce a working system was that the customer (together with all the companies working on the project) put extensive effort into the requirements phase. Working on the requirements and removing requirement conflicts (a very common thing), understanding of requirements, feasibility of requirements etc. etc., and, at the final stage, a week-long meeting with everyone (customer, companies) to work out the last kinks. Only after that did the next phase start: Creating software requirements from the system requirements, and from there, an architecture and so on. And, as this was something involving many companies in many countries and even continents, having everyone on the same page was essential. And it did work. Of course in the years following the project there would be bugs etc, but not fatal ones (which are typically caused by errors in the requirements- and architecture phases). (We had several projects of the type above, and those which had more problems were those were the requirements phase wasn't as extensive) EditAdd: Just to be clear - I don't think the pure waterfall model is the best way to work. However I did learn a lot from it, particularly how important requirements are. And the forth-and-back-and-forth-and-back on this which can happen in Agile projects isn't really the solution either.