I think the OP is confusing UML (a language for modeling) with requirements management (a process). Modeling your system in UML is not going to stop users from asking requirements. You use UML to capture your architecture and to map requirements to artifacts. A requirement change would invariable represent a change in your model.
These are systemic problems that you just don't "UML it out". There are things to consider here:
Too large of a change, then either the request is disruptive, or your UML does not relate to the actual system, or your system has an inflexible architecture.
Rate of Requirement Change
Too frequent changes will cause you to 1) update your model and 2) deliver. So without a requirements management process, you are going to UML yourself to death, thus decreasing the rate of at which you produce results.
You could say that your productivity is inversely proportional to the rate of requirement change multiplied by a factor representing the UML "crust" artificially added to a process.
I would suggest you get a book on requirements management, and learn a bit about the way Scrum handles requirements. Say you previously had a requirement R, and the user now wants a change on R, say R'. Then you treat R' as new requirement with its new timeline. You have to communicate users that requirements changes have associated costs.
Also, it would do you well to study a bit of systems engineering and the concept of requirements as being:
- A change request on a requirement is
a defect on the requirement. Thus,
it creates a new requirement, and
puts the onus on the originator
(typically the customer.)
There is such a thing as an invalid requirement. A requirement request that does not fill any of the above is an invalid requirement. And in a good process, the development team has the right to reject a requirement.
I mean, you ask an architect to design you a house without windows, he'll walk away. Or you ask repairman to fix your roof with clear tape, he'll give you the finger and walk away. Ask a dentist to remove a tooth from you using a pair of bolt cutters, he'll hit you with them and kick you out.
Only in software you see this notion that all requirements are valid and that they must implemented whatever the cost.
I recently put an answer to a related question, on requirements management and engineering. Maybe you might want to take a look at it. I hope you you find it helpful
How do you deal with changing requirements?