# Requisiti Architetturalmente Significativi

I Requisiti Architetturalmente Significativi (ASR dall'inglese Architecturally Significant Requirements) sono quei requisiti che hanno un impatto significativo sull'architettura di un sistema software. Sono una sottocategoria dei più generali requisiti software.

## Relazione con i Requisiti Non-Funzionali

Per molto tempo il concetto di Requisito Architetturalmente Significativo non è stato riconosciuto come importante nel mondo dell'ingegneria software. Parlando di architettura infatti, venivano spesso usati come elementi di sostegno i Requisiti Non-Funzionali (NFR). Ma recenti studi empirici hanno dimostrato che non tutti gli NFR influenzano l'architettura di un sistema software. E d'altro canto possono invece esserci Requisiti Funzionali che incidono sulle scelte architetturali. Ecco perché il concetto di ASR nel campo dei requisiti relativi all'architettura risulta di notevole importanza.

## Caratteristiche

I Requisiti Architetturalmente Significativi possono essere caratterizzati dai seguenti aspetti.

### Caratteristiche descrittive

Gli ASR sono spesso difficili da definire e da articolare. Tendono ad essere espressi vagamente, inizialmente trascurati, nascosti dagli altri requisiti. Sono soggettivi, variabili e situazionali. Anche altri requisiti possono rivelare queste caratteristiche descrittive ma gli ASR lo fanno in modo unico.

### Indicatori

Un requisito che ha un effetto ampio, coinvolge scelte trade-off, è rigoroso (vincolante, limitante, non negoziabile), presuppone possibilità di interruzione o è difficile da raggiungere probabilmente è un requisito architetturalmente significativo.
Più precisamente, gli indicatori di ASR riportati in letteratura includono:
* Il requisito è associato ad un alto valore di business e/o ad un rischio tecnico.
* Il requisito è una preoccupazione di particolare importanza per gli stakeholder.
* Il requisito è il primo a possedere una specifica caratteristica, ovvero nessuno dei componenti già esistenti nell'architettura ha la responsabilità di trattare quella caratteristica.
* Il requisito possiede dichiarazioni di tipo QoS o SLA che deviano da quelle già soddisfatte nell'architettura.
* Il requisito ha causato il superamento del budget o l'insoddisfazione del cliente in un progetto precedente, con un contesto simile.
L'OpenUP e Peter Eeles (IBM) forniscono ulteriori criteri di identificazione.

### Altre caratteristiche

Quando un requisito specifica un attributo di qualità del software, ne coinvolge alcune funzionalità basilari, impone dei vincoli al sistema e/o definisce l'ambiente nel quale il software verrà eseguito con buona probabilità è un ASR.

## Dichiarazione

Proprio come i requisiti non-funzionali e gli attributi di qualità, gli ASRs dovrebbero essere specificati tramite una definizione SMART. Gli scenari degli attributi di qualità sono un modo per raggiungere la S(specificità) e la M(misurabilità) dei criteri SMART. Il SEI raccomanda di effettuare dei workshop sugli attributi di qualità (QAW, Quality Attribute Workshops) per raggiungere questo obiettivo.

## Impatto

Gli ASR sono usati nella progettazione software per guidare e giustificare le decisioni architetturali; se non vengono soddisfatti pienamente contribuiscono alla crescita del debito tecnico. Consigli su come implementare gli attributi di qualità del sistema (compresi gli ASR) sono disponibili pubblicamente.