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.