Architecturally-significant requirement
An Architecturally-significant requirement (ASR) is a requirement that has a measurable effect on a software system’s architecture.
Why?
As a software engineer with architecture responsibilities, I want to prioritize technical issues quickly so that architecturally significant issues are addressed at their most responsible moment and we do not have to revise decisions and designs unnecessarily later. When doing so, I want to be as objective as possible to avoid that loud voices receive more attention than they deserve so that the truly urgent and important things are tackled first.
https://www.ozimmer.ch/practices/2020/09/24/ASRTestECSADecisions.html
Seven Criteria for Architectural Significance
The following Criteria is copied from Olaf Zimmermann (ZIO)'s article - https://www.ozimmer.ch/practices/2020/09/24/ASRTestECSADecisions.html
The requirement is directly associated with high business value (benefit vs. cost) or business risk.
The requirement is a concern of a particularly important stakeholder such as the project sponsor or an external compliance auditor.
The requirement includes runtime Quality-of-Service (QoS) characteristics (such as performance needs) that deviate from those already satisfied by the evolving architecture substantially.
The requirement causes new or deals with one or more existing external dependencies that might have unpredictable, unreliable and/or uncontrollable behavior.
The requirement has a cross-cutting nature and therefore affects multiple parts of the system and their interactions; it may even have system-wide impact, short term and/or in the long run (examples: security, monitoring).
The requirement has a First-of-a-Kind (FOAK) character: For instance, this team has never built a component or subsystem that satisfies this particular requirement before.
The requirement has been troublesome and caused critical situations, budget overruns or client dissatisfaction on a previous project in a similar context.
Last updated
