Durante l’Agile Day 2012 (Milano) ho avuto il piacere di chiacchierare con un caro amico ed un collega, entrambi esperti IT, del tema dei Requisiti non Funzionali (NFR, o anche di Qualità).
La questione si è incentrata su una domanda tanto banale quanto cruciale:
“come descrivo i requisiti non funzionali di un sistema, ottenendone l’accettazione del cliente”?
Se vi sembra semplice rispondere a tale domanda, vi invito a rifletterci bene, perché dietro si cela una complessità enorme che spesso non riesce a trovare una risposta semplice ed unica.
Nella discussione, l’amico suggeriva di adottare lo standard ISO 9126 (ISO/IEC 25000 dal 2005) che descrive un modello di qualità del software. Il suggerimento è assolutamente centrato, visto che, opportunamente utilizzato, la specifica in questione permette di comunicare al Cliente (attenzione: notare che si parla di Cliente e non Stakeholder!) sufficienti informazioni riguardo ad aspetti come Manutenibilità e Sicurezza.
Ma lo stesso è adattabile al mondo Agile? E se si, come?
Partiamo da un dato di fatto: lo standard ISO 9126 è nato tenendo conto dei modelli di sviluppo classici, in cui la fase di analisi e definizione dei requisiti è effettuata, in modo imperativo, a monte del ciclo di sviluppo del software.
Si tratta, chiaramente, di un approccio in netto contrasto con quello Agile che, come ben sappiamo, prevede un continuo “aggiustamento” dei requisiti durate le varie iterazione (JIT, Just in Time).
A questo punto qualcuno potrebbe suggerire: “trascriviamo gli NFR in User Story che ne catturano l’essenza”.
Bene, si può sicuramente fare ma bisogna affrontare due sfide interessanti:
- La tipica User Story (As a user, i want) è pensata per rientrare in una singola iterazione in modo da essere completata e produrre incrementalmente un sistema pronto per il deploy. Un requisito non funzionale è però spesso un aspetto trasversale che, non è detto possa essere completato in una singola iterazione o splittato efficacemente per essere coperto da più iterazioni. Tipicamente è vero proprio il contrario!
- Gli NFR sono, al pari dei Temi di Business (aka Requisiti Funzionali, FR), fondamentali per la definizione dell’Intentional Architecture. Ciò impone di confrontarci con l’Agile Architect Uncertainty Principle [Principio di Indeterminazione delle Architetture Agile]: “Più si affina un aspetto, tanto più l’altro perde di consistenza” [F.P], che contrappone tra loro l’Aspetto Temporale e l’Aspetto Strutturale dell’Intentional Architecture (si veda post).
E’ quindi necessario identificare un approccio per gestire correttamente l’inserimento dei requisiti non funzionali all’interno del Software Development Lifecycle (SDLC), così come suggerito da Scott Ambler che identifica quattro strategie di injection degli NFR all’interno del ciclo di sviluppo del software:
- Initial requirements and architecture envisioning during Iteration 0 to identify NFRs and constraints;
- Just in time (JIT) model storming through the construction lifecycle to explore the details;
- Independent investigative testing throughout the lifecycle to ensure that the system addresses the NFRs and constraints appropriately;
- Developer education so that they understand the fundamentals of the full range of architectural concerns described in the requirements.
In pratica Ambler suggerisce che gli NFR vengano rivisti in più momenti dell’SDLC e affidati a diverse figure del Team:
E’ interessante evidenziare che, oltre all’autoapprendimento, viene contemplato esplicitamente l’attività di Education, ovvero il coinvolgimento diretto di esperti che sappiano trasferire al Team know-how relativo allo specifico requisito non funzionale.
Inoltre Ambler prevede (così come descritto in DaD) una serie di Test Indipendenti (affidati a persone esterne del Team di sviluppo), atti a stressare il sistema al fine di verificarne sia gli NFR che gli FR.
Fin qui abbiamo preso in prestito una possibile strada da percorre per integrare nel nostro SDLC la gestione dei requisiti non funzionali, ma come applichiamo il tutto concretamente?
Facciamo un esempio relativo all’aspetto della Security.
A luglio di quest’anno, SAFECode ha pubblicato un white paper da titolo “Practical Security Stories and Security Tasks for Agile Development Environments” in cui, partendo dalle esperienze dei propri aderenti e della Community afferente, ha delineato
- 36 security focused stories e relativi task (tab.1) con cui comunicare efficacemente agli stakeholder e al Team gli NFR;
- 17 operational security tasks, ovvero attività non direttamente legate alle User Stories ma che spingono verso una operatività che tenga in conto dei fattori legati alla Security (tab.2);
- 12 advanced security tasks, ovvero le attività che richiesto l’assistenza da parte di un Security Expert (tab.3);
|
No. |
Security-focused story |
Backlog task(s) |
SAFECode Fundamental Practice(s) |
CWE-ID |
|
1 |
As a(n) architect/ developer, I want to ensure AND as QA, I want to verify allocation of resources within limits or throttling |
[A] Clearly identify resources. A few examples:
[A/D] Define limits on resource allocation. [T] Conduct performance/stress testing to ensure that the numbers chosen are realistic ( i.e. backed by data ). [A/D/T] Define and test system behavior for correctness when limits are exceeded. A few examples:
|
Common Vulnerabilities
Robustness Testing |
(CWE-ID: Common Weakness Enumerations http://cwe.mitre.org/) |
Tabella 1
|
No. |
Operational Security Task |
Requirement/Recommendation |
|
1 |
Configure bug tracking to track security vulnerabilities |
Requirement for software development team |
Tabella 2
|
No. |
Security Experts to Help |
Frequency of Help |
|
1 |
Software security training (secure coding and secure testing) |
Always |
Tabella 3
In conclusione gli NFR vanno associati in modo stringente all’Intentional Architecture in modo da definire i “binari” entro cui sviluppare le caratteristiche specifiche, esattamente come accade per i Temi di Business (RF). La definizione di User Storie specifiche (tab.1) permette di definire con gli stakeholder (e non solo al Cliente!) un “accordo” su cosa si intende per singolo requisito, andando al di la della banalizzazione dello stesso. Fondamentale è, inoltre, l’utilizzo di best-practice che indirizzino il modo di operare del Team per soddisfare gli NFR (tab.2), affidandosi a opportuni Technical Specialist (tab.3) di supporto, sia nello sviluppo della User Story sia nelle pratiche operative.
