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

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.

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

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à).

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: www.vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *