One of the values of the Agile Manifesto is "working software over comprehensive documentation". And yet there is a need for requirements to be documented. If a feature developed 6 months ago is being altered, I (as a developer) need a place to go to to reference the existing requirements. Documented requirements are obviously important for QA resources as well. Also, if a question arises about a particular requirement, there should be a single location one can reference for clarification rather than requiring me to parse through my code or a string of emails to see how things where built.
The Agile teams I've been on have all used an online management (eg. Rally, Jira) where requirements can be defined under each user story as acceptance criteria. While I find this to be an extremely functional solution/location for requirements documentation since you're constantly using the tool to move the story along, it seems a little informal. On the most recent project I worked on, the project management team maintained a BRD (Business Requirements Document) which contained all system requirements in a single document. On this particular project, the BRD was used for sign-off from the client on what was going to be developed and was also reviewed by my (consulting) company's management team to ensure everything was completed. The issue with BRDs in my experience is that they're verbose to the point of unreadability.
The Agile framework does not concern itself with defining a specific means of documentation, but is there a single best practice for documenting requirements on an Agile development project?