What’s the difference between requirements and constraints? How do we identify and use them in change-projects and in enterprise architectures?
This is a query that came up in my web-stats yesterday – and it should (I hope…) be one that I can answer in a way that’s short, simple, straightforward and uncontroversial.
To me, requirements and constraints are two sides of a conversation that we have with the real world, regarding any desired change:
- requirements describe what we want to happen
- constraints describe real-world limits or boundaries around what we want to happen
There’s a mutual-pair or flipside-of-each-other relationship between requirements and constraints, very similar to that between risk and opportunity: we can never have one without the other. (Sometimes it might seem that there’s nothing but constraints, but actually we wouldn’t even notice those constraints as constraints unless we have a desire – a requirement – that things be otherwise.)
Some other comparisons between the two that are useful, though rarely absolute:
- top-down versus bottom-up: requirements are top-down (from strategy to execution), constraints are bottom-up (‘this is the real world talking…’)
- inside-out versus outside-in: requirements are inside-out, constraints are outside-in
- enterprise-architecture versus solution-architecture: enterprise-architects often focus more on requirements, solution-architects often more on constraints (though both roles must achieve appropriate balance between the respective requirements and constraints)
- opportunity versus risk: requirements are often viewed as aligned to opportunity, constraints are often regarded primarily as risks
As with the relationship between opportunity and risk, it’s really important not to regard requirements and constraints as being inherently in opposition to each other. Real-world constraints such as new regulations or environmental technical limits can be important sources and drivers for innovation – which, for commercial organisations, can create sustainable differentiation and competitive-advantage relative to organisations that see constraints only as something to override or ignore.
Enough for now, but anything else you’d suggest we should add here?
