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).
Posts
