Ingegneria del software Modulo 1 -Introduzione al processo software Unità didattica 2 -Gestione requisiti Ernesto Damiani Università degli Studi di Milano Lezione 2 – I requisiti
I requisiti I requisiti specificano cosa un sistema software deve fare e non come deve farlo Il what vs. how dilemma: quello che per qualcuno è il “cosa”, per altri è il “come”
Classi di requisiti (1) I requisiti appartengono a quattro classi Requisiti funzionali – Specificano una funzione che il sistema deve compiere Requisiti non funzionali – Prestazioni, affidabilità, efficienza, portabilità, modificabilità ecc. – Solitamente sono globali
Classi di requisiti (2) Requisiti inversi – Specificano operazioni che il sistema non deve fare – Sono relativi alla sicurezza Specifiche di progetto/implementazione – Sono legati alla tecnologia (es. WWW, XML, Java)
Priorità dei requisiti I requisiti vengono anche suddivisi in classi di priorità MUST: requisiti che il sistema deve assolutamente avere per poter fornire le funzionalità richieste dal committente SHOULD: requisiti che rendono il sistema migliore o comunque più accettabile per il committente MAY: requisiti che migliorerebbero il sistema e che si possono aggiungere se i tempi e i budget lo consentono.
Analisi e negoziazione Attività di analisi dei requisiti rilevati nella fase precedente per identificare carenze, ambiguità e conflitti È richiesto un negoziato tra tutti gli stakeholder
Formalizzazione Registrazione dei requisiti in un documento da condividere tra sviluppatori, utenti e management Uso di linguaggi formali o semiformali
Validazione Controllo dei requisiti formalizzati per rimuovere ridondanze e ambiguità Controllo di qualità sui requisiti FINE