APPLICAZIONI INFORMATICHE
i requisiti
applicazioni informatiche - ingegneria dei requisiti
1
Ingegneria dei Requisiti
applicazioni informatiche - ingegneria dei requisiti
2
Progetti Software
“26% di progetti software terminano con successo”
Standish Group, CHAOS Report, 2000
“… cioè il 74% fallisce”
Standish Group, CHAOS Report, 2000
Il 26% che vede la luce comunque ha 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
applicazioni informatiche - ingegneria dei requisiti
3
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
applicazioni informatiche - ingegneria dei requisiti
4
Costi
applicazioni informatiche - ingegneria dei requisiti
5
… 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%)
– Documentazione (36%)
– Test (35%)
applicazioni informatiche - ingegneria dei requisiti
6
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 R.E.”
• 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”
applicazioni informatiche - ingegneria dei requisiti
7
… un’altra definizione
• L’ingegneria dei requisiti è:
“Lo sviluppo e l’uso di tecnologie per raccogliere,
specificare e analizzare i requisiti degli utenti/clienti che
saranno poi realizzati da un sistema software”
applicazioni informatiche - ingegneria dei requisiti
8
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.”
applicazioni informatiche - ingegneria dei requisiti
9
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 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 browser web.
– Il sistema dovrà gestire almeno 20 transazioni per
secondo
– Il sistema dovrà essere accessibile attraverso l’uso
di password
applicazioni informatiche - ingegneria dei requisiti
10
Tipi di requisiti
•
•
•
•
Requisiti Funzionali: definiscono parte delle
funzionalità 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
applicazioni informatiche - ingegneria dei requisiti
11
Tipi di requisiti
•
Requisiti non funzionali
– Esprimono vincoli sotto i quali il software dovrà
operare
– Possono essere visti come qualità specifiche che il
software dovrà avere
•
•
•
•
•
Costi
Sicurezza
Robustezza
Portabilità
Requisiti -1
– Condizioni che non si devono mai verificare
– Solitamente associate a requisiti non funzionali
applicazioni informatiche - ingegneria dei requisiti
12
Problemi legati ai requisiti
• I requisiti non riflettono i reali bisogni dei clienti
• I requisiti 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 analizzato i requisiti,
– tra chi ha raccolto i requisiti e il progettista,
– tra il progettista e chi realizzerà il sistema.
applicazioni informatiche - ingegneria dei requisiti
13
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.
• Non possiamo scrivere requisiti universali, ma
possiamo tentare di essere il più possibile
completi.
applicazioni informatiche - ingegneria dei requisiti
14
Determinazione dei requisiti
• Fornire una definizione informale dei requisiti
• 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 rinegoziazione dei requisiti
• Documento dei requisiti
applicazioni informatiche - ingegneria dei requisiti
15
Raccolta o negoziazione dei requisiti
•
•
•
•
Discussione con clienti e esperti del dominio
Esperti del dominio  conoscenza del dominio
Clienti  requisiti
Casi d’uso e conoscenza del domino devono essere
integrati
applicazioni informatiche - ingegneria dei requisiti
16
Metodi di raccolta requisiti
• Tradizionali
– Interviste
Analizziamoli
– Questionari
– Osservazioni
– Studio dei documenti e dei sistemi software
• Metodi moderni
– Prototipi
– Sviluppo cooperativo delle applicazioni
– Sviluppo rapido delle applicazioni
applicazioni informatiche - ingegneria dei requisiti
17
Interviste
• Condotte principalmente 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)
applicazioni informatiche - ingegneria dei requisiti
18
Interviste
• Strutturate
– Preparate in anticipo
– Un’agenda
– Domande predeterminate (aperte o chiuse)
– Sono generalmente 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)
applicazioni informatiche - ingegneria dei requisiti
19
Domande da evitare
• Domande sulle quali l’intervistatore esprime
(direttamente 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 è chiaramente
espressa
– non intendi fare questo, vero?
• Domande contenenti già la risposta
– devi fare le cose in questo modo, non è vero?
Importante è ascoltare
applicazioni informatiche - ingegneria dei requisiti
20
Questionari
• In aggiunta alle interviste
– Sostituiscono le interviste quando il progetto è a
basso rischio con obiettivi ben definiti
• Non è possibile chiedere chiarimenti sui quesiti e le
risposte
– Vantaggi: tempo per valutare la risposta, anonimato
– Svantaggi: non c’è la possibilità di discutere e
approfondire i quesiti
applicazioni informatiche - ingegneria dei requisiti
21
Questionari
• I quesiti dovrebbero essere chiusi (evitare i quesiti
aperti)
• Tre tipi:
– A scelta multipla
– A punteggio
– Con ordinamento
applicazioni informatiche - ingegneria dei requisiti
22
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
diversamente quando osservate
applicazioni informatiche - ingegneria dei requisiti
23
Studio dei documenti e dei sistemi software
• ….. per approfondire la conoscenza di dominio
• Documenti organizzativi:
– modulistica 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.
applicazioni informatiche - ingegneria dei requisiti
24
Studio dei documenti e dei sistemi software
• Moduli e rapporti di sistema: schermate e rapporti
computerizzati (con la relativa documentazione),
manuali operativi di sistema, documentazione utente,
documentazione tecnica, modelli di analisi di
progetto, ecc.
• Libri, riviste, pacchetti proprietari (sistemi ERP) internet
applicazioni informatiche - ingegneria dei requisiti
25
Negoziazione e validazione
• In parallelo alla raccolta dei requisiti
• Validazione e negoziazione fatta sul documento dei
requisiti (acquisiti)
• Revisione del documento
– Requisiti fuori dal contesto
– Matrice di dipendenza dei requisiti
– Priorità e rischi associati ai requisiti
applicazioni informatiche - ingegneria dei requisiti
26
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 eliminare le sovrapposizioni
applicazioni informatiche - ingegneria dei requisiti
27
Goal Analisys
la goal analysis è una tecnica che aiuta il
progettista a focalizzarsi sugli obiettivi che un
sistema software deve raggiungere, e fornisce i
mezzi per raffinare questi obiettivi, esplorando
più soluzioni alternative
applicazioni informatiche - ingegneria dei requisiti
28
Goal Analisys
1.
2.
3.
si definiscono gli obiettivi
si definiscono le strategie per raggiungerli
l’analisi comparativa tra le strategie porta ad
scelta che deve essere condivisa
applicazioni informatiche - ingegneria dei requisiti
29
Goal Analisys
• What
• Why
• How
QUALI obiettivi si devono portare a
compimento in questo passo?
PERCHE’ questi obiettivi?
COME vengono eseguiti questi obiettivi?
applicazioni informatiche - ingegneria dei requisiti
30
Priorità e rischi associati ai requisiti
• Analisi del rischio: identifica i requisiti che potrebbero
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 la ritaratura del
progetto rispetto ai ritardi (es. scaricando i requisiti
con bassa priorità per rispettare tempi di progetto).
• Le priorità devono essere negoziate con gli utenti
tendo conto dei fattori di rischio
applicazioni informatiche - ingegneria dei requisiti
31
Acquisti on line
• Un esempio di definizione dei requisiti
applicazioni informatiche - ingegneria dei requisiti
32
Acquisti online – “raccolta” dei 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
applicazioni informatiche - ingegneria dei requisiti
33
Acquisti online - strutturazione dei requisiti
Requisito
Attore
Attività
R1
Cliente
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
applicazioni informatiche - ingegneria dei requisiti
34
Acquisti online - documento dei requisiti
1. Premessa
Appendici
1.1 Obiettivo e scopo del prodotto
1.2 Contesto di business
1.3 Stackeholders
1.4 Soluzioni preliminari
1.5 Sintesi del documento
Glossario
Documenti e moduli di business
Riferimenti
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
applicazioni informatiche - ingegneria dei requisiti
35
Acquisti online - negoziazione dei requisiti
• Ma non è meglio verificare la disponibilità a magazzino
prima che il cliente completi l’ordine?
• Ma sei proprio sicuro che ti serva …
• Ma non sarà che il tuo cliente potrebbe …
• Ma non succede mai che l’ordine arriva in questo modo …
applicazioni informatiche - ingegneria dei requisiti
36
Requisiti
• Il primo problema …
• Un bel problema …
• Forse … IL PROBLEMA !
applicazioni informatiche - ingegneria dei requisiti
37