Luoghi comuni sui requisiti nello sviluppo software

1 – I requisiti arrivano dagli utenti.

–> In realtà, è raro che il vero utente (il futuro utilizzatore del sistema) possa esprimere in prima persona i propri requisiti, prima che il prodotto software gli sia stato reso disponibile. E’ più probabile che i requisiti vengano espressi da altri. Sono diversi i ruoli che possono esprimere i requisiti di un prodotto software.

Il principale soggetto che esprime requisiti è il committente (in termini generali, colui che paga per il progetto di sviluppo). Il committente è anche colui che decide quali altri soggetti, scelti tra i diversi stakeholder (le parti interessate a vario titolo agli esiti di un progetto) debbano essere coinvolti nel progetto per esprimere i propri requisiti.

L’insieme degli stakeholder di un progetto può essere molto ampio. Comprende, oltre al committente, tutti i futuri diretti utilizzatori del sistema, gli utilizzatori di altri sistemi esterni collegati in input o in output al sistema da realizzare, altri soggetti che a vario titolo possono ricevere vantaggi o svantaggi dalla realizzazione del sistema, o dalle diverse possibili scelte progettuali.

La selezione degli stakeholder da coinvolgere concretamente nel progetto può essere decisiva per il successo del progetto stesso. Non coinvolgere uno stakeholder può risultare critico, ma ogni coinvolgimento nel progetto ha un costo, che va valutato in termini di rischi / opportunità.

Naturalmente, i diversi stakeholder di un progetto hanno i propri punti di vista sui requisiti e sulle scelte progettuali. Punti di vista che sovente divergono e possono entrare in conflitto. In questo caso, spetta al committente il compito di decidere tra le diverse opzioni praticabili, e di indicare agli sviluppatori i requisiti da soddisfare.

2 – Il compito degli sviluppatori è ricevere i requisiti dagli utenti e creare un prodotto che li soddisfi.

–> Messa così, sembra che il ruolo degli sviluppatori nella gestione dei requisiti sia passivo. In realtà, rientra nei compiti degli sviluppatori software anche la scoperta dei requisiti, il tirarli fuori, farli emergere, elicitarli.

Si sente dire spesso dagli sviluppatori che “l’utente non ha le idee chiare”. In realtà la scoperta, l’emersione dei requisiti avvengono attraverso un dialogo tra gli sviluppatori e gli stakeholder (committente in primis, naturalmente), in un continuo e progressivo processo in cui si presentano delle alternative, vengono valutate, si prendono delle decisioni, si verificano gli effetti delle decisioni prese. I requisiti non sono già completamente definiti nella testa dell’utente, come alcuni sviluppatori pretenderebbero.

I prodotti software sono ottenuti tramite processi di astrazione, e sono il risultato di una progressiva acquisizione di conoscenza. All’inizio di un progetto esistono solo alcuni requisiti preliminari, che verranno via via arricchiti man mano che prende forma la soluzione completa. Pretendere il contrario sarebbe come pretendere che un giocatore di scacchi abbia già in testa, prima della partita, tutte le mosse che lo porteranno alla vittoria; oppure che un pittore abbia in testa, prima di iniziare a dipingere, l’immagine esatta del quadro finito.

3 – I requisiti non si discutono.

–> Invece bisogna analizzarli, discuterli, negoziarli. Non è detto che alla partenza di un progetto gli stakeholder abbiano le idee chiare, né che sappiano esprimerle in un modo comprensibile da parte degli sviluppatori software. Senza contare il frequente, già ricordato, conflitto tra punti di vista diversi.

Più in generale, possono esserci differenze sostanziali tra ciò che viene richiesto inizialmente dagli stakeholder, ciò che servirebbe davvero per risolvere le loro esigenze e ciò che tecnicamente potrebbe essere realizzato e costituisce un’opportunità almeno potenziale. Il chiarimento va effettuato in modo progressivo attraverso il dialogo tra committenti, altri stakeholder e sviluppatori, ed il confronto sulle possibili soluzioni.

4 – I requisiti sono tutti ugualmente importanti.

–> Secondo statistiche pubblicate dalla società di ricerche Standish Group, il 45% delle
funzionalità di un sistema non viene mai usato, il 19% viene usato solo raramente.

5 – Bisogna definire tutti i requisiti in dettaglio all’inizio del progetto.

–> Idealmente sarebbe meglio, ma purtroppo ci si riesce solo per progetti di dimensioni molto limitate.

D’altronde, in un progetto di lunga durata, scendere subito al massimo livello di dettaglio su tutto può essere perfino controproducente, perché aumenta la probabilità futura di dover gestire dei cambiamenti. Più tempo passa tra la formulazione di un requisito e la sua implementazione, maggiore la probabilità di cambiamenti.
Se ad esempio un sistema dovrà comprendere dieci funzionalità, specificarle tutte in una prima fase del progetto in estremo dettaglio, per poi iniziare solo dopo a realizzarle, può essere meno efficace e meno efficiente che non specificarle e realizzarle in successione, una dopo l’altra, cioè ritardando quanto più possibile la definizione dettagliata dei requisiti delle funzionalità che non verranno realizzate subito.

6 – I requisiti concordati non si toccano, vanno congelati.

–> Il cambiamento in corso d’opera dei requisiti è una costante (possono fare eccezione
i progetti di dimensioni molto limitate).

Il congelamento dei requisiti permette agli sviluppatori di lavorare in modo più tranquillo,
ma va contro alle esigenze degli stakeholder. Se si segue l’approccio “prima il dettaglio di tutti i requisiti, poi si inizia a realizzare” l’ambito e la durata del congelamento sono rilevanti, e sorgono problemi. Se invece i cicli di lavorazione sono incrementali e di durata limitata, e se il dettaglio dei requisiti viene raggiunto “just in time”, cioè immediatamente prima della relativa implementazione, il congelamento dei requisiti cessa di essere un problema.

7 – Il modo di gestire i requisiti deve essere lo stesso in tutti i tipi di progetto software.

–> I sistemi non sono tutti uguali. Esistono sistemi “life critical”, che in caso di malfunzionamento possono portare alla perdita di vite umane; sistemi il cui malfunzionamento può provocare la perdita di denaro; e sistemi molto meno critici.

Per i sistemi “life critical” è indispensabile che la storia e l’evoluzione di ogni singolo requisito venga tracciata con una documentazione accurata. Idealmente, la stessa esigenza esiste anche per i sistemi meno critici, ma spesso il lavoro necessario per documentare l’evoluzione dei requisiti in modo molto accurato entra in conflitto con le risorse economiche del progetto ed i tempi di consegna del prodotto richiesti dal committente.

8 – Se un requisito non è stato espresso in modo esplicito, non esiste. Quindi il fatto che non sia stato soddisfatto non può costituire un motivo per non accettare il sistema.

–> Dal punto di vista giuridico è (almeno in alcuni paesi) opinabile, ma dal punto di vista della relazione tra cliente e fornitore si tratta di un’affermazione poco sostenibile e poco ragionevole. Compito dello sviluppatore software è quello di soddisfare le esigenze degli stakeholder, collaborando con loro e aiutandoli a chiarire e a esplicitare i requisiti attraverso la progressiva predisposizione e verifica di soluzioni concrete.

Una variante di questo luogo comune afferma che “se non esiste una specifica dei requisiti
non si può testare il sistema”. In realtà, i sistemi di gestione della qualità (ISO9000 e derivati) distinguono tra attività di “validazione” e di “verifica”.
La validazione controlla che il prodotto soddisfi l’utilizzo per cui è stato previsto, cioè che si sia prodotto un sistema appropriato. La verifica controlla che il prodotto corrisponda ai requisiti specificati, cioè che il sistema sia stato prodotto in modo corretto. L’assenza di una specifica dei requisiti, pertanto, impedisce la verifica del prodotto, ma non la sua validazione.

9 – La firma del committente sulla specifica dei requisiti garantisce che se il prodotto finale rispetterà la specifica sarà accettabile da parte del committente.

–> Dal punto di vista giuridico è sicuramente vero, ma il committente è normalmente
restio ad apporre la firma, e con qualche ragione. La firma sulla specifica dei requisiti viene infatti spesso utilizzata dagli sviluppatori come una barriera protettiva nei confronti del committente, come se il committente fosse un soggetto lunatico, che cambia idea senza motivo.

In realtà, quando si usa l’approccio “prima il dettaglio di tutti i requisiti, poi si inizia a realizzare” la firma sulla specifica dei requisiti costringe il committente a bloccare ogni sua decisione ben prima di quanto sarebbe necessario alle reali esigenze degli sviluppatori. La “firma al buio”, inoltre, non tiene in considerazione il fatto che i requisiti evolvono progressivamente anche grazie alle verifiche concrete effettuate dagli utilizzatori sulle versioni iniziali o prototipali del prodotto.

Dare un’importanza eccessiva alla specifica dei requisiti, ed alla relativa firma, cioà considerarli come l’unico canale di comunicazione effettivo, è di solito sintomo di un atteggiamento antagonistico e non collaborativo nella relazione tra cliente e fornitore.