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:
- 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.
- 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.
- 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.
- A good requirements spec will contain "anti-requirements", explicitly spelling out things that should not be done.
- 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).
- Every piece of code in the project should exist because it helps meet one or more requirements.
- 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.