Requirements vs constraints

This one’s a follow-on to a comment in one of the Content Economy articles I referenced yesterday:

What is Enterprise Architecture? – “Architecture is the art of matching requirements with constraints in complex situations”.

In conventional requirements-modelling, we only model the requirements. Fair enough: that’s the top-down perspective, of ‘what shall be’ etc.

In any of the decent requirements-toolsets, such as Telelogic DOORS, we also identify tests for each requirement, and model the often many-to-many links between each. As we do design and implementation, we’re likely to add those into the requirements-model too.

But as far as I can tell, the tools don’t model constraints. Which they need to, because (as per that quote above), any implementation of an architecture needs to balance the top-down requirements with the bottom-up constraints (“this is the Real World talking…”) – and specifically the constraints which apply at that time. If we don’t map the constraints as constraints into the requirements-model, we have no way to tell which ‘requirements’ for implementation are actually real requirements, and which are actually constraints masquerading as requirements – for example, a colour-scheme, or an interface-spec, or a particular technology, and so on.

This is particularly important when we remember that we’re dealing with multiple intersecting life-cycles for each implementation: as with requirements, constraints are dynamic over time. Each implementation is a complex trade-off between requirements and constraints: if we embed the constraints into the model as ‘requirements’, we’ll always be finding ourselves limited by apparent constraints that may well be out of date and no longer apply.

My preferred requirements-methodology, Volere, does include constraints as a separate category (section 4 in the template), with some sub-categories, but nothing like the level of detail that it does for requirements – in fact it treats constraints as requirements, which they’re not. Although obviously requirements and constraints are related, we need quite different types of attributes and metadata for each: for example, at the design/logical-level, requirements should be ‘timeless’ and implementation-agnostic, whereas constraints are context- and implementation-specific.

And if “architecture is the art of matching requirements with constraints in complex situations”, we need our architecture to model both, dynamically over time and in different contexts. Which, given that our toolsets are still barely coming to grips with the idea that there could be anything more than a single fixed, static ‘as-is’ and ‘to-be’ in any enterprise-architecture model, is going to be tricky – to say the least – but it needs to be done. Somehow.

I’m trying to address these issues in the architecture-framework and methodology I’m developing for the current ‘mini-book’ on ‘real enterprise-architecture’; but if you happen to have thoughts on this that you’re willing to share, I’d love to hear from you!