At the functional test level, requirements generally are not the main focus. Requirements are the input to the Architecture, so reviewing the Architecture to ensure all requirements will be met is critical up front, to minimize the chances of having to change the architecture (and everything else) late in the development cycle. The test phase which best verifies the requirements were met is the 'Usability Test' or 'Customer Acceptance' test. If this test will be done by the customer, it is generally wise to include some requirements testing in your 'System Test'.
As for requirements 'changing', that is a pretty serious situation. If the requirements change, that is likely to have ripple effects throughout the entire development cycle (redoing everything to some degree), and any testcases based on the requirements are likely to have to change. And the change probably won't just be in the description...
For instance, let us take perhaps the simplest possible change to requirements. Let us say that a requirement is that 'the product can have up to 10 users simultaneously'. And after your function test(s) are written to try 1, 9, 10 and 11 users, the requirements are changed to be 15 users. Now the test(s) for 10 and 11, at least, need to be changed to 15 and 16, and you may want to reconsider the 9 test as well.
John