Abbiamo approfondito le caratteristiche delle metodologie di sviluppo software per comprendere più approfonditamente come si instauri, nelle diverse configurazioni, l’analisi dei requisiti.

Per quanto lo scopo e la connotazione di questa fase resti pressappoco la medesima in ogni metodologia, ciò che cambia è il modo in cui viene realizzata e come entra in contatto con lo sviluppo nel suo complesso.

Nelle metodologie pesanti, di cui il modello a cascata è l’esempio principe, l’analisi dei requisiti costituisce un passo preliminare e vincolante.

L’approccio con cui si affronta questa fase della realizzazione è approfondito quanto più possibile, con l’intento di predeterminare tutti i fattori e gli elementi costitutivi del prodotto.

E’ difficile che il documento della Specifica dei Requisiti venga rivisto successivamente, nelle altre fasi. Piuttosto, seguendo il principio di sequenzialità, gli output di ogni fase costituiscono gli input dei successivi, congelando la loro identità.

Dopo aver osservato il modello a spirale, ci è facile comprendere perché l’analisi dei requisiti sia diversa in questa famiglia metodologica. Sebbene permanga, infatti, una mentalità sequenziale e lineare, nei modelli iterativi incontriamo una ripetizione delle fasi a ogni nuovo passo del progetto.

L’analisi dei requisiti, in questo senso, è affrontata ogniqualvolta si aggiunge un tassello al progetto software. La parzialità dei cicli di sviluppo rispetto al prodotto completo fanno sì che l’analisi dei requisiti sia meno vincolante e più ancorata ai feedback raccolti nel corso dello sviluppo.

Come detto, la burocrazia e la centralizzazione sono aspetti fortemente attenuati nella metodologia agile.

Coerentemente, i documenti di Specifica dei Requisiti non soffrono della rigidità tipica delle metodologie pesanti ma, anzi, sono suscettibili di un controllo continuo operato insieme ai committenti.

Più che una fase chiusa in se stessa, quindi, assistiamo nei modelli agili a una compenetrazione tra le diverse tappe della progettazione, che si incontrano nell’orizzontalità delle relazioni tra sviluppatori e clienti.