![Page 1: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/1.jpg)
Ingegneria dei RequisitiIngegneria dei Requisiti(Requirements Engineering)(Requirements Engineering)
Paolo Giorginihttp://www.dit.unitn.it/˜pgiorgio
![Page 2: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/2.jpg)
Progetti SoftwareProgetti Software
Tuttavia del 26% non tutti sono esenti da problemi:– Denver Airport: più di 50 milioni di US$ per errori del sistema di
controllo dei bagagli– London Ambulance Service: il sistema è stato disattivato dopo un
giorno di funzionamento
“26% di progetti software terminano con successo”Standish Group, CHAOS Report, 2000
“… cioè il 74% falliscono”Standish Group, CHAOS Report, 2000
![Page 3: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/3.jpg)
Tom De MarcoTom De Marco
“Il 56% degli errori di un software possono essere riferiti ai requisiti”
• Durante lo sviluppo di un software, più tardi un errore viene rilevato più costoso sarà risolverlo
• Molti errori sono fatti durante la raccolta e l’analisi dei requisiti• Molti errori relativi ai requisiti possono (e devono) essere
rilevati il prima possibile• Errori tipici: uso di fatti non corretti, omissioni, inconsistenze e
ambiguità• Errori nella specifica dei requisiti sono uno dei problemi
principali per l’industria software
![Page 4: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/4.jpg)
CostiCosti
![Page 5: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/5.jpg)
… … in Europain Europa
• Un questionario inviato a 3.805 società ha rilevato:
• Per gli analisti I problemi principali sono:– Specifica dei requisiti (53%)– Gestione dei requisiti (43%)– Ducomentazione (36%)– Test (35%)
![Page 6: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/6.jpg)
DefinizioneDefinizione
L’ingegneria dei requisiti è una sotto area dell’ingegneria del software che studia il processo di definizione dei requisiti del
sistema da realizzare.
• E’ una nuova area che ha avuto origine nel 1993 con “the 1st International Symposium on RE” Ora siamo alla 12 edizione.
“Il processo di definizione dei requisiti è un’interfaccia tra i desideri (o bisogni) dei clienti e la realizzazione dei questi requisiti come sistema software”
![Page 7: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/7.jpg)
… … un’altra definizioneun’altra definizione
• L’ingegneria dei requisiti è:
“Lo sviluppo e l’uso di tecnologie per raccogliere, specificare e analizzare i requisiti degli utenti/clienti (stakeholders) che saranno
poi realizzati da un sistema software”
![Page 8: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/8.jpg)
Fred Brook’sFred Brook’s
“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.”
![Page 9: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/9.jpg)
• Requriements Engineering come disciplina: 1993– RE (93, 95, 97, 99. 01)
– ICRE (94, 96, 98, 00)
– WER (98, 99, 00, 01)
– Requirements Engineering Journal
• Passato: System Analysis• Oggi: A network of processes
– Pressione da parte del mercato per software di qualità
– Libri (Sommerville, Jackson, Loucopoulos, …)
– Tools (Doors, Requisite-Pro, Caliber-RM)
Breve storiaBreve storia
![Page 10: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/10.jpg)
Requisiti di sistemaRequisiti di sistema
• Definiscono che cosa un sistema deve fare e sotto quali vincoli deve operare, ad esempio: – Il sistema dovrà archiviare i dati di 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à essere accessibile attraverso l’uso di
password
![Page 11: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/11.jpg)
Tipi di requisitiTipi di requisiti• Requisiti Funzionali: definiscono parte delle funzionalitaà del sistema• Requisiti di implementazione: come il sistema dovrà essere
implementato • Requisiti di prestazione: specificano le prestazioni minime accettabili per
il sistema• Requisiti di usabilità: specificano il tempo massimo per mostrare l’uso
del sistema• Requisiti non funzionali
– Esprimono vincoli sotto i quali il software dovrà operare– Possono essere visti come qualità specifiche che il software dovrà
avere (come il software …
• Requisiti-1
– Condizioni che non devono mai accadere– Solitamente associati a requisiti non funzionali
![Page 12: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/12.jpg)
Probelmi legati ai requisitiProbelmi legati ai requisiti
• I requisiti non riflettono i reali bisogni dei clienti • I requisit i sono inconsistenti e/o incompleti• E’ costoso cambiare i requisiti dopo che sono stati definiti e
concordati• Possono esserci delle incomprensioni tra i clienti e chi a raccolto
e anlizzato i requsiti, tra chi ha raccolto i requisiti e il prgettista, e tra il progettista e chi realizzerà il sistema.
![Page 13: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/13.jpg)
Un esempio di incompletezzaUn esempio di incompletezza
• Il sistema dovrà permettere agli utenti di fare delle ricerche per titolo, autore, o ISBN.
• Che cosa significa per i CD-ROM?– Possono non avere un ISBN– Vale solo per i libri– Immaginate se realizzate il sistema con questo requisito
senza considerare i CD-ROM.
• Naturalmente non possiamo scrivere requisiti universali, ma possiamo tentare di essere il più possibile completi.
![Page 14: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/14.jpg)
Determinazione dei requisitiDeterminazione dei requisiti
• Fornire una definizione informale dei requisiti, funzionali e non
• Generalmente in questa fase si parla anche di servizi attesi dal sistema e vincoli a cui deve sottostare
• L’attività di raccolta dei requisiti è svolta da un analista di business (o di sistema) utilizzando tecniche diverse, che possono spaziare dalle tradizionali interviste ai clienti andando (se necessario) fino alla costruzione di prototipi.
• Analisi delle duplicazioni e contraddizioni• Revisioni e rinegozazione dei requisiti• Documento dei requisiti
![Page 15: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/15.jpg)
Raccolta dei requisitiRaccolta dei requisiti
• Discussione con clienti e esperti del dominio• Esperti del dominio conoscenza del
dominio • Clienti requisiti (casi d’uso)• Casi d’uso e conoscenza del domino devono
essere integrati
![Page 16: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/16.jpg)
Metodi di raccolta requisitiMetodi di raccolta requisiti
• Tradizionali– Interviste– Questionari– Osservazioni– Studio dei docuemnti e dei sistemi software
• Metodi moderni– Prototipi– Sviluppo cooperativo delle applicazioni– Sviluppo rapido delle applicazioni
Analizzziamoli
![Page 17: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/17.jpg)
IntervisteInterviste
• Condotte principalemnte con i clienti (anche gli esperti possono essere intervistati)
• Problemi– Generalmente i clienti hanno solo una vaga idea dei
requisiti del sistema e non sono in grado di esprimerli – Possono anche richiedere funzionalità che vanno fuori
i costi e gli obiettivi del progetto– Possibili conflitti
• Due tipi di intervista:– Strutturata (formali)– Non strutturate (informali)
![Page 18: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/18.jpg)
IntervisteInterviste
• Strutturate– Preparate in anticipo– Un’agenda– Domande predeterminate (aperte o chiuse) – Sono generalemnte accompagnate da interviste informali (non
strutturate)
• Non strutturate– Incontri informali– Senza domande anticipate o obiettivi prederminati– Incoraggiare il cliente a parlare di ciò che ha in mente, su cui
l’analista potrebbe non aver riflettuto
• Per entrambe si parte da un contesto di discussione (ad esempio un breve documento inviato in anticipo)
![Page 19: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/19.jpg)
Doamnde da evitareDoamnde da evitare• Domande sulle quali l’intervistatore esprime
(direttaemnte o indirettamente) la propria opinione sul problema– dobbiamo fare le cose nel modo in cui le facciamo?
• Domande prevenute, simili alle precedenti, eccetto che l’opinione dell’intervistatore è chiaraemnte espressa– non intendi fare questo, vero?
• Domande contenenti già la risposta– devi fare le cose in questo modo, non è vero?
Importante è ascoltare
![Page 20: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/20.jpg)
QuestionariQuestionari
• In aggiunta alle interviste – Sostituiscono le interviste quando il progetto è a basso rischio con
obiettivi ben definiti
• Non è possibile chiarimenti sui quesiti e le risposte– Vantaggi: tempo per valutare la risposta, anonomi
– Svantaggi: non c’è la possibilità di discutere e approfondire i quesiti
• I quesiti dovrebbero essere chiusi (evitare i quesiti aperti)• Tre tipi:
– A scelta multipla– A punteggio– Con ordinamento
![Page 21: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/21.jpg)
OsservazioniOsservazioni
• Ricerca di fatti attraverso l’osservazione:– Osservazione passiva: l’analista osserva le attività senza
interruzioni o coinvolgimento diretto del cliente che lavora (anche con videocamera).
– Osservazione attiva: l’analista partecipa direttamente alle attività ed entra a far parte del gruppo di lavoro.
• Svolte per periodi lunghi e con differenti carichi di lavoro
• Difficoltà: le persone tendono a comportarsi diversaemnte quando osservate
![Page 22: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/22.jpg)
Studio dei documenti e Studio dei documenti e dei sistemi softwaredei sistemi software
• Importante per approfondire la conoscenza di dominio• Documenti organizzativi: modulustica aziendale (compilata, se
possibile), descrizione delle procedure lavorative e delle politiche di intervento, piani di business, organigrammi, corrispondenza fra uffici, minute di incontri, registrazioni contabili, corrispondenza esterna, lamentele clienti, ecc.
• Moduli e rapporti di sistema: schermate e rapporti computerizzati (con la relativa documentazione), manuali operativi di sistema, docuemntazione utente, documentazione tecnica, modelli di analisi di progetto, ecc.
• Libri, riviste, pacchetti proprietari (sistemi ERP) - internet
![Page 23: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/23.jpg)
Negoziazione e validazioneNegoziazione e validazione
• In parallelo alla raccolta dei requisiti• Validazione e negoziazione fatta sul
docuemnto dei requisiti (acquisiti)• Revisione del documento
– Requisiti fuori dal contesto– Matrice di dipendenza dei requisiti– Priorità e rischi associati ai requisiti
![Page 24: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/24.jpg)
Matrice di dipendenza Matrice di dipendenza
Requisito R1 R2 R3 R4
R1
R2 Conflitto
R3 Indipendenti Indipendenti
R4 Indipendenti Sovrapposto Sovrapposto
• Conflitti: discussi con i clienti• Sovrapposti: riscritti per eliminari le sovrapposizioni
![Page 25: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/25.jpg)
Priorità e rischi associati ai requisitiPriorità e rischi associati ai requisiti
• Analisi del rischio: identifica i requisiti che potrbbero causare difficoltà nello sviluppo
• Tipologie di rischio: rischio tecnico, rischio di prestazione, rischio di sicurezza, rischio di integrità dei database, rischio nel processo di sviluppo, rischio politico, rischio legale, rischio di volatilità
• Valutazione della priorità: permette al ritaratura del progetto rispetto ai ritardi (es. scaricando i requisiti con bassa priorità per rispettare tempi di progetto).
• Le priorità devono essere negoziate con incontri di gruppo tendo conto dei fattori di rischio
![Page 26: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/26.jpg)
Modellizzazione dei casi d’uso Modellizzazione dei casi d’uso (UML - Unified Modeling Language)(UML - Unified Modeling Language)
• Attori: venditore, cliente e magazzino
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
![Page 27: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/27.jpg)
Casi d’usoCasi d’uso
• Rappresentà un’unità funzionale che fornisce valore ad un attore
• Un attore che non comunica con almeno un caso d’uso è privo d’interesse, mentre il contrario non è necessariamento vero– Un caso d’uso che non comunica con alcun attore è
permesso– Esistono generalizzazioni o specializzazioni di casi d’uso
• Quali sono le responsabilità e le aspettative dell’attore verso il sistema?
• Spesso un caso d’uso corrisponde ad un requisito funzionali
![Page 28: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/28.jpg)
Acquisti online (requisiti)Acquisti online (requisiti)
(R1) Il cliente usa la pagina web del produttore per vedere la configurazione standard del computer (server, desktop, portatile) scelto. Il prezzo è esplicitamente mostrato
(R2) Il cliente sceglie di vedere i dettagli della configurazione, per l’acquisto oppure per definire un’altra configurazione più adatta. Il costo di qualunque configurazione può essere calcolato su richiesta del cliente
(R3) Il cliente può scegliere di ordinare il computer direttamente online oppure può richiedere un incontro con il venditore prima di confermare l’ordine, per ottenere maggiori spiegazioni sui dettagli dell’ordine, una negoziazione del costo, etc.
(R4) Per ordinare, il cliente deve riempire online un modulo con i dettagli della spedizione, l’indirizzo di fatturazione, e i dettagli di pagamento (carta di credito o assegno)
(R5) Dopo che l’ordine del cliente è stato inviato e confermato, il venditore invia elettronicamente una richiesta al magazzino con i dettagli della configurazione ordinata
(R6) I dettagli della transazione, compresi un numero d’ordine e un numero cliente, sono inviati via e-mail al cliente, permettendo a quest’ultimo di controllare lo stato d’ordine
(R7) Il magazzino riceve la fattura dal venditore e spedisce il computer al cliente
![Page 29: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/29.jpg)
Requisito Attore Caso d’uso
R1 Cleinte Mostrare configurazione Computer Standard
R2 Cliente Costruire Configurazione Computer
R3 Cliente, Venditore Ordinare Computer configurato, richiedere contatto commerciale
R4 Cliente Ordinare Computer configurato, verificare e accettare pagamento cliente
R5 Venditore, Magazzino Informare magazzino su ordine
R6 Cliente, Venditore Ordinare computer configurato, aggiornare stato ordine
R7 Venditore, Magazzino Stampare fattura
Acquisti onlineAcquisti onlineAssegnazione dei requisiti ad attori e casi d’usoAssegnazione dei requisiti ad attori e casi d’uso
![Page 30: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/30.jpg)
Casi d’usoCasi d’uso
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
![Page 31: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/31.jpg)
Diagramma dei casi d’usoDiagramma dei casi d’uso
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
<<extend>>
Il significato della relazione <<extend>> è che il caso d’uso Ordinare Computer Configurato può essere esteso dal cliente con il caso d’uso Richiedere Contatto Commerciale
![Page 32: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/32.jpg)
Altri esempiAltri esempi
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
<<include>>
Inserire Piano di Studi include sempre Convalidare piano di studi: ogniqualvolta il
piano di studi è inserito, deve essere anche convalidato
![Page 33: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/33.jpg)
… … ancoraancora
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
Generalizzazione: Il manager Servizi clienti è un tipo di Impiegato Servizi Cliente il quale, a sua volta, è un tipo di Impiegato
![Page 34: Ingegneria dei Requisiti (Requirements Engineering) Paolo Giorgini](https://reader035.vdocuments.mx/reader035/viewer/2022062418/5542eb58497959361e8c2cda/html5/thumbnails/34.jpg)
Documento dei requisitiDocumento dei requisiti1. Premessa
1.1 Obiettivo e scopo del prdotto1.2 Contesto di business1.3 Stackeholders1.4 Soluzioni preliminari1.5 Sintesi del docuemnto
2. Servizi del sistema2.1 Scopo del sistema2.2 Requisiti funzionali2.3 Requisiti non funzionali
3. Vincoli di sistema3.1 Requisiti di interfaccia3.2 Requisiti di presentazione3.3 Requisiti di sicurezza3.4 Requisiti operativi3.5 Requisiti politici e legali3.6 Altri vincoli
4. Aspetti progettuali4.1 Problemi aperti4.2 Programma preliminare4.3 Previsione costi
AppendiciGlossarioDocumenti e moduli di businessRiferimenti