Q:

Would you use UML if it kept stakeholders from requesting changes frequently?

As much as programmers hate to document their code/system and draw UML (especially, Sequencing, Activity and State machine diagrams) or other diagramming notation, would you agree to do it if it kept managers from requesting a "minor change" every couple of weeks?
IOW, would you put together visual models to document the system if it helped you demonstrate to managers what the effect of changes are and why it takes so long to implement them?
(Edited to help programmers understand what type of answer I'm looking for.)
2nd edit: Restating my question again, "Would you be willing to use some diagramming notation, against your better nature as a programmer, if it helped you manage change requests?"
This question isn't asking if there might be something wrong with the process. It's a given that there's something wrong with the process. Would you be willing to do more work to improve it?

A:

Your problem is a lack of communication between you and your managers/stakeholders.
They don't understand the problems that making frequent changes can cause - even if you have an agile process in place.
But equally the developers don't understand the need that the program is designed to solve or the business process as well as you should.
Why do I say this?
If the managers were familiar with the development process then they'd know when was the appropriate time to request changes - before the start of the next sprint, or when the design document for the next phase was being written etc.
If the developers understood the problem better then the product would be closer to the needs of the stakeholders.
You need to address the communication issue and put in place procedures to manage the change - because change will happen.
Hiding behind UML diagrams (or specifications, or even story cards) isn't going to solve the problem.

A:

Gernerally speaking if minor changes required updates to UML diagrams then I would consider the diagrams to be too detailed. I have found the best use of UML diagrams is to succinctly convey the design of a system. It's incredibly beenficial to be able to look at a class diagram or a deployment diagram and get a feel for the software compared to trawling through code or trying to suck the information out of other distracted devs. 
I think the mistake a lot of people make - including me when I first started modelling - is to think that the model has to be of 100% complete. For example class diagrams can very quickly get unwieldy if they include every single class in a big project but often there are a lot of utility classes for logging, loading configuration settings etc. that don't really add a lot to the picture and can be ommitted.
However there are also cases where more detailed UML diagrams may be useful. In particular activity or state diagrams can help clarify how a particularly tricky piece of business logic is working. In those cases it is a very good idea to change the diagram for every small change as a way of keeping track of the business process.
UML and modelling are a balancing act. If the incorporating the changes your manager is making into the diagrams make them more useful then add them. If on the other hand it takes you longer to make the changes to the models than it does to write the code then perhaps your UML is too low level.

