Good Requirements - Part VIII - Design Independence

I have seen people call requirements by names such as: business requirements, functional requirements, functional specifications etc... To me a rose is a rose is a rose.

I normally use a very simple document structure to store my requirements. The level of detail increases as one moves from the Business Strategy to the High-Level Business Requirements to the Functional Requirements and finally to the Functional Specifications.
This setup allows for full traceability.

The high-level business requirements and functional requirements should be written to be design independent. This is one of the most important guidelines that should be followed. High-level requirements must answer the what question. If high-level business requirements try to answer the how question, it may bias or jeopardize the solution.

One of the problems with allowing a high-level requirement to be design dependent is that the true requirement may be obfuscated. Consider this, on one requirement gathering session I was told that, "We need the ability to clear the cache (on a server.)" After a lot of investigation, I found out that the actual need was, "the ability to publish content to a web site." If the original articulation of the need was used, the final solution could have been very different and not met the need.

That is the pitfall that one can run into when high-level requirements are not design independent.