There are several conditions under which it might be appropriate to have less detail in the requirements. If you have customers interacting closely with analysts and developers, you don't need as much written requirements documentation. You can also write less-detailed requirements if the developers have extensive experience with the application domain. If you are building a system that is based on or derived from an existing application, such as when reengineering a current system, you might not need comprehensive requirements. If your project intends to acquire a commercial package solution to meet some or all of the project's needs, there's no point in writing detailed functional requirements because the people who built the package have already done that (at least we hope they did).
In contrast, if you plan to outsource development, plan to have highly detailed requirements. With outsourced development you don't have the many opportunities for day-to-day interactions between developers with questions and customers with answers. You have no choice but to provide richer information in written form. If your team is geographically dispersed, you need to develop a richer shared repository of requirements and project information. To perform comprehensive requirements-based testing, those requirements need to be detailed enough so that the testers know what the expected system behavior is under many circumstances.
No requirements specification will fully describe every product detail. Nor will even the best requirements specification replace human dialogue. But the factors I listed here will help you decide when your requirements are detailed enough to avoid unnecessary risk.