NFR: come definire correttamente uno scenario

Abbiamo più volte affrontato la questione dei Requisiti Non Funzionali o di Qualità, e affermato la loro fondamentale rilevanza nella definizione dell’Intentional Architecture. Inoltre, abbiamo visto come in Agile sia possibile pensare a delle (Technical) User Story che contemplino gli NFR e come esista una loro congiunzione diretta all’ALM con un occhi particolare a DAD.

A questo punto, cerchiamo di rispondere più in dettaglio ad una semplice domanda che, però, cela una risposta complessa:

            “Come catturo opportunamente gli NFR, in modo sintetico e non ambiguo?”

Una soluzione interessante è quella proposta da Bass, Clements e Kazman in “Software Architecture in Practice”, che propone di definire uno specifico attributo di qualità (o meglio di dettagliare quali aspetti di esso afferiscono al contesto/progetto specifico) attraverso un Quality Attribute Scenario.

specify nfr

Quality Attribute Scenario

Nel dettaglio, uno tale scenario è esplicitato attraverso 6 elementi:

  • Stimolo (Stimuls), ovvero l’evento che sollecita il sistema;
  • Source of Stimuls (Sorgente dello Stimolo), la sorgente da cui proviene lo stimolo;
  • Artefatto (Artifact), la parte del sistema sottoposta allo stimolo. Chiaramente può essere l’intero sistema;
  • Environment (Contesto), il contesto in cui si verifica lo stimolo;
  • Response (Risposta), come il sistema risponde allo stimolo;
  • Response Misure (Misura della Risposta), permette di valutare se la risposta del sistema è soddisfacente.

Vediamo un esempio concreto di scenario generale afferente alla requisito di Availability (Disponibilità)

 

availability scenario

Quality Attribute Scenario for Availability

In cui troviamo:

Elemento

Possibili Specifiche (nel dettaglio ne verrà selezionato solo uno)

Source of Stimulus

Interno/Esterno

Persone/Hardware/Software

Infrastrutture e Ambienti fisici

Stimulus

Fault, Tempi di risposta incorretti, Risposte Incorrette

Artifact

Processori, Canali di Comunicazione, Sistemi di Storage, Processi

Environment

Esercizio, Startup, Riavvio, In Manutenzione, ecc…

Response

Evitare che i fault si tramutino in failure

Tracciare il fault: log, notifiche

Inibire la sorgente dello stimolo

Response Measure

Tempo o relativo intervallo di disponibilità

Percentuale di Availability

Tempo per individuare un fault e tempo di recovery

Personalmente ritengo che questo approccio permetta di definire dettagliatamente gli NFR, scrollandogli di dosso quella aleatorietà che spesso gli si associa con affermazioni del tipo “Il Sistema deve essere sicuro!”, prendendo, eventualmente, come riferimento gli attributi esplicitati nello standard ISO 9126 (ISO/IEC 25000 dal 2005).

Una volta definiti gli scenari è possibile passare alla stesura di una prima ipotesi di Intentional Architecture, utilizzando Tattiche e Pattern Architetturali per abbracciare l’insieme degli NFR. Inoltre è possibile definire le (Technical) User Story per il ciclo di sviluppo, o un'altra formalizzazione delle specifiche dipendente dalla metodologia scelta.

La cosa su cui ritengo untile spendere un ulteriore passaggio è che tale approccio si applica sia agli attributi che afferiscono ai componenti e alle loro iterazioni (component-and-connector) sia agli attributi relativi alla definizione statica dell’architettura (modules). Quest’ultimo aspetto non è immediato come quello che più afferisce al funzionamento del sistema, ma è altrettanto fondamentale. Un esempio per tutti è la Modifiability, alias l’attitudine del sistema ad essere modifica e/o adattato.

modifiability scenario

Modifiability Scenario relativo al cambio della UI

Come si vede dalla figura precedente, l’Environment è “Design Time” e quindi implica uno scenario che afferisce alla specifica fase di definizione della struttura del sistema.

agileiot logo  ac2 logodac dac dacdac dac psmii psmii safe cal1 less certazure fundamentals
mvp reconnect

Free Joomla templates by Ltheme