10 consigli sull'analisi dei requisiti

di Gianni Tomasicchio - 11 aprile 2009

Nel ciclo di vita di una applicazione PHP tutte le fasi sono importanti. Nella mia esperienza lavorativa ho imparato però che l'analisi dei requisiti è talmente importante da mettere quasi in secondo piano tutto il resto. Ma andiamo con ordine.

L'analisi dei requisiti è l'attività che porta alla definizione del "cosa" dovrà fare l'applicativo. Consiste quindi nel definire quali saranno le funzionalità che il cliente desidera trovare nel prodotto finito. Se l'applicativo non è destinato ad un particolare committente ma al "grande pubblico" allora saranno gli addetti al marketing a definire i requisiti.

L'argomento è vasto e quindi in questo post mi limiterò a segnalare, in maniera schematica, quali sono secondo me gli aspetti da tenere in considerazione per affrontare correttamente questa fase.

  1. L'analisi dei requisiti va sempre fatta, indipendentemente dalla dimensione del progetto, dal numero di sviluppatori o dal tipo di committente.
  2. Per requisiti non bisogna intendere solo le funzionalità che dovranno essere presenti nel sistema ma tutte le richieste del committente (estetica, accessibilità, performance, sicurezza, ecc.)  e più in generale qualsiasi cosa che possa influire sul software da realizzare.
  3. L'analisi va condivisa con il committente sia nella stesura che nell'approvazione. Deve fungere anche da vincolo contrattuale. I documenti di analisi non sono quindi dei documenti "privati", ma devono essere impiegati per interagire con il cliente.
  4. La definizione dei requisiti va fatta coinvolgento il più possibile il committente, i futuri utenti del software, gli esperti del dominio applicativo ed in generale chiunque interagirà con il prodotto finito.
  5. L'analisi deve essere il più possibile dettagliata, a beneficio sia di chi sviluppa che non dovrà inventarsi nulla, sia del cliente che troverà realizzato esattamente quello che desiderava. Ci tengo a sottolinearlo: se i documenti di analisi non sono dettagliati allora serviranno a ben poco.
  6. Il linguaggio da utilizzare in questi documenti deve essere semplice, lineare, privo di ambiguità. Le frasi devono essere brevi e devono definire con chiarezza chi è l'attore, cosa fa e come. Es.: l'utente inserisce nome e cognome e preme il pulsante di invio, il sistema recupera tali informazioni e verifica l'identità dell'utente, ecc..
  7. L'analisi va redatta utilizzando metodi e linguaggi condivisi. L'UML è il linguaggio di modellazione per eccellenza pertanto, se possibile,  l'analisi dei requisiti deve essere effettuata attraverso la definizione dei casi d'uso. Ciò che importa comunque è che l'analisi porti alla scomposizione dell'intero progetto in tante funzionalità atomiche più una serie di requisiti non funzionali. In questo modo sarà facile dividere il lavoro tra gli sviluppatori, sapere qual è il livello di realizzazione dell'intero progetto, valutare i tempi ed i costi complessivi.
  8. La stesura del documento contenente la specifica dei requisiti va effettuata con degli strumenti adeguati alle dimensioni del progetto.  Per piccoli progetti si può usare un semplice editor di testi, mentre per progetti più complessi bisogna prendere in considerazione un tool di analisi più adeguato.
  9. L'analisi dei requisiti non si conclude con la prima stesura del documento delle specifiche software. Molte sono le dinamiche che portano a rivedere i requisiti del progetto in corso d'opera. Di frequente il committente, posto di fronte ad una prima realizzazione del software, richiede delle modifiche. Capita inoltre che durante le fasi di progettazione e di implementazione sia necessario rivedere i requisiti per risolvere determinate problematiche tecniche. In generale bisogna essere preparati a gestire il cambiamento dei requisiti.
  10. Per i suddetti motivi l'analisi è un processo iterativo, che abbraccia tutto il ciclo di vita del software, recepisce le necessità del committente e le canalizza nel processo di realizzazione/modifica del software. Anche durante la fase di manutenzione, quando ormai il software è in produzione da tempo, può essere necessario rimettere mano ai requisiti.

Per il momento mi fermo qui. Ci sarebbero sicuramente tante altre cose da dire a proposito, magari nei prossimi post.

2 commenti

1 Enrico Milano Enrico Milano giovedě 17 dicembre 2009, ore 14:16
Complimenti! Un potere si sintesi veramente notevole. 4 capitoli di Ingegneria del Software in una sola pagina.
Ottimo articolo.
2 franco franco martedě 4 gennaio 2011, ore 12:39
interessante, grazie ;)
Effettua l'accesso o registrati per inserire un commento