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.Eckhardt, Jonas; Vogelsang, Andreas; Fernández, Daniel (2016).
Caratteristiche I Requisiti Architetturalmente Significativi possono essere caratterizzati dai seguenti aspetti.Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013).
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àBass, Len; Clements, Paul (2003). 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.
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
Categoria:Architettura del software