My experience of business requirements vs developer requirements are a bit more simplistic. I have found the business types spend far too long brainstorming new features and then telling clients about them. The client immediately says "Yes, we need that now!!!" and then the developers are expected to get the new feature integrated ASAP. The problem is that they may not do a great job integrating the feature due to time constraints resulting in various fragmentation issues in the long run. I've had this conversation many times "It's working, but the back end is ugly. I'll have to tidy it up ASAP", "Can we deliver it to a customer right now?", "Err yes, but...", "Don't care it's good enough".
I think the key to preventing developer/business conflict is having a road map. That way the business types can get the features they want and the developers can think ahead about new features they will have to add.
Most business/programmer conflicts I have encountered are nearly always due to the sales people overselling the product. My old IT director, a formidable man who took no nonsense, announced that we would not add features unless they were in the road map. The CEO overruled him so nothing changed.