Ingegneria dei Requisiti

Transcript

1 Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A Ingegneria dei Requisiti E. TINELLI

2 Contenuti I requisiti del software Documento dei requisiti I processi di ingegneria dei requisiti Caso di studio: BiblioSYS sistema bibliotecario universitario usato dagli studenti e dalle facoltà per ordinare libri e documenti ad altre biblioteche 2

3 Definizioni Il processo di ricerca, analisi e documentazione dei requisiti è chiamato Ingegneria dei Requisiti (Requirements Engineering) Per l Institute of Electrical and Electronic Engineering (IEEE), i requisiti Esprimono capacità e condizioni (vincoli) necessarie per risolvere problemi o realizzare obiettivi di business degli utenti Sono documentati da contratto, standard, specifiche o altri documenti formalmente convenuti che descrivono le Capacità e Condizioni La loro documentazione, in genere, si basa su una rappresentazione grafica delle Capacità e delle Condizioni che descrivono 3

4 Definizione e specifica dei requisiti Definizione dei requisiti Descrizione orientata al cliente delle funzioni del sistema e delle restrizioni sulle sue operazioni Specifica dei requisiti Descrizione dettagliata e precisa della funzionalità del sistema e delle restrizioni. Intesa per comunicare cosa è richiesto dallo sviluppatore e per servire da base di un contratto per lo sviluppo del sistema 4

5 Domande utili per scrivere i requisiti 1. Cosa deve fare il software? 2. Che interfacce ha con i suoi utenti (con HW, con altro SW)? 3. Che prestazioni deve esibire il SW? 4. Quali attributi (es. portabilità) dovrà avere? 5. Quali vincoli dovrà soddisfare? 5

6 Ruolo dei requisiti I requisiti servono per far comunicare correttamente: gli Stakeholder (o Parti Interessate) tra di loro; portatori di conoscenza del Dominio Applicativo con gli Sviluppatori (portatori di conoscenza del Dominio delle Tecnologie Informatiche). Una Una parte parte interessata è una una classe classe di di persone o sistemi sistemi che, che, a vario vario titolo, titolo, sono sono interessate ad ad una una o più piùcaratteristiche del del prodotto software. Persone Il Manager/Committente/Customer determina i vincoli di costo e di personale da utilizzare, requisiti del processo di sviluppo L Utente è interessato ai servizi resi dal sistema, alla loro qualità ed alla loro adattabilità Lo Sviluppatore è interessato alla componibilità, alla qualità ed alla estensibilità del sistema Sistemi Organi di Legislazione o di Controllo interessati a comportamenti o a livelli di qualità (es.: controllo della composizione degli scarichi certificazione della qualità, ecc.) Sistemi Cooperanti con cui i prodotti da sviluppare devono comunicare 6

7 I livelli di descrizione Requisiti Utente Dichiarano, in linguaggio naturale e\o corredati da diagrammi, quali servizi il sistema dovrebbe fornire ed i vincoli sotto cui deve operare; Sono rivolti a lettori disinteressati ai dettagli dei servizi; Dovrebbero specificare SOLO il comportamento esterno del sistema; Il linguaggio naturale può portare a diversi problemi: mancanza di chiarezza, confusione dei requisiti, mescolanza dei requisiti formato standard, requisiti desiderati ed obbligatori Esempio di di requisito utente? BIBLIOSYS deve deve fornire fornire un un sistema di di contabilità finanziaria che che memorizzi tutti tutti i i pagamenti fatti fatti dagli dagli utenti utenti del del sistema. I I gestori gestori del del sistema possono configurarlo in in modo modo che che gli gli utenti utenti abituali abituali possano ricevere prezzi prezzi scontati. 7

8 I livelli di descrizione Requisiti di Sistema Definiscono le funzioni, i servizi ed i vincoli operativi del sistema in modo dettagliato. Il documento dei requisiti di sistema dovrebbe essere preciso e definire esattamente cosa deve essere implementato; Sono definiti per i lettori che devono sapere con precisione cosa il sistema dovrà fare; Sono versioni espanse dei requisiti utente e dovrebbero descrivere semplicemente il comportamento esterno del sistema, non come il sistema dovrebbe essere progettato o implementato Il linguaggio naturale è poco adatto alla descrizione dei requisiti di sistema 8

9 Alternative alla specifica in linguaggio naturale Linguaggio naturale strutturato - Limitazione delle forme linguistiche usabili, uso di costrutti di controllo tipo linguaggi di programmazione (if-then-else, while ), uso di forms (moduli predefiniti: nome e descrizione della funzione, input, output, precondizioni, ecc.) Linguaggi di descrizione di progettazione - Linguaggi tipo linguaggi di programmazione con caratteristiche più astratte per esprimere requisiti e definire modelli operazionali. Poco usati ma comodi per definire i requisiti di interfaccia poiché definiscono i requisiti fornendo una visione operazionale del sistema. Notazioni grafiche Un linguaggio grafico, aiutato da annotazioni testuali, viene usato per definire i requisiti funzionali del sistema (es. casi d uso proposti da UP). Specifiche matematiche - Linguaggi basati su concetti matematici (es. insiemi o automi a stati finiti). Riducono le ambiguità ma sono di difficile comprensione per il cliente. 9

10 BiblioSYS: : Un esempio di requisiti utente e di sistema Definizione dei requisiti utente BiblioSYS deve memorizzare tutti i dati richiesti per l assegnazione delle licenze sul diritto d autore. Specifiche dei requisiti di sistema Per richiedere un documento, il richiedente deve inoltrare un modulo che contenga i dettagli sull utente e sulla richiesta fatta. I moduli di richiesta di BiblioSYS devono essere immagazzinati nel sistema per 5 anni dalla data della richiesta. Tutti i moduli di richiesta di BiblioSYS devono essere indicizzati per utente, per nome del materiale richiesto e per operatore che soddisfa la richiesta. BiblioSYS deve mantenere un elenco di tutte le richieste fatte al sistema Per il materiale soggetto al diritto d autore sul prestito, i dettagli devono essere spediti mensilmente alle agenzie per le licenze sui diritti che sono registrate in BiblioSYS. 10

11 Classificazione dei requisiti Requisiti funzionali sono elenchi di servizi che il sistema deve fornire (in alcuni casi possono affermare esplicitamente cosa il sistema non dovrebbe fare) Requisiti non funzionali sono vincoli sui servizi offerti dal sistema (es. vincoli temporali, sul processo di sviluppo, sugli standard utilizzati, ecc.) Requisiti di dominio derivano dal dominio di applicazione del sistema, ne riflettono le caratteristiche e possono essere requisiti funzionali o non funzionali. Requisiti informativi - identificano le principali informazioni di business che il sistema deve gestire, la loro struttura e le loro eventuali relazioni (i processi di business sono identificati dai requisiti funzionali) 11

12 Esempi di requisiti funzionali Se espressi come requisiti utente possono essere descritti in modo astratto altrimenti conteranno informazioni di dettaglio: input, output, le eccezioni, ecc. L utente dovrà essere in grado di cercare o in tutti i database o in un loro sottoinsieme Il sistema fornirà i visualizzatori appropriati per permettere all utente di leggere i documenti in memoria Ad ogni ordine verrà associato un identificatore unico (ORDER_ID) che l utente potrà copiare nell area di memoria permanente del suo conto Le specifiche dei requisiti non devono essere ambigue Le specifiche dei requisiti funzionali dovrebbero essere complete e coerenti 12

13 Classificazione dei requisiti non funzionali Requisiti del prodotto - Requisiti che specificano che il prodotto deve comportarsi in un certo modo, per esempio velocità di esecuzione, affidabilità, ecc. Requisiti organizzativi o del processo - Requisiti che sono conseguenza di politiche aziendali e procedure, per esempio il processo utilizzato, mezzi di implementazione, ecc. Requisiti esterni - Requisiti che sorgono da fattori che sono esterni al sistema ed al suo processo di sviluppo, per esempio requisiti di interoperabilità, requisiti legislativi, ecc. 13

14 Tipi di requisiti non funzionali 14

15 Esempi di requisiti non funzionali Requisiti del prodotto L interfaccia utente per il sistema BiblioSYS deve essere realizzata con una semplice pagina HTML Requisiti organizzativi Il processo di sviluppo del sistema e la consegna dei documenti devono conformare processo e deliverable definiti dallo standard X. Requisiti esterni Il sistema non deve dar modo agli operatori della biblioteca di accedere alle informazioni personali degli utenti oltre al nome ed al numero di riferimento. 15

16 Misure dei requisiti non funzionali 16

17 Requisiti di dominio Derivano dal dominio di applicazione del sistema piuttosto che dalle specifiche necessità degli utenti Possono essere nuovi requisiti funzionali, porre nuovi vincoli o definire particolari calcoli Se questi requisiti non sono soddisfatti, potrebbe essere impossibile far sì che il sistema lavori in modo soddisfacente Esempi di requisiti di dominio per BiblioSYS: Deve esserci un interfaccia utente uniforme per tutti i database basata sullo standard X (vincolo di progettazione) A causa delle restrizioni sul copyright, alcuni documenti devono essere cancellati immediatamente dopo la stampa. A seconda dell utente, questi documenti possono essere stampati localmente sul server del sistema per l invio manuale all utente oppure devono essere inoltrati ad una stampante di rete 17

18 Specifica delle interfacce software Molti sistemi software operano in un ambiente che include altri sistemi. Possono doversi interfacciare con questi sistemi in diversi modi (tali specifiche dovrebbero essere definite in fase di analisi dei requisiti ed incluse nel documento dei requisiti) Tre tipi di interfacce possono dover essere definiti in un documento di specifica dei requisiti: Interfacce procedurali: servizi offerti da sottosistemi già esistenti Interfacce dei dati: strutture dati che vengono trasmesse da un sottosistema all altro Interfacce di rappresentazione: specifici pattern utilizzati per descrivere dati 18

19 La tecnica Quality Function Deployment (QFD) QFD traduce i bisogni del cliente in requisiti tecnici per il software concentrandosi sulla massimizzazione della soddisfazione del cliente nei confronti del processo di sviluppo del SW La tecnica QFD identifica tre tipi di requisiti: Requisiti normali corrispondono ad obiettivi fissati per il prodotto determinati durante le riunioni con il cliente. Se tali requisiti sono presenti il cliente è soddisfatto. Requisiti attesi sono impliciti nel sistema e sono talmente fondamentali che il cliente potrebbe dimenticare di esplicitarli (affidabilità, usabilità del sistema e facilità di installazione, ecc.) Requisiti interessanti riflettono funzionalità che vanno oltre le attese del cliente ma possono essere di notevole soddisfazione per il cliente. Attenzione a non esagerare con i requisiti interessanti!! 19

20 I requisiti in pratica Spesso i requisiti non possono andare nei dettagli perché essi sono molti e complessi; pertanto l analista deve generalizzare e descrivere il requisito concettualmente L analista deve trascurare i dettagli che possono essere lasciati come gradi di libertà agli sviluppatori; deve descrivere tutti i dettagli che devono essere vincolanti. 20

21 I requisiti in pratica - Esempio Transazione Economica (TE) di uno studente, comprende: Pagamento tasse annuali o un rateo di esse Pagamento delle more Pagamento della tassa di laurea Aggiornamento di Stato Economico (SE): Ogni volta che uno studente vuol fare una TE il sistema calcola e notifica l importo tenendo conto di esoneri (Algoritmo xxx) e more (Algoritmo yyy); eseguita la TE il sistema aggiorna SE; quando una TE attesa non si verifica, la carenza è segnalata sullo SE; una TE può essere eseguita ad uno sportello, via INTRANET o via INTERNET. 21

22 Requisiti trascurati Il colloquio sistema-utente per la rilevazione della TE; La modalità di registrazione dell avvenuto pagamento o il ritardato pagamento; La modalità di estrazione delle informazioni necessarie per gli algoritmi citati. 22

23 Tracciabilità dei requisiti La tracciabilità è una proprietà della specifica dei requisiti che permette di trovare facilmente i requisiti correlati Alcuni tools CASE offrono strumenti di supporto alla tracciabilità. Per esempio, possono trovare tutti i requisiti che usano gli stessi termini. Tecniche: Assegnare un identificatore unico a ciascun requisito Costruire la lista dei riferimenti incrociati ai requisiti usando tale id Uso di link ipertestuali (es. HTML) per realizzare meccanismi di navigazione della tracciabilità Produrre una matrice dei riferimenti incrociati per ogni documento che mostra i requisiti in relazione fra loro. Più matrici possono essere necessarie per diversi tipi di relazioni 23

24 Esempio di Matrice di Tracciabilità Req id 1.1 U R 1.2 U R U 1.3 R R 2.1 R U U 2.2 U 2.3 R U 3.1 R 3.2 R U : il requisito di riga Usa la funzionalità descritta nel requisito in colonna R: relazione più debole fra due requisiti (es. si riferiscono entrambi allo stesso sottosistema) 24

25 Documento dei requisiti software Il Documento dei Requisiti Software o Specifiche dei Requisiti del Software (SRS) è ciò che ufficialemente deve essere implementato dagli sviluppatori. Contiene generalmente sia requisiti utente che requisiti di sistema. Differenti utenti differenti requisiti Formato dipendente anche da processo di sviluppo adottato e dalle caratteristiche del progetto Esistono standard per la specifica dei requisiti di sistema. 25

26 Documento dei requisiti Requirements Documents secondo lo standard IEEE/ANSI Introduzione 1 Scopo del documento dei requisiti 2 Scopo del prodotto 3 Definizione, acronimi ed abbreviazioni 4 Riferimenti 5 Overview dell intero documento Descrizione generale 1 Prospettive sul prodotto 2 Funzioni del prodotto 3 Caratteristiche degli utenti 4 Vincoli generali 5 Assunzioni e dipendenze Requisiti specifici Appendici Indici 26

27 Documento dei requisiti (1/2) Proposto da Sommerville, e ispirato allo standard IEEE/ANSI Introduzione Perché il sistema è desiderabile e come si inquadra negli obiettivi più generali del Cliente, descrive in breve le funzioni Glossario I termini e i concetti tecnici usati Definizione dei Requisiti funzionali (requisiti utente) I servizi richiesti Definizione dei Requisiti non funzionali (requisiti utente) I vincoli operativi del sistema, e quelli sul processo di sviluppo Architettura La strutturazione in sottosistemi (cui riferire i requisiti) 27

28 Documento dei requisiti (2/2) Specifiche dei requisiti di sistema Specifica dettagliata dei requisiti funzionali e non funzionali Modelli del sistema Modelli formali o semi-formali (ciascuno illustra un solo punto di vista: controllo, dati, funzioni) Evoluzione del sistema Previsione di successivi cambiamenti (per es. di HW, o di requisiti) Appendici Individuazione ed eventuale descrizione della piattaforma hardware RequisitidiDataBase Piani di Test Indici 28

29 Processo di produzione dei requisiti 29

30 Studio di fattibilità Studio preliminare sulle implicazioni che il sistema avrà una volta costruito e sulla sua convenienza. Risultato di questa fase sarà una raccomandazione sul continuare o meno lo sviluppo. Le domande a cui tipicamente uno studio di fattibilità dovrà rispondere sono: Il sistema contribuisce al raggiungimento degli obiettivi dell organizzazione a cui è rivolto? Con quale contributo? Può il sistema essere implementato con le tecnologie correnti e con costi e tempi prevedibili? Può il sistema essere integrato con sistemi pre-esistenti? Quali attività il sistema dovrà supportare e cosa potrà essere lasciato fuori? 30

31 Elicitazione Scopo: Acquisizione/cattura/scoperta dei requisiti Sorgenti Obiettivi di Business delle imprese destinatarie Conoscenza del Dominio Applicativo Opinioni di stakeholder di sistemi analoghi Ambienti operativi (timing,interoperabilità,ecc.) Ambienti organizzativi (cultura,logistica,ecc.) Tecniche Interviste Scenari d uso Prototipi Conferenze,Riunioni, Incontri, News per Comunità Valutazioni di sistemi concorrenti Studio del problema e del dominio applicativo 31

32 Analisi e Negoziazione Caratterizzazione dei Requisiti: Prodotto o Processo; Funzionali o Non Funzionali; Priorità (critici, obbligatorio, fortemente desiderabile, desiderabile, opzionale, ecc.); Scopo (caratterizzazione dei destinatari), Volatilità/Stabilità (nello spazio e nel tempo); Parti Comuni o Parti Varianti Modello Concettuale. Si usa un linguaggio di rappresentazione che può dipendere da: i concetti da esprimere; la esperienza dell analista; i vincoli del committente; i tools disponibili. Negoziazione Risoluzione di eventuali conflitti tra i requisiti espressi. Modifica dei requisiti accordandosi con il cliente Assegnare priorità ai requisiti 32

33 Specifica dei requisiti Produzione dei Manufatti finali Requisiti di Sistema/ Concetti Operativi. Definisce i requisiti di sistemi a livello alto, dal punto di vista dello stakeholders (Standard IEEE ). Esso serve per Validare i requisiti; pertanto deve utilizzare termini e concetti caratteristici del Dominio Applicativo. Può utilizzare un linguaggio di rappresentazione. Specifiche dei Requisiti Software (SRS). Dettaglia la parte dei Requisiti di Sistema che sono stati allocati al software. Esso utilizza un linguaggio di rappresentazione semiformale o formale. 33

34 Verifica e Validazione Verifica dei Requisiti - Conformità e correttezza del modello. Ispezione, per verificare il modello; Validazione dei Requisiti - Corrispondenza dei contenuti alle richieste che il Sistema deve soddisfare. Statica Ispezione, per validare il modello Dinamica Prototipi per validare i comportamenti più critici Test di Accettazione per validare che il sistema finale soddisfi i requisiti richiesti. 34

35 Check list per la validazione dei requisiti Consistenza. Ci sono conflitti fra requisiti? (automatizzabile) Completezza. Sono incluse tutte le funzioni desiderate dal Cliente e dagli Stakeholders? (non automatizzabile) Realismo. Possono essere implementati questi requisiti, dati i limiti di tempo, budget, e tecnologia? Verificabilità. Si può scrivere un insieme di test per verificare che questo specifico requisito è soddisfatto? Tracciabilità. Viene espressa chiaramente l origine del requisito? 35