Abbiamo avuto già modo di parlare ampiamente della questione dei Requisiti non-funzionali (NFRs, o di Qualità) di un sistema software, sia collegando la questione all'(Intentional) Architecture sia alle metodologie Core Agile.
Riprendiamo ora il discorso in ambito DAD.
Come è ormai chiaro, gli NFRs interessano direttamente l'intero sistema e gli stessi requisiti funzionali, anche se spesso sono tralasciati o considerati un "de facto" dagli stakeholder e dagli stessi Membri del Team.
In DAD vengono individuate tre strategie di base per catturare tali requisiti (che ricordiamo possono comprendere: requisiti di sicurezza, di performance, di availability, ecc...):
-
- Technical Stories. Una "Technical Story" è un'unità documentale che cattura le specifiche caratteristiche di un requisito non-funzionale, consentendo di aggredirlo idealmente in una iterazione. In sintesi una Technical Story sta ad un NFR come una User Story sta ad un FR (Functional Requirement). Esempio: "La pagina web deve essere caricata in 3 secondi", così come: "Il dato deve essere trasmesso con un livello di cifratura a 128bit";
-
- Acceptance Criteria. L'adozione dell'Agile implica che una User Story sia considerata completata quando supera i relativi criteri (test) di accettazione. E' possibile far sì che uno o più NFR appartengano ad una User Story e che quest'ultima contempli criteri di accettazioni che implicitamente validino gli annessi NFRs. Esempio: "La pagina web di amministrazione può essere visualizzata solo da un utente di tipo Amministratore" che afferisce ad una User Story del tipo: "Essendo un utente voglio una pagina web per amministrare il sistema";
-
- NFRs Explicit List. Questa strategia contempla la "cattura" (documentazione) degli NFRs in un artefatto separato dalla Work Item List (WIL). Si tratta di appoggiarsi a quello che in Unified Process viene definito "supplementary specification", ovvero un documento di riferimento per i test di accettazione dei requisiti funzionali nel loro insieme e non nella specificità.
Chiaramente le tre strategie possono essere mixate tra loro all'occorrenza e hanno uno scope diverso: utilizzando una Technical Story si ha una visione legata al task specifico, mentre utilizzando una Explicit List si calano gli NFRs all'interno dell'intero sistema.
NFRs Capturing Strategies in DAD
In sostanza, ad ogni strategia sono chiaramente associati una serie di vantaggi e svantaggi:
-
- Technical Stories. Con questa strategia gli NFRs vengono catturati in modo semplice ed esplicito, diventando parte della WIL. Il problema è che, spesso, gli NFRs sono cross-cutting aspects, ovvero interessano più User Story e difficilmente possono essere implementati all'interno di una singola iterazione. Questo porta con se il rischio che essendo l'item troppo problematico e costoso da affrontare, il Team decida di rimandarne l'implementazione alla ultime iterazione della fase di Construction;
- Acceptance Criteria. Questo approccio consente di focalizzare il problema in funzione di una User Story, verificandone implicitamente il corretto funzionamento e, quindi, il soddisfacimento dei criteri di accettazione. I dettagli degli NFRs sono tipicamente individuati just in time (JIT), anche se uno stesso NFR può interessare più User Story e, quindi, il Team deve tener conto e bilanciare diverse varie esigenze. Tale strategia enfatizza il ruolo dell'Intentional Architecture come catalizzatore degli NFRs, al fine di ridurre i rischi ed evitare che alcuni di essi vengano dimenticati o erroneamente interpretati;
- NFRs Explicit list. Questa strategia consente di individuare preventivamente gli NFRs e renderli disponibili per costrutti quali: l'Intentional Architecture, i Test di Accettazione, ecc. Il problema è che la lista può diventare particolarmente complessa e addirittura obsoleta, se non gestita correttamente e "dimenticata" da un Team non particolarmente attento.
Ambler e Lines suggeriscono di mantenere una NFRs Explicit List ed utilizzarla per identificare gli opportuni Criteri di Accettazione. Tale soluzione sembra dare il miglior risultato, anche se è richiesta una certa maturità per gestire il processo in modo opportuno.
E' fondamentale sottolineare come per documentare efficacemente gli NFRs sia necessario ricorrere alla tecnica di "continuous documentation", la quale consente di tenere costantemente aggiornati (JIT) i documenti di progetto previsti, ovvero quelli che generano Valore aggiunto.
