writing requirement docs

Any design answers some set of requirements. Were there no requirement (no need), the design wouldn't be created. These requirements must be documented - for two reasons:

• So that the design/creation/coding will be guided and not arbitrary. The design is complete when it answers all the requirements - no less.
• Some time after the project is completed, the requirements serve as a very good documentation. When you look at a design, you ask "what is it supposed to do ?" before you start figuring out *how* it does it. Requirements answer this question (at least well-written ones).

There's another benefit to explicitly specified requirements: they impose a hierarchical/modular structure on a design. For instance, the project must be able to do X. It delegates these tasks to other projects that have to do A, B, C. There are written requirements that specify X, and there are written requirements for A, B, C. The design document of X can then say that some of the requirements are implemented by A. The requirements document of A can say that some requirements come from X.

Requirements also are a "high level debugging tool". Ideally, one person writes the requirements, and another person implements them. Say the project leader of X assigns tasks to A, B, C (each of which can be a whole team) and writes the requirements for them - what X expects to receive from A, B, C. When A, B and C finish, a design review can quickly come up with problems. Where is this requirement implemented ? Where is that one ? Etc. "Where" should precede "How".

This may seem like a dull way to work, but it's very important for long term projects (think 5-10 years), where people tend to come and go. The biggest challenge is not creating the requirement documents in the first place. The biggest challenge is to keep them updated as the project progresses.