Requirements, specificaion and design are these three things that happen before you get into writing any code (or testing it), and from experience it’s tricky to properly disentangle them. This matters, because what the customer actually wants is something that fulfils the requirements that they want, but the natural way for us developers to think about things is in terms of design, and so can end up focussed on the wrong thing!
Here’s a simple rule of thumb that lets me spot when I (or someone else) have mixed these up.
- Requirements are WHY we are doing what we’re doing.
- Specification is WHAT we’re doing.
- Design is HOW we’re doing it.
For example a statement that says “The customer needs a link at the top corner of every page on their website that takes you back to the home page.” sounds very much like a requirement. But putting a link at the top corner of every page on the site is a WHAT, not a WHY – so that’s specification pretending to be a requirement. The actual requirement is probably something like “The customer wants to be able to get back to their home with one click.” or perhaps even “The customer wants their site to be easily navigable.”
Have a go when you’re creating or reviewing any or all of reqs, specs and designs. Does this help? Does it not? Are there obvious exceptions? Let me know…