Requirements are design decisions

I believe that the success of software development projects and many other types of initiatives could be greatly improved if we came to terms with a simple insight:

There is no such thing as a requirement. A so-called requirement actually is a design decision.

Why does this matter? First and foremost, I think we want to consciously make potentially far-reaching decisions, especially when other peoples’ lives and livelihoods depend on them. (Well, this dependency might be more pronounced in your business decisions than mine…) Second, when we see these design decisions for what they are, we can make them more effectively, e.g. by applying design methods to them.

Requirement statements are best understood as statements of stakeholders’ interests, needs or wants. Rather than taking them at face value, we ought to seek insight into the stakeholders’ deeper, underlying motivations.

For example, stakeholders frequently express perceived mechanisms for achieving desired ends as requirements. Identifying these desired ends will often lead to discovering better ways of achieving them.

Design decisions come in two flavours: decisions relating to the problem space (i.e. ultimately deciding which problem to solve) and those relating the solution space (i.e. ultimately deciding how to solve it and implementing the solution). Rushing to working on the solution may feel like progress, but this might well be progress in the wrong direction.

A request: I know that I’m not the first one to state that requirements are design decisions. Please let me know if you know who said this first (or, at least, early). Thanks.


7 thoughts on “Requirements are design decisions

  1. Gene Hughson

    Interesting premise, I had to read it twice for the light to come on (my issue, not yours). I think I like the concept that what we call requirements (those done properly) are the design of the problem space.

    1. Oliver Baier Post author

      Thanks, Gene. The problem space often seems to be neglected in enterprise IT contexts. The benefits of expending effort towards the solution are obvious to decision-makers, while inquiring into the problem space seems almost counter-productive (or at least alien) to some.

  2. Pingback: Faster Horses – Henry Ford and Customer Development | citizentekk

  3. Pingback: Faster Horses – Henry Ford and Customer Development | Form Follows Function

  4. Pingback: Faster Horses – Henry Ford and Customer Development | Iasa Global

  5. Pingback: Enterprise Design Framework: Frames | Oliver's Blog

  6. Pingback: Faster Horses - Henry Ford and Customer Development | CitizenTekk

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s