A3_1 V2.2 Analisi dei Requisiti e Specifica Significato, motivazioni e processi

Transcript

1 Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE Paolo Salvaneschi A3_1 V2.2 Analisi dei Requisiti e Specifica Significato, motivazioni e processi Il contenuto del documento è liberamente utilizzabile dagli studenti, per studio personale e per supporto a lezioni universitarie. Ogni altro uso è riservato, e deve essere preventivamente autorizzato dall autore. Sono graditi commenti o suggerimenti per il miglioramento del materiale

2 INDICE Significato e Motivazioni Identificazione dei requisiti Che cosa si identifica Da dove si identifica Rischi Negoziazione Modellazione ed analisi Comunicazione A3 - Requisiti Paolo Salvaneschi 2

3 Motivazioni Requisiti Specifica Progetto Implementazione A3 - Requisiti Paolo Salvaneschi 3

4 Motivazioni La principale misura del successo di un sistema software è il grado di soddisfazione degli scopi per cui è stato pensato Il costo di una modifica ad un prodotto software aumenta al procedere delle fasi di sviluppo A3 - Requisiti Paolo Salvaneschi 4

5 Significato Analisi dei requisiti (Requirements Engineering): Scoprire, identificare gli scopi Identificare le parti interessate (Stakeholders) ed i loro bisogni Concordare / Contrattare i bisogni Documentare, analizzare, comunicare nel vocabolario del dominio del problema e non della soluzione Definire funzioni e caratteristiche non funzionali del prodotto informatico A3 - Requisiti Paolo Salvaneschi 5

6 Significato A3 - Requisiti Paolo Salvaneschi 6

7 Significato Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behaviour, and to their evolution over time and across software families. Zave, P. (1997). Classification of Research Efforts in Requirements Engineering. ACM Computing Surveys, 29(4): A3 - Requisiti Paolo Salvaneschi 7

8 Significato Difficoltà del processo di analisi dei requisiti Più parti interessate Responsabili del cliente Utilizzatori Responsabili del fornitore Progettisti Leggi e regolamenti Un potenziale mercato di clienti Il pubblico e la società nel suo complesso A3 - Requisiti Paolo Salvaneschi 8

9 Significato Difficoltà del processo di analisi dei requisiti Obiettivi diversi e variabili nel tempo Cooperazione e conflitti Viste diverse Incompletezza Requisiti difficili da definire con chiarezza Requisiti impliciti e assunzioni Vincoli al di fuori del controllo A3 - Requisiti Paolo Salvaneschi 9

10 Significato L analisi dei requisiti è un processo Multidisciplinare Computer science Aspetti linguistici e comunicazione Aspetti cognitivi Aspetti sociologici.. Centrato attorno agli aspetti umani A3 - Requisiti Paolo Salvaneschi 10

11 Significato Contesti diversi dell analisi dei requisiti Tipo di utilizzo Software su misura per un cliente Famiglia di applicazioni Prodotto per il mercato Le caratteristiche dell analisi cambiano significativamente al cambiare del contesto A3 - Requisiti Paolo Salvaneschi 11

12 Significato Contesti diversi dei analisi dei requisiti Tipo di prodotto Sistema informativo Sistema embedded Software di base. A3 - Requisiti Paolo Salvaneschi 12

13 Identificazione dei requisiti Identificazione ed analisi degli obiettivi del contesto dei comportamenti desiderati (relativi al contesto) Requisiti Specifica Formalizzazione di un elenco di funzioni e caratteristiche del prodotto inserito nel contesto Progetto Implementazione A3 - Requisiti Paolo Salvaneschi 13

14 Identificazione dei requisiti Contesto esistente Requisiti Specifica Progetto PERCHE' COSA (nei termini del contesto) COSA (nei termini del prodotto informatico) COME Implementazione Nuovo contesto A3 - Requisiti Paolo Salvaneschi 14

15 Identificazione dei requisiti Contesto esistente Requisiti Specifica Progetto Implementazione Nuovo contesto Comprensione dell' ambiente Comprensione dei bisogni (obiettivi, comportamenti attesi ) Acquisizione di conoscenza A3 - Requisiti Paolo Salvaneschi 15

16 Identificazione dei requisiti Contesto esistente Requisiti Specifica Progetto Implementazione Nuovo contesto Qualità come capacità predittiva della soddisfazione del cliente Qualità come conformità rispetto alle specifiche funzionali e non funzionali Qualità come soddisfazione del cliente A3 - Requisiti Paolo Salvaneschi 16

17 Che cosa si identifica Quale è il problema Gli obiettivi Il contesto esistente I comportamenti desiderati nel contesto (requisiti) Gli utenti I confini del prodotto informatico I compiti del prodotto informatico (specifica) A3 - Requisiti Paolo Salvaneschi 17

18 Che cosa si identifica Il problema Gli obiettivi Il contesto esistente I comportamenti desiderati nel contesto (requisiti) Gli utenti I confini I compiti del prodotto informatico (specifiche funzionali e non funzionali) A3 - Requisiti Paolo Salvaneschi 18

19 Esempio Prodotto software: sistema informatizzato di gestione della terapia farmacologica: prescrizione, preparazione e somministrazione di farmaci in un ospedale.. Obiettivi Miglioramento della sicurezza per il paziente (abbattimento dell errore di terapia), aumento del tempo dedicato all assistenza del paziente. Miglioramento nei processi organizzativi, nella collaborazione e comunicazione fra medici, farmacisti ed infermieri Tracciabilità del processo farmacologico, documentazione di terapia completa Eliminazione dei documenti cartacei per l operatività A3 - Requisiti Paolo Salvaneschi 19

20 Esempio.. Gestione del processo di prescrizione, preparazione e somministrazione di un ciclo di terapia protocollata. Gestione dei processi prescrizione, preparazione e somministrazione di terapie non protocollate: Terapia al bisogno Terapia con infusione continua Terapia estemporanea Terapia ad orario standard Terapia urgente Gestione dello stato di una terapia e controllo dei vincoli relativi al passaggio di stato. Tracciabilità di ogni operazione (esecutore e descrizione operazione). Requisiti A3 - Requisiti Paolo Salvaneschi 20

21 Esempio Specifiche A3 - Requisiti Paolo Salvaneschi 21

22 Esempio Sistema Informativo per la gestione delle entità territoriali e per l erogazione dei servizi tributari edilizi demografici di un comune. Specifiche funzionali e non funzionali Gestione Unità edilizie elementari Inserimento del primo inviluppo planimetrico in forma vettoriale di un Unità edilizia elementare specificata. Inserimento di un nuovo inviluppo planimetrico in forma vettoriale di un Unità edilizia elementare specificata. Modifica di un Unità edilizia elementare. Gestione Unità edilizie elementari Ricerca di uno specifico immobile attraverso un input alfanumerico o attraverso un input cartografico: Il tempo di esecuzione deve in entrambi i casi essere paragonabile al tempo impiegato dall attuale applicazione alfanumerica su AS400 A3 - Requisiti Paolo Salvaneschi 22

23 Esempio Specifiche non funzionali (o vincoli o di qualità ) Il modello di qualità ISO 9126 Caratteristiche di un prodotto software: Funzionalità Affidabilità Usabilità Efficienza Manutenibilità Portabilità A3 - Requisiti Paolo Salvaneschi 23

24 Che cosa si identifica Funzionalità: attributo del software relativo all'esistenza di uno specifico insieme di funzioni (e relative caratteristiche) che soddisfano le esigenze richieste o definite; Affidabilità: attributo del software relativo alla capacità di mantenere un definito livello di prestazioni nelle condizioni previste per un periodo di tempo previsto; Usabilità: attributo del software relativo agli sforzi necessari per l'uso e relativo alla valutazione di tale uso per un prefissato insieme di utenti; Efficienza: attributo del software che valuta la relazione tra le prestazioni e la quantità di risorse impiegate in condizioni prefissate; Manutenibilità: attributo del software relativo allo sforzo necessario per apportare le modifiche richieste; Portabilità: attributo del software che valuta la possibilità di trasferire il software da un ambiente ad un altro. A3 - Requisiti Paolo Salvaneschi 24

25 Che cosa si identifica Specifiche non funzionali Devono essere il più possibile quantificate Il sistema deve essere in grado di monitorare fino a 1000 utenze connesse. Il sistema, in caso di comportamento non desiderato (rispetto a comportamenti dichiarati), invia un messaggio all'utenza. Il tempo di risposta (tempo trascorso dal manifestarsi dell'evento non desiderato all'emissione del messaggio verso l'utente) deve essere inferiore a 5 minuti. Possono essere proprietà emergenti relative al sistema intero Il throughput del call center deve aumentare del 20 % A3 - Requisiti Paolo Salvaneschi 25

26 Da dove si identifica Le fonti di conoscenza Le parti interessate La conoscenza del dominio applicativo La documentazione esistente A3 - Requisiti Paolo Salvaneschi 26

27 Rischi Rischi: Requisiti come che cosa sintetico Nessun modello esplicito del contesto Nessuna definizione degli obiettivi Nessuna traccia dei ragionamenti seguiti per analizzare il contesto e sintetizzare le specifiche A3 - Requisiti Paolo Salvaneschi 27

28 Rischi Non esiste spiegazione del PERCHE Possibile risultato: Software di ottima qualità interna ma non è quello che serve A3 - Requisiti Paolo Salvaneschi 28

29 Rischi Rischi: Specifiche incomplete o vaghe Specifiche contraddittorie Carente identificazione dei requisiti non funzionali Possibile risultato: Necessità di modifiche in corso d opera A3 - Requisiti Paolo Salvaneschi 29

30 Rischi Il documento dei requisiti è un modello di una parte della realtà generato in un contesto di Complessità, viste diverse, conoscenza incompleta, conflitti,. In pratica il documento dei requisiti contiene un dettaglio ritenuto sufficiente per stimare costi, progettare e realizzare In ogni caso è necessario gestire requisiti che contengono inconsistenze, sono ulteriormente dettagliati nelle fasi successive evolvono nel tempo A3 - Requisiti Paolo Salvaneschi 30

31 Negoziazione Negoziazione dei requisiti Divisione in classi Requisiti obbligatori. Irrinunciabili per il cliente Requisiti desiderabili. Non necessari, ma utili Requisiti opzionali. Relativamente utili, oppure contrattabili in seguito A3 - Requisiti Paolo Salvaneschi 31

32 Modellazione ed analisi L identificazione dei requisiti genera un modello del sistema da realizzare e del suo contesto di utilizzo Il modello può essere utilizzato per studiare proprietà del sistema A3 - Requisiti Paolo Salvaneschi 32

33 Modellazione ed analisi Approcci diversi di modellazione Il comportamento di un organizzazione (flussi di dati, regole di business, ) Modelli basati sui dati Modelli del comportamento (la dinamica) dei sistemi A3 - Requisiti Paolo Salvaneschi 33

34 Modellazione ed analisi Linguaggi diversi di modellazione Linguaggio naturale Linguaggio naturale strutturato Linguaggi semiformali (grafici) Linguaggi formali A3 - Requisiti Paolo Salvaneschi 34

35 Modellazione ed analisi Analisi Verifiche di consistenza Animazione Ragionamento automatico A3 - Requisiti Paolo Salvaneschi 35

36 Comunicazione L analisi dei requisiti è basata su processi di comunicazione tra progettisti, responsabili, utenti, esperti, Necessità di documentazione Linguaggi di specifica Espressivi Rigorosi Leggibili da utenti di diversa formazione A3 - Requisiti Paolo Salvaneschi 36

37 Comunicazione Un documento di specifica può contenere un insieme complesso di elementi Gestione dei requisiti Standard di documentazione Tracciabilità (Seguire la vita dei requisiti lungo il processo di sviluppo) A3 - Requisiti Paolo Salvaneschi 37