A few points:
1. You can tailor RUP to be as effective, or as ineffective, as you like. We highly recommend making it as light as possible. Having said that, many organizations seem to ignore that advice, and often suffer as a result.
2. If you tighten the feedback cycle and deliver working software based on the transient requirement as quick as possible, you shouldn't have this problem. For example, if you model storm the details of a requirement then an couple of hours or days later have it implemented, and the stakeholders are happy and tell you that you can go on to something else, what could the problem be? If they change their minds a few weeks or months earlier then simply ask them what they want now and make the appropriate changes.
3. You don't need to trace because of the reason that you define because the customers would implicitly have accepted your work at the time that you did it. If you don't have their active involvement in the manner that I describe then you need to start worrying about a lot more documentation, reviews, sign offs, ...

Sadly, the traditionalists seem to a lot of relatively uneccessary busy work due to the long feedback cycles that they prefer.

- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM
http://www-306.ibm.com/software/rational/bios/ambler.html