Thanks for pointing me to this post in the first place. Your views are nice and i prefer this as one of the good approach to handle this kind of debates.

But then, things may not be that smooth or simple in all the scenarios.

I work for a product development company and most of the requirements will be captured by the Sales / Architecture / Management Team with some inputs from the Customers.

Here the requirement is not specific to a customer and the big problem as i said earlier is the Clarity on the requirements itself.

In product development, there will be different customers and see all these requirements won’t come in from them.

As i said above in my post
The root cause for most of the scenarios from my perspective are that

1. Clarity on the requirements across the teams (Management / Sales / Arch / Dev / Testing)

2. Attributing the Technical Limitations to the Requirements and not disclosing the same

3. Not coming up with the required documents that will clarify the ambiguities

4. Lack of understanding on how the Systems behave in general ( Take a step up and see how this should behave in the real time )

5. Taking things personally instead of understanding the System

I blogged about this topic here …

http://shrinik.blogspot.com/2006/09/bug-or-feature.html

Shrini