An architecturally significant requirement (ASR) is any requirement that strongly influences the design choices and the structures of the architecture. To help find these ASRs, think of four categories.
- Constraints
- Quality attributes
- Influential FRs
- Other influences
Limit design options with constraints
Constraints are powerful, they make the life of an architect easier or hell. They can be categorized into technical and business, based on what they affect.
Capture constraints as simple statements
It's important to document constraints, as they are non-negotiable and non-changeable. Also be conservative about accepting them. As a system grows, some design decisions become like constraints, but are actually not and can change (it may be very difficult to do though).
Capture quality attribute scenarios
Quality attributes like scalability, availability, etc. are just words. To make one an attribute, attach a scenario to it. The scenario must be qualified, as the architecture direction is most influenced by quality attributes.
The format to test the quality attribute scenario is:
- Stimulus - the event that starts the quality attribute, like the system is down; availability
- Source - the person, system or part of the system that initiates the stimulus, like the server
- Artifact - the part of the system or the whole system that is affected in this whole scenario, like the orders APIs
- Response - the visible action that takes place in the artifact, like can't place order
- Response measure - the success criteria, which is measurable and practical, like the order is placed
- Environment context - the circumstances of the scenario, like Diwali sale peak load
The response measure is very important, because if it can't be chosen as measurable, then how would you test it and make sure your architecture satisfies that attribute in that scenario?
Influential functional requirements
There are several functional requirements, but some are very influential and carry the potential to make you restart the architecture from the ground up again, so it's important to identify those.
Try to first put the related FRs in categories, to minimize the list for our evaluation. Then run the FRs against the architecture. If you can think of structures to satisfy the FRs, it's good. If it swirls the whole architecture, it's influential. For example, an FR to allow a user to see previous calculations on any phone. A simple calculator would now need a database, then backups, deployments, cloud hosting, APIs and what not.
Other influences
These can come from knowledge, team skills, trendy tech stacks, etc. Have an eye for them, because if you have a hammer, everything will look like a nail. Also, picking whatever trends will make your architecture look like a mullet hairstyle, over used.
Conway's law
...organizations which design systems...are constrained to produce designs which are copies of the communication structures of these organizations
As Aram said, if there are two teams, backend and frontend, seeing how error codes are respected in the REST APIs can tell you how the communication between the teams is.