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.[1] 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).[2] 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.[1][3] Ecco perché il concetto di ASR nel campo dei requisiti relativi all'architettura risulta di notevole importanza.[3]
Caratteristiche
I Requisiti Architetturalmente Significativi possono essere caratterizzati dai seguenti aspetti.[1]
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[4] e Peter Eeles (IBM) forniscono ulteriori criteri di identificazione.[5]
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à[6], gli ASRs dovrebbero essere specificati tramite una definizione SMART. Gli scenari degli attributi di qualità[2] 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.[7]
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.[8]
Note
Voci correlate
- Pattern architetturali
- Progettazione guidata dagli attributi
- Qualità del software
- Requisiti non funzionali
- Open Unified Process
- Ingegneria dei requisiti
- Architettura software
- Architettura della soluzione
- Architettura dei sistemi
