Ingegneria dei Requisiti
(Requirements Engineering)
Paolo Giorgini
http://www.dit.unitn.it/˜pgiorgio
Progetti Software
“26% di progetti software terminano con successo”
Standish Group, CHAOS Report, 2000
“… cioè il 74% falliscono”
Standish Group, CHAOS Report, 2000
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
Tom 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
Costi
… in 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%)
Definizione
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”
… un’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”
Fred 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.”
Breve storia
• 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)
Requisiti 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
Tipi 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
Probelmi 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.
Un 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.
Determinazione 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
Raccolta 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
Metodi di raccolta requisiti
• Tradizionali
–
–
–
–
Analizzziamoli
Interviste
Questionari
Osservazioni
Studio dei docuemnti e dei sistemi software
• Metodi moderni
– Prototipi
– Sviluppo cooperativo delle applicazioni
– Sviluppo rapido delle applicazioni
Interviste
• 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)
Interviste
• 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)
Doamnde 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
Questionari
• 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
Osservazioni
• 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
Studio dei documenti e
dei 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
Negoziazione 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
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
Priorità 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
Modellizzazione dei casi d’uso
(UML - Unified Modeling Language)
• Attori: venditore, cliente e magazzino
QuickTime™ and a
TIFF (LZW) decompressor
are needed to see this picture.
Casi 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
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
Acquisti online
Assegnazione dei requisiti ad attori e casi d’uso
Caso d’uso
Requisito
Attore
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
R6
Cliente, Venditore
R7
Venditore, Magazzino
Informare magazzino su ordine
Ordinare computer configurato, aggiornare stato
ordine
Stampare fattura
Casi d’uso
QuickTime™ and a
TIFF (LZW) decompressor
are needed to see this picture.
Diagramma dei casi d’uso
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
QuickTime™ and a
TIFF (LZW) decompressor
are needed to see this picture.
<<extend>>
Altri esempi
QuickTime™ and
a
<<include>>
TIFF (LZW) decompressor
are needed to see this picture.
Inserire Piano di Studi include sempre
Convalidare piano di studi: ogniqualvolta il
piano di studi è inserito, deve essere anche convalidato
… ancora
Generalizzazione: Il manager
Servizi clienti è un tipo di
Impiegato Servizi Cliente il
quale, a sua volta, è un tipo di
Impiegato
QuickTime™ and a
TIFF (LZW) decompressor
are needed to see this picture.
Documento dei requisiti
1. Premessa
1.1 Obiettivo e scopo del prdotto
1.2 Contesto di business
1.3 Stackeholders
1.4 Soluzioni preliminari
1.5 Sintesi del docuemnto
2. Servizi del sistema
2.1 Scopo del sistema
2.2 Requisiti funzionali
2.3 Requisiti non funzionali
3. Vincoli di sistema
3.1 Requisiti di interfaccia
3.2 Requisiti di presentazione
3.3 Requisiti di sicurezza
3.4 Requisiti operativi
3.5 Requisiti politici e legali
3.6 Altri vincoli
4. Aspetti progettuali
4.1 Problemi aperti
4.2 Programma preliminare
4.3 Previsione costi
Appendici
Glossario
Documenti e moduli di business
Riferimenti