Approfondimento

Checklist

Nel documento "Software Development Checklist" un lunghissimo elenco di domande come aiuto nella raccolta dei requisiti.

Ne riportiamo alcune (per la lista completa si faccia riferimento al documento).

Contenuto:
- è specificato il livello di sicurezza ?
- è specificata la memoria massima richiesta (RAM e HD) ?
- sono indicati i tempi di riposta attesi per ogni operazione ?
- sono specificati tutti gli input del sistema indicandone la sorgente, l’accuratezza, l’intervallo di valori, la frequenza, il formato ?

Completezza:
- le aree per quali i requisiti sono incompleti sono specificate ?
- ci sono parti non implementabili, inserite solo per compiacere il cliente o la direzione ?

Qualità:
- i requisiti sono scritti in linguaggio comprensibile per l’utente ? Anche il cliente è convinto di questo ?
- sono scritti in modo abbastanza chiaro da essere passati ad un altro gruppo e compresi da chi li dovrà elaborare ?
- ogni requisito si presta ad essere verificato ?


 

I dieci errori da evitare


Un articolo di Karl Wiegers ("Ten Requirements Traps to Avoid"), consultabile al sito StickyMinds fra i documenti della sezione "Requirements", elenca i 10 errori da evitare nel processo di specifica dei requisiti.

Confusione sui requisiti
Esistono diversi tipi di requisiti, tutti necessari, e i partecipanti alle riunioni di stesura dei requisiti devono essere a conoscenza di concetti e terminologie:
- requisiti di business o "business requirements", riferiti all’organizzazione di alto livello del cliente, da rendere attraverso un documento introduttivo di applicabilità del software,
- requisiti utente o "user requirements", riferiti ai compiti che l’utente deve eseguire utilizzando il prodotto richiesto, esprimibili attraverso "use cases",
- requisiti software o "software requirements", riferiti ad obiettivi sia funzionali che non funzionali, esprimibili attraverso descrizioni in forma testuale che utilizzino precise forme verbali e grammaticali.

Insufficiente coinvolgimento del Cliente
Molti progetti vorrebbero quasi basarsi sulla "telepatia" come meccanismo di comunicazione fra cliente e fornitore.
I futuri utilizzatori del prodotto ritengono di non dover perdere tempo nel parlare con gli sviluppatori, o, al massimo, delegano un referente unico a rappresentarli.
Devono essere invece ben chiarite le tipologie di utenti del sistema e per ogni tipologia deve essere coinvolto almeno un utente nella attività di analisi e di valutazione dei prototipi sviluppati.

Requisiti vaghi ed ambigui
L'ambiguità può derivare da frasi interpretabili in modo diverso o da indicazioni mancanti o incomplete. Per evitare tutto ciò devono essere vietati termini generici quali "minimizzare", "massimizzare", "ottimizzare", "rapido", "user-friendly", "facile", "semplice", "spesso", "normale", "ampio", "intuitivo", "robusto", "migliore", "efficiente", "flessibile", "pericoloso".
Non vanno utilizzate le forme "e/o" e "etc". Eventuali indicazioni del tipo "da verificare" possono essere temporaneamente utilizzate, ma devono essere risolte prima di passare alla fase di progetto e sviluppo.
Eventuali prototipi, anche parziali, possono rendere più tangibili i concetti analizzati, e consentire la verifica dell'avvenuta comprensione del problema.

Requisiti senza indicazione di priorità
Se tutti (o quasi) i requisiti sono considerati dal cliente ugualmente importanti il project manager ha uno strumento in meno per gestire eventuali imprevisti nello sviluppo del progetto.
Tutti i casi d’uso e tutti i requisiti funzionali devono avere una priorità.

Sviluppo di funzionalità che nessuno utilizzerà
E' importante assicurarsi che tutto quello che viene sviluppato deriva da casi d’uso o requisiti realmente richiesti.

Paralisi delle attività di analisi
In certe occasioni l’attività di analisi risulta interminabile e produce decine o centinaia di modifiche e riscritture dello stesso documento.
Va considerato in questi casi che non è sempre necessario disporre di una situazione completamente definita per avviare le successive fasi di progettazione e sviluppo.
Può essere talvolta preferibile individuare e definire i requisiti di base del progetto e scegliere un modello di sviluppo che consenta l’iterazione attraverso cicli successivi di analisi, progettazione ed implementazione. In tal caso è ovviamente fondamentale procedere solamente per la aree ben specificate e solamente con la sicurezza che quanto deve essere ancora definito non avrà impatti successivi sulle scelte di base già effettuate.

Aumento della portata del lavoro
In molti progetti capita che requisiti nuovi continuino ad aggiungersi in ogni fase dello sviluppo. Si chiedono nuove funzioni e nuove caratteristiche senza modificare tempi, costi e risorse dedicate al progetto.
Questo può dipendere dalla scarsa qualità del processo iniziale di specifica dei requisiti o dal fatto che la firma del documento concordato con il cliente viene considerata una pura formalità. Un minimo di flessibilità deve essere prevista per gestire eventuali (poche) richieste tardive che comunque rientrino negli obiettivi del progetto iniziale, ma il cliente deve essere consapevole di cosa ha chiesto e firmato e del fatto che ogni modifica comporta costi aggiuntivi.
Tutte le nuove richieste vanno gestite e tracciate secondo gli standard di documentazione stabiliti.

Inadeguatezza dei processi di gestione delle modifiche
Se la gestione delle modifiche non segue procedure formali, può capitare che vengano sviluppate funzionalità eliminate dal progetto, o che non vengano gestite modifiche già approvate, o che le modifiche approvate non siano comunicate a tutti gli interessati.
Deve essere costituita una struttura responsabile dell’approvazione delle modifiche richieste (Software Configuration Board o SCB), che assicuri la gestione effettiva ed efficiente del processo.

Analisi insufficiente dell’impatto delle modifiche
Modifiche approvate con leggerezza possono rivelarsi più costose o più complesse di quanto previsto, o possono entrare in conflitto con altri requisiti.
Prima di accettare una richiesta di modifica devono essere analizzate tutte le relative implicazioni, tecniche e organizzative.
Una valutazione dei costi dovrebbe essere nota al SCB Manager prima che questo si impegni con il cliente.

Gestione delle versioni non adeguata
Ogni nuova variante dei requisiti concordati deve produrre una nuova versione del relativo documento (non è sufficiente riferirsi alla data del documento).
Periodicamente le modifiche autorizzate dal SCB Manager vanno riportate nel documento di specifica dei requisiti e questo va ridistribuito a tutti gli interessati.
Una buona soluzione tecnica è quella di disporre di uno strumento software per il controllo automatico delle versioni.


 

Template

Segnaliamo un esempio di template per la stesura di documenti di specifica dei requisiti.

Si tratta in effetti di tre documenti collegati che rispondono alla definizione delle tre tipologie di requisiti:
- business requirements, rappresentabili con il template "Vision and Scope Document Template"
- user requirements, rappresentabili con il template "Use Case Template",
- software requirements, rappresentabili con il template "Software Requirements Specification Template".

Nel documento "VolereRequirements SpecificationTemplate Edition 6.1" un altro template completo ed approfondito.

Un terzo template si può trovare al sito di
Ancora un template per la raccolta dei requisiti.
Prevede sezioni dedicate a:
- Business Requirements
- System Requirements
- regole
- checklist di controllo.


 

Checklist

Segnaliamo ancora Checklist scaricabili per l’analisi di impatto delle modifiche ai requisiti (documento "Requirements Change Impact Analysis Checklist and Worksheet.doc") ed una checklist per la validazione della specifica dei requisiti (documento "requirements_review_checklist.doc").

 

I requisiti: l’anello debole dello sviluppo software


Un noto studio effettuato dallo Standish Group, nel 1994, su un campione di 8000 progetti, riporta risultati sconfortanti: 16% di successi, 53% di fallimenti parziali (gravi problemi sulle funzionalità, sui costi e/o sui tempi), 31% di fallimenti completi.
E la principale causa di insuccesso è la incompletezza dei requisiti (13,1% dei casi). Ai primi posti anche la variabilità dei requisiti (8,7% dei casi).
L’articolo su Zerouno del luglio 1999.


 

Scrivere i requisiti giusti la prima volta


La difficoltà di definire requisiti corretti, completi e testabili rappresenta un aspetto fondamentale dell’ingegneria del software.
Il successo di un progetto, sia tecnico che finanziario, è direttamente condizionato dalla qualità dei requisiti, e altrettanto critico è il test finale, basato sulla completezza del prodotto rispetto i requisiti.
Nuovi strumenti di gestione dei requisiti rendono disponibili nuove metriche da utilizzare a supporto di entrambi i processi, permettendo di identificare con anticipo eventuali problemi.
I problemi più frequenti possono in particolare riguardare l’ambiguità o incompletezza dei requisiti, il mancato collegamento fra requisiti e casi di test, il numero eccessivo o insufficiente dei casi di test.
Un articolo affronta i temi sopra ricordati, con particolare riferimento a tre aspetti critici dei requisiti: definizione, verifica, gestione.


 

In cerca di requisiti eccellenti


Riferiamo un altro articolo che vuole aiutare nel miglioramento del processo di specifica dei requisiti.

La ricetta proposta per ottenere buoni risultati prevede quattro ingredienti:
- un alto grado di partecipazione del cliente nello sviluppo,
- la preparazione di un documento di specifiche strutturato secondo lo standard IEEE per la specifica dei requisiti software,
- la costruzione di una “mappa di dialogo”, con cui modellare l’interfaccia utente ad un alto livello di astrazione,
- l’utilizzo estensivo di prototipi per chiarire meglio le necessità dell’utente ed esplorare soluzioni alternative con cui ottenere la sua soddisfazione.

Secondo l’esperienza dell’autore le tecniche suggerite riducono il "gap" normalmente presente fra quanto il cliente si aspetta di ricevere e quanto il fornitore intende sviluppare.


 

Scrivere requisiti di qualità


Ancora un articolo su come scrivere la specifica dei requisiti.
L’autore Karl Wiegers individua alcune caratteristiche che devono essere rispettate per ottenere requisiti "di qualità".

Per ogni singolo requisito deve valere le seguenti proprietà:
- corretto: ogni requisito deve descrivere correttamente la funzionalità da fornire,
- fattibile: ogni requisito deve essere risolvibile nell’ambito delle capacità e limitazioni note,
- necessario: ogni requisito deve riferire reali necessità del cliente o vincoli esterni cui adeguarsi, e deve essere indicato da persone qualificate a farlo,
- dotato di priorità: ogni requisito deve contenere un indice di priorità (alta, media, bassa) indicato dal cliente,
- non ambiguo: due lettori distinti devono capire le stesse cose (vanno evitati termini generici, ridondanti, complicati, eccessivamente tecnici),
- verificabile: deve essere possibile dimostrare che il prodotto sviluppato risolve il singolo requisito specificato.

Rispetto al sistema complessivo dei requisiti individuati, si richiede invece che questo risulti:
- completo: non devono mancare requisiti o informazioni necessarie; eventuali punti non definiti devono essere risolti per tempo
- consistente: i requisiti software non possono essere in conflitto fra di loro o con requisiti di sistema di livello più alto
- modificabile: se necessario deve essere possibile modificare il documento di specifica dei requisiti, mantenendo nel sistema di configurazione ogni diversa versione prodotta
- tracciabile: ogni requisito software deve essere ricollegabile alla sua fonte (requisito di sistema, caso d’uso, richiesta del cliente). Ogni requisito deve essere poi tracciato nel progetto, nel codice software, nei casi di test con cui dovrà essere verificato.