Writing project specs

Eric Sink wrote a long post about writing requirements/specifications for a software project.
He lists lacking specs as a cause for project failures, since the people that came up with the ideas are not the people implementing them.

And he lists some useful pointers:

1. A spec needs to be in a form which is accessible to more than one person. It needs to be written down, either in a computer or on paper.
2. The spec should be logically broken up into a bunch of little pieces (bullets). Each piece should be a self-contained statement about one single detail of how the software should behave.
3. A good requirements spec contains priority information to help the dev team make the right trade offs. If some requirements are more important than others, the spec should say so.
4. A good requirements spec will contain "anti-requirements", explicitly spelling out things that should not be done.
5. If we choose a development process which rigidly requires a perfect spec before construction can begin, we are just setting ourselves up for pain. We need to be a bit more agile (flexible).
6. Every piece of code in the project should exist because it helps meet one or more requirements.
7. Every requirement needs to be tested.

Regarding item 7, I recently read about an interesting emerging framework, used to write demos the same way you write tests. It's called "NDemo".

As an interesting side-note, Eric also mentions a new ALM tool which is about to be released from SourceGear, called "Fortress". It should be interesting to compare this tool to Team System.