I admit that after finishing CS course at the university I had the same mindset regarding software engineering: understand the context, capture requirements (as

I admit that after finishing CS course at the university I had the same mindset regarding software engineering: understand the context, capture requirements (as much of them), and stick to it while developing subsequent parts of the system. In many occasions this is a trap: many details are just secondary, and would have probably never been articulated by the customer. Some of them seem to be important but then they are not. Sometimes some important problems appear somewhere around the end of the development, but we already have spent a lot of time working on some secondary issues. Dealing with complexity by reducing or ommiting some problems are vital also for small and medium projects. This encouranges rapid creation of some working prototype and the overall process tends to shift towards more iterative development.