Better Business Requirements

Some of my developer colleagues are in a software project that is a total mess. They are very frustrated that the business users keep changing their minds between when they set their requirements and when it comes time to make a release.
From my distant view I can see a couple of things that are not working in their favor. They are not communicating well. If the software development team is not meeting the business users' expectations, then there is a communication problem. The business users say one thing and the developers do another.
I think a lot of this comes from my company's process of setting business requirements. It puts the project into business terms that are not native to the business process or descriptive to software. The process of creating requirements should be an understanding of what the users want and what the development team can deliver. If you set the requirements and the expectations in visual terms, i.e. pictures and simple diagrams, then people will have a concrete image of what they want. When the delivery of the software comes around, there will be far less surprises.
The second thing that I notice is the development team kowtows to the business users' demands well after the requirements have been made The requirements are effectively open until release time. This has nothing to do with agile methodologies, it has to do with business users who are not accountable for their actions. The business users who are setting the requirements are also not funding the project. They have no accountability for the hours that are spent creating the product.
When the business users see the software when the development team is getting close to delivery the release is not as abstract as when they specified it. They then can see that the product is not what they wanted. They let the development team know that it is unacceptable and they say what they want. It's like the initial design and development stages are really just a prototype and the user acceptance stage is when the real requirements get set. This puts a tremendous strain on the development team because the release date doesn't move. This puts absolutely no strain on the business users though, because the project isn't coming out of their budget. They realize absolutely no penalty for vague requirements.
I would propose that instead of giving the business users a free pass that the development team stops allowing changes in the business requirements after they are set. Any changes after they are set go into the next release. They will deliver something that the users don't want, but the users will then have an incentive to give thoughtful requirements during the requirements phase.