Specs are a necessary evil as they are painful to write and painful to read. Documents that are too long tend not to be read, while a lack of detail can lead to a distortion of the original vision.
I have found that verbal communication is the best way of getting a project through to the team. This also help get everyone involved and spot opportunities. The spec then plays the role of documenting the group decisions for later reference and the QA process.
Too much detail can be problematic in some cases. Specifying only the details that affect the end user allows development to make smart decisions on the implementation. All too often, development spends time coding a detail that will not have a user impact, just because it was in the spec.
AccessibleNobody likes to read specs. The more steps there are to get to the document, the less your stakeholders will revisit updates. Systems like wiki’s provide quick access and organic growth.
UpdatingWhile we love to call a spec final, it's never really done. As development starts, the spec needs to be tuned. Keeping it up-to-date is important. Again, systems like wiki’s provide an easy way to update and deliver new versions.
Save PaperThere is no harm in saving in few trees during the SDLC. Promoting the use of electronic copies will save a fair amount of paper and also lessen the chance for stale documentation.
