Every project has different types of requirements it must comply with: business requirements (which are driven my the immediate imperatives of a set of business users, and relate to some aspect of the business's operation and performance); and strategic requirements (which are driven by broader, longer term goals). We could call the strategic requirements "architectural requirements" if we like – though this implies they have something to do with design per se (i.e. architecture). We can also consider other constraints e.g. project (cost/time etc.); technologies (materials availability, skills, to be used/not used), best practice (patterns, guidelines), existing assets (existing, and those to be created by other initiatives/activities)- which we could chose to consider under either the heading of business or strategic requirements. One can once again consider a parallel in a mature domain where we can see we have all of these.
In IT oriented solutions we have equivalents e.g.
A challenge in IT is firstly to get the different types of constraints understood. Secondary challenges are to get:
- business requirements defined in business terms (in terms of business operations and outcomes) and,
- designers/architects to realise they don't operate in a vacuum and that they need to consider and reference the constraints in their designs (ideally explicitly base on a canonical reference).