One of the slides in the lecture I'm giving tomorrow.
The course is COMP8100 Requirements Elicitation and Analysis Techniques.
Note there's a lot more stakeholders than just the users and those who pay for it: those who are supposed to build it have to be involved in the requirements analysis too. Not much point stating requirements for something that can't be defined properly, or built within time and budget, or which can't be tested. Or which is so brittle that entirely foreseeable future requirements can't be met.
All you can do is state the aims, then enough detail about how those aims are to be met in a testable fashion that everyone can agree on is feasible and useful. Compromises usually have to be made, so there's a matter of prioritising the requirements too.
Rocket Science... yes, it is, sometimes.