Differing views of managing software requirements

I hope this is doesn't become a habit that I bitch about non-technical people, though I may have intentions to do so.

Coming to the topic of my opinion, there are two views of software development.

i. Build the perfect system handling extreme cases though the extreme cases will not be encountered for the next couple of years. Consider a service aggregation where multiple service providers sign up. Users can choose the services that they are interested in and pay for it. If the business is not yet ready to bring in multiple service provider for the same service (say payroll), it makes no sense to build the software up-front to handle features like the priority, pricing etc.,
The business must be a very powerful one to get such multiple service providers sign up with them. If that is the case, why should the software be designed for it up-front. When the business spends the efforts to rope in multiple providers, the logic for the priority and pricing will have to be reviewed and changed as there will be a better understanding of the problem.

ii. I am fine with an approach where you treat software as an evolving beast. Address the requirements that would be useful right away for which the efforts are proportional to the effects. In web lingo, what is the cost per click - if you were to measure the cost in developers' time. If there is a reasonable doubt that a feature will be useless for 50% of the users, it makes sense to drop it and focus on something more important.

Often I come across bosses, mostly non-technical who want to take the first approach. I would bet that less than 10% of such over engineering done ahead of time is useful.