Requirements and constraints
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?
In the beginning of my professional life, working as a product engineer, I had to search for recipes that could be used in the industrial production of artificial leather for the automotive industry.
.
One of my most inteligent and tough customers was VW. I remember one particular specification where they were looking for a particular elongation and resistance and, at the same time, a limit for the plasticizer content in the formulation.
.
In that case I think taht the plasticizer content was both a requirement from the customer “thout shalt not have more than 33% w/w of liquids” and a constrain for me because without that limitation the solution would be much more easy and less expensive.
.
Can you help me with these ideas?
Many thanks – nice example!
Yes, there are plenty of cases where constraints either act as requirements, or spawn off a bunch of requirements in response to constraints. This is a really good example of how that happens.
In a strict formal sense, the requirements are “a particular elongation and resistance”; “a limit for the plasticizer content” is arguably more a constraint that is then regarded as a requirement – exactly as you described (“both a requirement from the customer ‘thou shalt not have more than 33% w/w of liquids’ and a constrain for me”).
In some ways it’s a matter of perspective: a requirement from the customer’s perspective is a constraint for you, and so on. (It’s a bit like architecture versus design, or ‘why’ versus ‘how’: something will usually be both, but in practice will often be seen as either one or the other, depending on which way we look at it, and from where we look at it.)
As we go down closer towards implementation, a classic waterfall-style project-model will describe everything as requirements, because it purports that all of the balance between requirements versus constraints has already been decided. If you’re working in an agile-style development, you’ll need to keep aware of the constraints at all times (i.e. a principles-based perspective, rather than a rules-based one).
If we explicitly include and respecte the constraints as constraints rather than as ‘requirements’, it frees us to make different and often better choices. To use your example, the fact that you weren’t allowed to go for the ‘cheap option’ of high plasticiser content, or (I imagine? 🙂 ) for the ‘expensive option’ of lower-plasticiser content for more expensive material, would then have usefully forced you to find with a new way of resolving the requirements that was both low-plasticiser and cheaper to produce.
I don’t know if that helps? – would be happy to explore more on that, if you’d like.
Thank you,
I understood wrongly your statement “requirements and constraints are two sides of a conversation that we have with the real world” in the post. I understood that they were different things.
Your comment “In some ways it’s a matter of perspective” made me go back and re-read the original text. My mistake.
BTW, I like your statetement “If we explicitly include and respecte the constraints as constraints rather than as ‘requirements’, it frees us to make different and often better choices.” Made me remember a quote that I like a lot “Life (animal life) doesn’t plan, it runs away from constraints”
Hi Tom.
You get the same situation when you try to satisfy a set of requirements that compete in some way. The classic time/cost/quality triangle in the project management space is a good example. So we must be satisfied with an outcome that addresses all three dimensions adequately. And the need to satisfy all three is itself a constraint. The time/cost/quality model identifies the interdependencies amongst the requirements and so presents the problem as having to deal with all three dimensions simultaneously.. In many ways architecture is all about identifying such interdependencies and articulating the situation as a set of constraints that must be respected and then planning a trajectory through the resultant space that satisfies each requirement adequately. There is an interesting chapter on the whole notion of requirements in Christopher Alexander’s ‘synthesis of form’ which resonates with the themes in this discussion. It is worth the look. Also take a look at the TRIZ framework which is based around the notion of addressing conflicting requirements, problem solving and design. It grew out of the analysis of international patents. Again I think it is worth a look.
Regards
Robert
P.s keep up the good work.
Great Tom! I think you should add assumptions in this comparison too. I see all the time people mistaking assumptions with constraints.
Very good point, Alan – thanks!
One of the realizations we had was that we can practically simplify the way we deal with Constraints, Assumptions, Risks, Requirements, and Dependencies (CARRDs). (“We” means the Core Team working on the 3rd version of the BABOK Guide.)
The short version (without the rationale) is this:
* If it affects the solution, rephrase the CARRD as a Requirement. Allocate it to the relevant requirements repository for action and management.
* If it affects the change, rephrase the CAARD as a Risk, and allocate it to the project risk manager for action and management.
* If it affects the organization, rephrase the CAARD as a Risk, and allocate it to management for action and management.
Requirements and Risks both have probabilities and impacts:
* Requirements that have positive impacts if they are fulfilled are usually called functional requirements. These are measured in terms of potential benefits.
* Requirement that have negative impacts if they are unfulfilled are usually called non-functional or quality requirements. These are measured in terms of a scale of acceptable and unacceptable consequences.
Thoughts welcome!