In Scrum and/or other Agile methods how do you handle versions of requirements simply? I assume that there are plenty of organisations who are Agile but also need to keep a track of requirement changes for regulatory purposes and so on.
You may have a requirement in version 1 which is substantially altered in version 8. How do you track that kind of change between releases?
You could version your requirements document(s) right along with the source code... that way, you'd have the documents that detailed the requirements at any point in time, along with the code that implements (or attempts to) those requirements.
That being said, I don't think this is any different in "agile" or "scrum" than it is in any development process.
There is nothing built-on SCRUM that resembles requirement version management. That you require it may be a sign that you are either not really implementing SCRUM or that SCRUM is not the right process for you. If I had to implement something similar I would first look into your product backlog (from which detailed sprint tasks are derived) and map stories/use cases/requirements versions to them, then I would check for updates on already released items during sprint planning to see if a new "update code to match requirement" task are required for the sprint.
(I'm avoiding talking about agile as there are hundreds of agile processes out there, perhaps somebody else can give their point of view on AUP or Crystal Clear)
A wiki linked to your user stories / requirements tool is probably your best bet.
We use Assembla as our main collaboration tool for our agile projects. It has a wiki where you can document your requirements and a ticketing tool that can be easily linked to the wiki (and code check-ins) through simple tags for requirements traceability.
Both the wiki and the ticketing tool keep history, so it would be easy to view and document changes over time.
As others have mentioned, from a process perspective, it's probably better to break down your requirements / stories from epics into smaller stories and ADD new stories to capture new requirements as things progress. The tool I mentioned (and I'm sure several other tools) allow you to do this easily and link the items together if you want to see how a feature progressed or was added to over time.
Why do you need to track requirement changes (I have a lot of reasons, but what problem are you trying to solve?). Do you have the option of building your product iteratively or do you need to figure most of it out up front ?
If you are able to build iteratively, I would skip requirements version management. Individual sprint deliveries will define the product at different points in time. The next sprint backlog will define committed work.
The master backlog or wish list can change as needed. It may not be necessary to track changes as the work hasn't been committed.
If you do need more control, I like Paddyslacker's recommendation of a Wiki. Most other mechanisms don't handle the relationship concepts of epics and the break down of requirements. I have always found a single file to be insufficient for complex features.
You didn't mention what platform you develop on but if you use TFS; it keeps track of all changes to Backlog items, when they were changed, and by whom.