First of all, in my opinion documenting *all* the requirements to such a detail up front is a lot of waste. One reason is that it delays coding, and thereby delays getting feedback from the first version of the real system (as well as some possible ROI), another that those requirements are very likely to change over time.
So what I would start with is just a list of very high level description of the requirements. So high level that a stack of index
cards (one card per requirement) would just work fine.
The, shortly before you actually implement a requirement, you begin to detail it. In my opinion, the very best you can do is describing it in a set of automated acceptance tests, for example using something like FitNesse.
Depending on your situation, that might be too much of a change to swallow it in one bite, of course...