Ingegneria dei Requisiti: Come scrivere correttamente i requisiti

La scrittura dei requisiti

Sebbene i requisiti utente possano essere espressi in un linguaggio naturale, non vale lo stesso per i requisiti di sistema, i quali necessitano di notazioni più dettagliate e specifiche.
Infatti, l’utilizzo del linguaggio naturale richiede che ogni termine adoperato per descrivere un requisito abbia un’ accezione comune a colui che redige il documento e all’ utente.
Un chiaro esempio dell’ambiguità del linguaggio naturale è fornito dallo studioso Jackson (1995):
“Shoes must be worn” – “Le scarpe devono essere indossate”,
“Dogs must be carried” – ” I cani devono essere portati”.

In effetti, entrambi i verbi adoperati (to wear, to carry) si prestano ad un accezione comune: portare, pertanto il significato di ciascuna frase può essere equivocato.
In definitiva, il linguaggio naturale risulta essere eccessivamente flessibile se utilizzato nella specifica dei requisiti. Oltre a questa caratteristica, si è riscontrato che l’adozione di tale metodo di scrittura infici la tracciabilità e una volta definiti, i requisiti verranno collezionati in un documento strutturato che, a vari livelli di dettaglio, dovrà essere completo e coerente.

Dunque, ottenere un buon documento di specifica richiede che i requisiti in esso contenuti siano descritti in modo uniforme e, per fare ciò, diviene molto utile adoperare delle linee guida che vengono indicate in letteratura.stessa dei requisiti, nonchè la possibilità di scovare requisiti correlati al fine di valutare l’impatto di un possibile cambiamento.

Per far fronte all’esigenza di adoperare un linguaggio idoneo, la letteratura propone l’uso del linguaggio naturale strutturato, eventualmente corredato da semplici modelli grafici. L’idea di base è quella di limitare la libertà dell’addetto alla descrizione dei requisiti, così da forzarlo a scrivere ciascun requisito secondo uno “schema” che garantisca l’uniformità delle specifiche, senza sacrificare l’espressività e la comprensibilità peculiari del linguaggio naturale. Di fatto, il linguaggio naturale strutturato limita la terminologia che può essere adoperata attraverso l’uso di modelli per specificare i requisiti di sistema. Inoltre, può includere costrutti di controllo derivati dai linguaggi di programmazione, così come schemi grafici per suddividere le specifiche. In pratica vengono usati costrutti di controllo tiipici di linguaggi di programmazione (if-then-else, while…), forms (moduli predefiniti: nome e descrizione della funzione, input, output, pre-condizioni, ecc.).

Documento di specifica

Una volta definiti, i requisiti verranno collezionati in un documento strutturato che, a vari livelli di dettaglio, dovrà essere completo e coerente.
Dunque, ottenere un buon documento di specifica richiede che i requisiti in esso contenuti siano descritti in modo uniforme; per fare ciò, risulta molto utile adoperare le linee guida riportate in letteratura.
Il punto da cui partire è quello di scegliere un formato standard ed adoperarlo per ciascun requisito, in cui servendosi del linguaggio naturale strutturato, si esprimano le azioni attraverso la forma “dovrà” per i requisiti obbligatori e la forma “dovrebbe” per i requisiti desiderabili.
Inoltre, bisognerà evidenziare i concetti fondamentali contenuti nel requisito, evitando, nel caso di requisiti utente, termini troppo tecnici.

Si può, ad esempio, adoperare un modulo standard costituito dai seguenti campi:

1. Funzione: indicazione della funzione che dovrà o dovrebbe essere svolta o, se vogliamo, il nome della funzione;
2. Descrizione: descrizione sintetica della funzione che dovrà o dovrebbe essere svolta;
3. Input: input della funzione;
4. Sorgente: entità dalla quale arriva l’input;
5. Output: output della funzione;
6. Destinazione: entità alla quale perverrà l’output;
7. Azione: descrizione dettagliata delle azioni che dovranno o dovrebbero essere svolte.

È importante dunque che il dettaglio si riferisca a COSA debba o dovrebbe essere fatto, non al COME, quindi alle scelte implementative.

1. Richiede: indicazione delle azioni pregresse all’esecuzione della funzione corrente;
2. Pre-condizioni: indicazione delle condizioni che debbano o dovrebbero sussistere prima dell’esecuzione della funzione corrente;
3. Postcondizioni: indicazione delle condizioni che debbano o dovrebbero verificarsi dopo l’esecuzione della funzione corrente;
4. Effetti collaterali: indicazione degli effetti che l’adempimento della funzione possa comportare.

Le voci appena mostrate rappresentano solo un esempio dal quale prendere spunto per definire uno schema di strutturazione che possa rispecchiare le specifiche esigenze. Infatti, è possibile eliminare alcune voci o aggiungere tabelle o modelli grafici del sistema, così da pervenire ad un formato più semplice o ad uno più ricco di informazioni.