"Thus spake the master programmer:
'When the program is being tested, it is
too late to make design changes.'"
(The Tao of Programming, G. James, 1987, pp. 31)
You all recognize this, don't you? You're almost done with the release and there's your customer demanding a change. It's frustrating, but understandable. I would do the same thing as a customer... not on purpose, but sometimes you just think of things you want when the project is already well on it's way.
There are ways of dealing with this. You can develop your software in increments and test these increments or you can work in sprints and demo the product at the end of every sprint. So use RUP or SCRUM or another development method to be able to react to design changes in an earlier stage. These methods will work, if used correctly. Sometimes a project fits well in a development process, other time it won't. Don't get too hung up on a single development process, eventually it's comes down to communication and visualization.
Always communicate with your customer. Tell them what they're going to get, tell them what they won't. Tell them the consequences of their wishes and requirements. But most of all: listen. Your customer has to work with the software. Listen to what they want and help them with thinking about what they want.
Software development is an abstraction of reality. It's hard to abstract the reality that is your daily work. It's even harder when you are a non-technical person. If we help our customers with thinking about the abstraction of their reality, which is the software they're going to get, it's easy to assume that you and you're customer are on the same page. It may seem that way, but you never can be sure unless you visualize the abstractions to them. Show your customer diagrams, screen designs, process designs. Even better: show them a working demo. The more you can visualize what you're doing, the better your customer will understand an be able to think the software trough. In the end this will lead to less late design changes.