Sergio Di Martino » 4.L'ingegneria dei Requisiti

Obiettivi della lezione

• Comprendere il concetto di Ingegneria dei Requisiti
• Comprendere le diverse Tipologie di Requisiti Software
• Requisiti Utente vs. Requisiti di Sistema
• Requisiti Funzionali vs. Requisiti Non Funzionali

Software Lifecycle Activities

Requisiti software

Requisiti di un sistema software:

Cosa deve fare il sistema + Vincoli operativi

Esempi
Il sistema dovrà archiviare i dati di una biblioteca, in particolare dati relativi ai libri, ai giornali, le riviste, video, nastri audio e CD-ROM.
Il sistema dovrà permettere agli utenti di fare delle ricerche per titolo, autore, o ISBN.
L’interfaccia al sistema dovrà essere realizzata utilizzando un World-Wide-Web browser.
Il sistema dovrà gestire almeno 20 transazioni per secondo.
Il sistema dovrà riconoscere l’utente attraverso una smart-card.

Requirement Engineering

L’ingegneria dei requisiti comprende tutte le attività che si occupano di requisiti:

• raccolta dei requisiti;
• analisi dei requisiti;
• specifica / documentazione dei requisiti;
• verifica e validazione dei requisiti.

“The most difficult part of building a software system is to decide, precisely, what must be built. No other part of the work can undermine so badly the resulting software if not done correctly. No other part is so difficult to fix later.” [Fred Brook's]

Requirement Engineering (segue)

La raccolta dei requisiti è spesso considerata l’attività più difficile, perché richiede la collaborazione tra più gruppi di partecipanti con differenti background. Stakeholders: “insieme dei soggetti che hanno un interesse nei confronti di un’organizzazione e che con il loro comportamento possono influenzarne l’attività”:

• tutte le persone in qualche modo interessate alla messa in opera del sistema;
• il cliente e gli utenti finali sono esperti nel loro dominio e hanno una idea generale (spesso vaga) di cosa il sistema debba fare, e poca (o nulla) esperienza nello sviluppo del software;
• gli sviluppatori hanno esperienza nel produrre sistemi software, ma hanno una conoscenza limitata del dominio di applicazione (ambiente degli utenti finali).

Tutti gli stakeholders comunicano tra di loro per definire il sistema da realizzare. Fallimenti nella comunicazione (tra i diversi domini) portano a un sistema difficile da usare o che non supporta le funzionalità richieste. Gli errori introdotti in questa fase sono difficili (e costosi) da risolvere perché sono scoperti nelle ultime fasi del processo di sviluppo del software.

Rischi possibili:

• una funzionalità che il sistema dovrebbe supportare non è specificata;
• funzionalità incorrette o obsolete;
• interfacce utenti poco intuitive e difficile da usare.

Tipi di Requisiti

I Requisiti SW possono essere classificati secondo due diversi punti di vista:

• livello di dettaglio;
• requisiti utente;
• requisiti di sistema.

Tipo di Requisito rappresentato

• requisiti funzionali;
• requisiti non funzionali;
• requisiti di dominio.

Livello di dettaglio

Possono espressi a vari livelli di astrazione e formalismo, dando luogo a 2 tipologie di requisiti:

Requisiti Utente:

• descrivono i servizi richiesti al sistema (comportamento osservabile dall’esterno) e i vincoli operativi del sistema;
• scritti in linguaggio naturale;
• il punto di vista è quello del Cliente, che li sottopone a un possibile Sviluppatore per ottenere una offerta (requisiti aperti a soluzioni alternative).

Requisiti di Sistema:

• formulazione dettagliata, strutturata, di servizi e vincoli;
• scritti in linguaggio naturale, notazioni semi-formali, linguaggi formali;
• il punto di vista è quello dello Sviluppatore, che li puo’ usare anche per il contratto con il Cliente (requisiti più restrittivi).

Un req. utente → molti req. di sistema

Tipi di requisiti

I Requisiti Funzionali descrivono i servizi, o funzioni, offerti dal sistema (normalmente attivati da user-inputs).
“Quando l’utente richiede la visualizzazione dell’estratto conto… allora il sistema deve …”.

I Requisiti Non-Funzionali descrivono vincoli sui servizi offerti dal sistema, e sullo stesso processo di sviluppo.
“La visualizzazione dell’estratto conto deve avvenire entro 4 secondi dalla sua richiesta”.

I Requisiti di Dominio (funzionali e non-funzionali) riflettono caratteristiche generali del dominio applicativo.
“L’accesso alla cassa continua da parte dell’addetto bancario al rifornimento deve avvenire secondo le consuete procedure di sicurezza a doppia-chiave”.

Requisiti Funzionali

Descrivono le interazioni tra il sistema e il suo ambiente indipendentemente dalla sua implementazione (l’ambiente include l’utente e ogni altro sistema esterno).
Esempio

• Il sistema POS NextGen è un’applicazione informatica che deve permettere di registrare le vendite ed in pagamenti in negozi e supermercati.
• Il sistema dovrà permettere ad un utente che vuole pagare con PagoBancomat di inserire il PIN su un’apposita tastiera, dopo aver visualizzato su un display l’elenco degli articoli acquistati.
• Il Display deve mostrare l’elenco degli articolo acquistati, con il relativo prezzo, un eventuale sconto applicato, ed il costo complessivo dell’intera spesa.
• …

I requisiti funzionali devono essere:

• completi: devono indicare tutti i servizi richiesti dagli utenti;
• coerenti: i requisiti non devono avere definizioni contraddittorie.

Per sistemi grossi è difficile ottenere requisiti completi e coerenti: i vari stakeholders hanno esigenze diverse, spesso in contrasto.

Requisiti non funzionali

Descrivono gli aspetti del sistema che non sono direttamente legati al comportamento (funzionalità) del sistema.
Esempio (POS NextGEN).

• Risposta all’autorizzazione entro 30 secondi, nel 90% dei casi.
• Il sistema deve essere in grado di gestire diversi tipi di interfacce utente, quali un display multiriga, un web-browser, etc…
• Qualora ci siano problemi di connettività, il sistema deve comunque registrare in locale il pagamento, in modo da permettere il normale svolgimento degli acquisti nel negozio.

Includono una grande varietà di richieste che si riferiscono a diversi aspetti del sistema, dall’usabilità alle performance.
Varie classificazioni (Sommerville, FURPS+, etc…).

La tassonomia di Sommerville

Il modello FURPS

FURPS è un acronimo per la definizione dei requisiti.
FURPS classifica i Requisiti in:

• Functionality
• Usability = Usabilità
• Reliability = Affidabilità
• Performance
• Supportability = Supportabilità

Requisiti non Funzionali: Il modello FURPS

Usabilità: facilità per l’utente di imparare ad usare il sistema, e capire il suo funzionamento. Includono:

• convenzioni adottate per le interfacce utenti;
• portata dell’Help in linea;
• livello della documentazione utente.

Affidabilità: capacità di un sistema o di una componente di fornire la funzione richiesta sotto certe condizioni e per un periodo di tempo. Includono:

• un accettabile tempo medio di fallimento;
• l’abilità di scoprire specificati difetti;
• o di sostenere specificati attacchi alla sicurezza.

Requisiti non Funzionali: Il modello FURPS (segue)

Performance: riguardano attributi quantificabili del sistema come

• tempo di risposta, quanto velocemente il sistema reagisce a input utenti;
• throughput, quanto lavoro il sistema riesce a realizzare entro un tempo specificato;
• disponibilità, il grado di accessibilità di una componente o del sistema quando è richiesta.

Supportabilità: riguardano la semplicità di fare modifiche dopo il deployment. Includono:

• adattabilità, l’abilità di cambiare il sistema per trattare concetti addizionali del dominio di applicazione;
• mantenibilità, l’abilità di cambiare il sistema per trattare nuove tecnologie e per far fronte a difetti.

Es. di Requisiti non Funzionali per POS NextGEN

• Il testo deve essere visibile da un metro di distanza (Usabilità).
• Qualora ci siano problemi di connettività, il sistema deve comunque registrare in locale il pagamento, in modo da permettere il normale svolgimento degli acquisti nel negozio. (Affidabilità).
• Risposta all’autorizzazione entro 30 secondi, nel 90% dei casi (Performance).
• Deve essere possibile cambiare la lingua del testo visualizzato (Supportabilità / Usabilità).

Requisiti di dominio

Si riferiscono a caratteristiche del sistema che derivano da caratteristiche generali del dominio applicativo.

Problemi:
A volte sono Requisiti impliciti: il Cliente li dà per scontati e non li esprime esplicitamente: ma lo Sviluppatore non lo sa…
A volte sono Requisiti espliciti ma oscuri: Il Cliente descrive requisiti utilizzando termini e concetti che lo Sviluppatore ignora…(→ Glossario).

Esempio
Gestione biblioteca: “There shall be a standard user interface to all databases which shall be based on the Z39.50 standard“.
Lo Standard è noto al personale della biblioteca, non agli sviluppatori.
POS NextGEN
Il codice identificativo dell’articolo, letto mediante codice a barre, può essere basato sui seguenti schemi di codifica:

• UPC
• EAN
• JAN
• SKU

Verificabilità di requisiti non funzionali

I Requisiti non funzionali dovrebbero sempre essere verificabili.
Goal (non verificabile): ‘il sistema deve essere facile da usare per controllori esperti, e deve essere tale da minimizzare gli errori degli utenti’.
Requisito non-funzionale (verificabile): ‘controllori esperti devono poter imparare a usare tutte le funzioni del sistema in max. 2 ore di apprendimento. Dopo l’apprendimento, il controllore deve essere in grado di operare senza commettere piu’ di 2 errori al giorno’.

Quantificazione di requisiti non funzionali

Validazione dei requisiti

E’ un passo critico nel processo di sviluppo. I requisiti sono continuamente validati da cliente e utenti. La validazione dei requisiti richiede di controllare:

• correttezza: una specifica è corretta se rappresenta accuratamente il sistema che il cliente richiede e che gli sviluppatori intendono sviluppare;
• completezza: una specifica è completa se tutti i possibili scenari per il sistema sono descritti, incluso i comportamenti eccezionali;
• coerenza: se i requisiti non si contraddicono tra di loro;
• chiarezza: una specifica è chiara se non è possibile interpretare la specifica in due modi diversi;
• realismo: La specifica dei requisiti è realistica se può essere implementata tenendo conto dei vincoli;
• verificabilità: La specifica dei requisiti è verificabile se, una volta che il sistema è stato costruito, test ripetuti possono essere delineati per dimostrare che il sistema soddisfa i requisiti. Esempio di non verificabilità:il prodotto dovrebbe avere una buona interfaccia – Buono non definito;
• tracciabilità: Ogni funzione del sistema può essere individuata e ricondotta al corrispondente requisito funzionale. Include anche l’abilità di tracciare le dipendenze tra i requisiti, le funzioni del sistema, gli artefatti, incluso componenti, classi, metodi e attributi di oggetti. è cruciale per lo sviluppo di test e per valutare i cambiamenti.

Tipi di raccolta dei requisiti

Classificati sulla base della sorgente dei requisiti:

• Greenfield Engineering: lo sviluppo parte da zero, nessun sistema esiste in precedenza, così i requisiti sono “estratti” dagli utenti e dal cliente. É guidata dalla necessità dell’utente o dalle esigenze del mercato;

• Re-engineering: un sistema esistente viene riprogettato a causa della disponibilità di nuove tecnologie o per estendere funzionalità del sistema;

• Interface Engineering: per fornire i servizi di un sistema esistente in un nuovo ambiente; vengono riprogettate le interfacce; sistemi legacy lasciati inalterati, eccetto che per le interfacce; è guidata dall’introduzione di nuove tecnologie, e da nuove necessità del mercato.