
We do not want a heavy level of documentation for requirements. Take an example from Scrum. They have something called a backlog which prioritizes requirements. This is a good methodology to manage simple requirements.
You would think that complex requirements could be broken down. The problem is that if you do break down the requirements, the smaller pieces might not make sense by themselves without the context. You need to try to group the smaller sets of requirements in a smart fashion for this to work.
Just like traditional object oriented analysis and design, you should break the requirements into use cases and scenarios. The use cases should be simple. There should also be very little documentation.