No idea

The challenge of getting the required information is well-known among testers. Even if you get the required documentation, what you really need is missing. I have seen a broad variety of documents with different levels of quality (from excellence to unusable) but the experiencie I liked the most was a project that combined two very different approaches in two different phases of the project.
The project started as an XP approach where the system was built from scratch; as the tester, I worked with developers and the project leader. During that time I learnt the application inside out, even though there was not much documentation around. After the program was shipped, we shifted to phase 2, from XP to a more classical approach where the developer and the BA wrote just rough specifications. After the initial version was built, I got release notes with valuable background information written by the BA and the developer. Even at a late stage in all the following phases, reading those release notes was enough for me to understand exactly which extensions were introduced and where I had to look for defects because I knew the application well from the first phase.

In another project that came with poor documentation, target users tested the system every six weeks for a whole week. During that week we delivered fixes every day and agreed on new features for the next iteration. The product quality was amazing. RUP and XP were foreign words at that time.
In cases were no or or poor documentation is around, I ask developers to present the features they have introduced rather than forcing them to write poor documentation that contains only half of the required information. Rather than focusing too much on requirements documentation, it is more imporatn to have the team close together and make sure you get the information you need to come a comain expert of the AUT.