Requirements, specifications and design

RuleOfThumb
A Rule of Thumb

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…

 

Advertisements

2 thoughts on “Requirements, specifications and design

  1. What do you think about the ordering of these? I’m asking as I’ve seen several projects where these don’t happen linearly:
    – sometimes I’ve seen them all happen at once (requirements develop alongside the specification, as understanding of the needs of customers develops, and impacts the requirements).
    – Sometimes the design may even have come first (e.g. if you have no idea what is technically possible, and have many soft requirements/aspirations, and the design helps identify which of those soft requirements are actually tenable, and so become the requirements).

    Like

  2. I think my response here comes in two parts.

    I don’t think there’s any explicit reason that these must come in a particular order (or need to be in carefully separated documents, or anything like that). I’ve seen successful projects start with a careful requirements process in “classic waterfall” model, and I’ve seen successful projects start with a design (or even implemented code from a hack-a-thon). In fact, as the what, the how and the why are all interlinked, it’s absolutely right to consider them all together, rather than each in a vacuum.

    That said, it is really important to keep clear distinctions between design, specification and requirements. Failure to distinguish these is one of the things that leads to that most expensive of project failures: successfully building the wrong thing. I’ve seen that happen often (and done it myself!). For that reason, even when working in an agile model, I would strongly suggest keeping requirements, specification and design clearly separated (at least in separate sections, if not in a separate document) – and explicitly reviewing each to make sure that they don’t “leak”.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s