Good Requirements Documents
Developers come from all backgrounds, but a well written requirements specification can fill in their knowledge gaps and clearly explain the business and the objective of the user. You may not think a developer should be writing requirements, but if you can find a developer that is also a good communicator and good writer, you essentially have a business analyst that understands the complexities of software development, which is better than having a business analyst that doesn't understand the real complexity in software development (and there are a lot of those running around).
Karl Weigers once wrote that if you miss the requirements then it doesn't matter how well you execute the rest of the project, you are at increased risk for failure (and that's putting it a lot more mildly than he did). A good requirements specification doesn't have to be monolithic (although if the cost of failure is loss of life, then perhaps it might have to be) and a good one will get everyone, not just programmers, but also analysts, managers, project managers, subject matter experts, and end users on the same page.
Experienced developers know that the synergy of good domain knowledge, programming skill, and communication is important to successful software projects. A requirements document (on paper, wiki, or any medium) is a good part of that, not only for the beginning of the project, but also for life after go-live.