Gestione dei requisiti software

La gestione dei requisiti software (o “ingegneria dei requisiti”) è l’attività che chiarisce le esigenze di chi ha bisogno di un sistema, e fornisce indicazioni a chi deve svilupparlo.

I requisiti sono importanti per tutti coloro che sono coinvolti nello sviluppo software, e quando non sono chiari (non sono stati espressi bene, specificati bene, capiti bene) possono portare a risultati spiacevoli.

Metafore per la gestione dei requisiti software

La metafora più comune per la gestione dei requisiti nei progetti software è l’altalena:

Incomprensione sui requisiti - la metafora dell'altalena

Un’altra metafora comune per la gestione dei requisiti software è il “Telefono senza fili”, un gioco diffuso nel secolo scorso, prima che esistessero i cellulari (il gioco forse si gioca ancora, ma avrà cambiato nome).

Il gioco è semplice. Una fila di bambini, oppure un cerchio. Il primo sussurra velocemente una frase nell’orecchio del vicino, che a sua volta la ripete al vicino successivo, e così via fino all’ultimo bambino, che per concludere deve dire la frase ad alta voce. Più sono i bambini coinvolti nella sequenza, più la frase finale risulta diversa dalla frase iniziale.

La gestione dei requisiti è analoga. Più lunga è la catena che collega chi ha l’esigenza – il requisito – a chi lo deve soddisfare, maggiore la probabilità di fraintendimenti. Più persone lavorano in sequenza sui requisiti, più aumentano i costi, i tempi, i rischi di incomprensione.


Definizioni di Requisito

Cos’è un “requisito”? Le definizioni di requisito sono molte, e riflettono il punto di vista (il ruolo) di chi li guarda. Eccone alcune.

“Ciascuna delle qualità necessarie e richieste per uno scopo determinato”.
Dal latino “requisitum”, neutro del participio passato di “requirere” ‘chiedere, esigere’ (Giacomo Devoto, Gian Carlo Oli – Il Dizionario della lingua italiana – Le Monnier 2001)

Ian Sommerville e Pete Sawyer (1997): “I requisiti sono … una specifica di ciò che andrebbe implementato. Sono descrizioni di come dovrebbe essere il comportamento del sistema, o di una proprietà o attributo del sistema. Possono costituire un vincolo sul processo di sviluppo del sistema.”

Incose (International Council on Systems Engineering) Requirements Working Group (2001): “Un requisito è una espressione della percezione del bisogno che qualcosa sia
realizzato.”

Cem Kaner, James Bach, Bret Pettichord (Lessons Learned in Software Testing, 2002): “Un requisito è una qualità o condizione che ha importanza per qualcuno importante. … Ai fini del testing, ogni qualità o condizione che il prodotto debba manifestare o soddisfare è un requisito.”

Alan Davis (2005): “Un requisito è una caratteristica di un sistema desiderato, osservabile dall’esterno.”

Robert Martin (2006): “Ciò che non è testabile non serve. Se avete un requisito e non potete provare di averlo soddisfatto, allora non è un requisito.”


Come scoprire i requisiti software

A cosa servono le tecniche di analisi.


I casi d’uso sono una delle tecniche più diffuse per scoprire e per specificare i requisiti.


Materiali per la gestione dei requisiti software

Requisiti-by-Example, una guida ricca di domande ed esempi per individuare i requisiti software.

Una template di documentazione requisiti, nei formati word e odt, per progetti non life-critical, in cui sia necessaria poca formalità.

Una template ancora più basilare per elencare e analizzare i requisiti candidati, in formato
excel.


Una introduzione a Planguage, linguaggio ideato da Tom Gilb per precisare i requisiti.


Bibliografia sui requisiti.


Sistemi di classificazione dei requisiti

ISO 25010 – “Systems and software engineering – System and software quality models”, è uno standard ISO pubblicato nel 2011 che fornisce una classificazione di requisiti non funzionali (o “attributi di qualità”) in sostituzione del precedente standard ISO 9126.

La nuova classificazione distingue tra requisiti sulla qualità intrinseca del prodotto (“product quality”) e requisiti sulle caratteristiche relative all’uso del prodotto (“quality in use”).

Presentazioni sintetiche (pdf) in italiano e in english.


Il mio sistema di classificazione dei requisiti FOCUS-TBD.


Altri sistemi classificatori:

Incose (International Council on Systems Engineering)

Volere


Requisiti e processo di sviluppo

Il modo in cui si gestiscono i requisiti nel processo di sviluppo software ha un forte impatto sull’impostazione dei progetti:


Strumenti per la gestione dei requisiti

Gli strumenti più utilizzati per la gestione dei requisiti sono le normali suite di elaborazione testi, fogli di calcolo, database.

A volte è necessaria una maggiore formalizzazione (es. versionamento dei requisiti, gestione della tracciabilità). In questi casi conviene valutare l’opportunità di ricorrere a strumenti creati specificamente per gestire requisiti.

Condivido, comunque, una osservazione di Karl Wiegers:

“raccomando di non adottare uno strumento dedicato per la gestione dei requisiti, se gli analisti non sono già capaci di scrivere bene i requisiti”.

Gli strumenti non servono a migliorare la qualità dei requisiti. Servono a gestire in modo più efficace ed efficiente i requisiti esistenti.

Un elenco di strumenti per l’ingegneria dei requisiti su Wikipedia: https://en.wikipedia.org/wiki/List_of_requirements_engineering_tools


Formazione