Progettazione del software: niente di nuovo sotto il sole

Ormai più di venti anni fa ho iniziato ad occuparmi di software, ed in particolare mi ha sempre interessato la sua progettazione.
Nonostante i cambiamenti radicali e la rapidissima evoluzione tecnologica, mi sembra che poco sia cambiato in questa attività, soprattutto nella sua prima fase: la definizione dei requisiti.
L'analisi dei requisiti è il momento cruciale in cui viene definito che cosa deve fare un sistema e come: tutte le attività che seguono (progettazione, realizzazione, test, avviamento, ...) non sono che una conseguenza; se i requisiti sono errati, ammesso e non concesso che il sistema li rispetti, farà comunque qualcosa che non va bene.
Questa riflessione sull'importanza e la criticità dell'analisi iniziale e sulla scarsa evoluzione è stimolata dalla lettura di un articolo di Esther Schindler pubblicato oggi su CIO: "Getting Clueful: Five Things CIOs Should Know About Software Requirements" (http://www.cio.com/advice_opinion/development/five_things_it_managers_should_know_about_software_requirements.html?CID=29903).

Le 5 cose da sapere identificate dall'autrice sono, purtroppo, le stesse di 20 anni fa (e anche 30) e tutt'altro che facili da risolvere in pratica (i commenti di fianco ad ogni voce sono miei):

1. L'identificazione dei requisiti ha diversi ruoli (stipulare il contratto, definire le funzionalità del software) che non necessariamente richiedono lo stesso livello di dettaglio e precisione.
2. L'utente finale deve essere coinvolto nel processo di definizione iniziale. Sembra banale ma, a parte che non è sempre facile a farsi, non necessariamente porta ad un risultato di qualità: l'utente è bravo ad usare un sistema per svolgere una determinata attività, normalmente non nel concettualizzare queste funzionalità ed immaginarsele sulla carta.
3. I requisiti devono avere il giusto livello di dettaglio. Nella maggior parte dei casi, cioè nel mondo del software gestionale, ciò è totalmente soggettivo e dipendente dal contesto e dalle persone coinvolte nelle diverse fasi del progetto.
4. I requisiti sono destinati a cambiare. E' una certezza della vita, il saperlo però non ci aiuta molto nella gestione del cambiamento in corso d'opera.
5. E' necessario ascoltare chi realizza il progetto ed agire di conseguenza. Non c'entra molto con l'identificazione dei requisiti (sulla carta le applicazioni software sono tutte perfette) ma vale sempre...