In past posts I’ve been discussing how to get the architecture of your technology right and I’ve referred to defining the requirements as the critical driver. I’ve noticed that some technologists go straight to product selection when defining an architecture – e.g. should we use React or Angular?
Taking the time to define requirements is also sometimes dismissed because an agile approach will gather the requirements through evolutionary development. Both early product selection and agile approaches are fine, but they are optimized when some time is taken to define the high level requirements up-front. How will you know what products/frameworks to use?
Defining the requirements for architecture need not be a bureaucratic or time consuming process, but they are hard because they require the owner of the technology to make hard tradeoffs. The more stringent the requirement the more cost and complexity that will be incurred.
In order to define requirements, it’s good to use some standard areas, we used to call them the “ilities” because many of the areas are described as a capability. The basic ones to define include: usability and personalization, maintainability, testability, scalability, availability and reliability, performance, and security. In some cases additional requirements to consider include how the software is multi-tenant, configured, customized and extended, multi-language, currency, and culture support, portability to different devices and browsers, ease of implementation and maintenance and ability to reuse for other future as yet undefined applications.