Analisi dei requisiti: Che cos’è e proprietà dei requisiti software

Analisi dei requisiti

Un requisito è una descrizione di qualcosa che il sistema dovrà fare, o di un vincolo che il sistema dovrà rispettare durante l’esecuzione dei suoi compiti, e che può essere data su diversi livelli di astrazione.

Requisiti utente, di sistema, funzionali e non funzionali

I requisiti si possono dividere per livelli di dettaglio (suddivisione proposta da Alan Mark Davis): si distingue tra i requisiti utente, una specifica in linguaggio naturale dei bisogni dell’utente, e i requisiti di sistema, una specifica molto dettagliata, scritta per lo sviluppatore, di cosa il sistema dovrà fare. Potranno essere scritti in linguaggio naturale (normale o strutturato attraverso form e template) ma anche attraverso linguaggi di specifica algebrici come il linguaggio Z. I requisiti utente spesso sono usati come forma di contratto tra cliente e software house. Naturalmente, dev’esserci consistenza tra requisiti di sistema e requisiti utente (in un documento potranno anche esserci riferimenti all’altro).

E’ importante che i requisiti utente non contengano termini tecnici, ma termini del dominio applicativo per cui stiamo sviluppando: dev’essere comprensibile al cliente. Nelle slides esempio di requisito utente e di sistema che dice come deve svolgersi l’aggiunta di un nodo in un editor grafico per modelli di design.

Requisiti funzionali e non funzionali

I requisiti funzionali sono quelli che hanno a che fare con le funzionalità del sistema che andremo a implementare, ad es. per un sistema bancario, il sistema dovrà permettere la consultazione del saldo è un requisito funzionale. I requisiti non funzionali invece non sono direttamente collegati con le funzionalità da implementare, ma si riferiscono a modalità operative e vincoli, come ad esempio tempi di risposta, piattaforme supportate, scelta dei linguaggi, risorse richieste, strumenti e tecniche di implementazione varie. I requisiti non funzionali possono essere ulteriormente suddivisi tra loro in requisiti di prodotto (efficienza, usabilità, portabilità, affidabilità), requisiti di organizzazione (tempi di consegna, standard da adottare) e requisiti esterni (etici, come ad esempio la scelta di usare solo software libero, legali o di interoperabilità).

Proprietà necessarie per buoni requisiti

• validità e correttezza: dobbiamo chiederci se i requisiti che abbiamo descritto sono veramente conformi ai bisogni dell’utente e se ce ne sono di troppo.
• consistenza: non ci sono requisiti incompatibili tra di loro, il documento è scritto con chiarezza (ad esempio: ogni volta che utilizziamo una parola ha lo stesso significato, non ci sono ambiguità).
• completezza: tutto ciò che vuole il cliente è coperto dai requisiti (questo avviene molto raramente).
• realismo: tutto ciò che è richiesto è implementabile (qui viene in aiuto l’informatica teorica che ci dice cosa possiamo/non possiamo calcolare).
• inequivocabilità: una sola interpretazione possibile.
• verificabilità: dev’essere sempre possibile eseguire un test per verificare i requisiti (ad esempio un vincolo di tempo sarà non “la risposta deve essere immediata” ma “la risposta deve avvenire in X millisecondi”).
• tracciabilità: dev’essere possibile risalire da una funzionalità al requisito che l’ha generata in modo semplice (nelle slide un esempio di matrice di tracciabilità).