To help your project not run away with scope creep, gathering requirements up front from the users with the business, development and QA all together to discuss them is the best defense against run-away requirements.
One everyone agrees on the requirments get sign off from them all, and include the statement that anything new WILL increase time, money and effort estimates for the project.
You can't tell them "no, I won't." they're paying the bills. What you need to do is detail the risks to your project time lines and costs if you add more stuff.
"Never doubt that a small group of thoughtful, committed people can change the world.
Indeed, it is the only thing that ever has." Margaret Mead
In addition to what Jean said, having an updated status of all the requirements could be useful to know at every moment how many requirements are open/analyzed/... approved/implemented/tested.
Don't foget to keep everybody interested informed with the requirements status.
Having a clear change management process/tool could also help you.
... Not even me.
I dont know how much this is feasible in your case.
We had an application which we divided into 10 modules (test modules). Had a similar problem and it had deteriorated into the last published requirements being unrecognizable to the latest build.
Then we (QA/Test) were forced to take a risky route: We started publishing (via email) the requirements (more techincal than functional) to the individual module owners and added a caveat(threat) in the mail saying if the requirements are not challenged we would test against them and open defects if not met.
As Jean suggested, accepting the fact is the greatest challenge, I had great difficulty in doing so when i moved to the current assignment (my earlier posts are testimony).
Along the same lines as what Jean said but I just wanted to add - adjust your schedule for the changed requirement and show the powers that be that this changed requirement will add X amount of time to your testing. They probably won't give you X amount of time (or they might - my company actually does) so then go over your schedule again, figure out what you can drop and then let the powers that be know you'll be dropping the testing of Y and Z to accomodate for new requirement X.