Il webinar mostra una panoramica sulle più accreditate tecniche di scrittura e gestione dei requisiti per ottimizzarne la raccolta, la stesura e la condivisione.

1. I requisiti nello sviluppo
software
- leggi generali e varianti contestuali -
©Adriano Comai 2011
www.analisi-disegno.com

2. Adriano Comai
• Formazione umanistica, da 30 anni nello sviluppo software
• Consulenza per molte organizzazioni in Italia e all’estero
• Oltre 400 corsi e seminari su diversi aspetti dello sviluppo
• Decine di articoli pubblicati su riviste informatiche
• Guida “Requirements-by-Example”, con esempi di
requisiti ben specificati e indicazioni pratiche per gli
analisti, diffusa e usata in tutto il mondo
• Scaricabile, anche in versione italiana, dal mio sito
www.analisi-disegno.com
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 2

3. Centralità dei Requisiti
Acquisto
• di prodotti
• di servizi
Sviluppo
• di software
• di sistemi complessi (Hardware + Software)
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 3

4. Andamento dei progetti sw
Esito dei progetti
(fonte: The Standish Group, su un campione di migliaia di progetti internazionali)
Successo Parziale insuccesso Fallimento (cancellati,
(meno funzioni, più tempi e costi) o mai utilizzati)
2010 37% 42% 21%
2006 35% 46% 19%
1998 26% 46% 28%
1994 16% 53% 31%
• Il campione include aziende e pubblica amministrazione, ma non
software house o aziende di consulenza
• Percentuali di fallimento superiori per i progetti di dimensioni maggiori e
nelle grandi organizzazioni. Progetti con costo di risorse < $750.000
hanno una percentuale di successo del 73% (dato 2006)
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 4

5. Perché i progetti falliscono
Requisiti incompleti 13,1%
Mancato coinvolgimento utente 12,4%
Mancanza risorse 10,6%
Attese irrealistiche 9,9%
Mancanza supporto direzione 9,3%
Cambiamento requisiti 8,7%
Mancanza pianificazione 8,1%
Non serviva più 7,5%
Carenze del Management IT 6,2%
Incompetenza sulle tecnologie 4,3%
Altro 9,9%
(fonte: The Standish Group)
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 5

6. Requisiti e prodotti …
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 6

7. Requisiti, componenti, test
componenti
sistema
esigenze
requisiti
stakeholders
test
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 7

8. Ruoli e requisiti
Architetto /
Committente Sviluppatore
Designer
Stakeholder
Responsabile Analista Tester
progetto
Gestore servizio
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 8

9. Attività per i requisiti
• Raccolta requisiti (gathering)
• Analisi requisiti (analysis)
• Gestione dei requisiti (management)
• Ingegneria dei requisiti (engineering)
• …
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 9

10. Requisiti?
Conoscenza
Comunicazione
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 10

11. Need goal requirement
Bisogni
Obiettivi
Requisiti
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 11

12. Cosa si vorrebbe
• che tutti i requisiti
siano già chiari alla
partenza del progetto
• che siano
completamente privi
di ambiguità, e
specifichino nel
dettaglio cosa dovrà
fare il sistema
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 12

13. La realtà:
i requisiti vanno scoperti
• usando tecniche (“arti”) efficaci ed efficienti
⇒…e parecchi emergeranno
solo quando il sistema verrà
effettivamente utilizzato
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 13

14. Esprimere requisiti è difficile
• Esprimere requisiti per evolvere e migliorare di un
sistema esistente è relativamente semplice
• Ma per qualcosa di nuovo, è molto più complesso
“Spesso, il modo migliore per scoprire requisiti che nessuno ancora
conosce è rilasciare il prodotto in modo incrementale.
Ogni volta che i clienti ricevono un rilascio tirano fuori decine di altre
funzioni che vorrebbero avere. È un dato di fatto che il numero di nuovi
requisiti pensati dai clienti è proporzionale al numero di requisiti già
soddisfatti.”
(Alan Davis 2005)
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 14

15. Legge:
Quanto è maggiore il livello di
innovazione, tanto più è difficile chiarire
i requisiti all'inizio del progetto.
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 15

16. Sprechi
Non tutti i requisiti hanno la stessa importanza
Mediamente:
• il 45% delle funzionalità di un sistema non viene mai
utilizzato
• il 19% viene utilizzato solo raramente
(fonte: Standish Group 2004)
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 16

17. Obiettivi del committente
Bisogni Obiettivi
derivano da una o più esigenze (“di business”),
alle quali il committente intende rispondere
con un cambiamento
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 17

18. Stakeholder (parti interessate)
• “dimenticare” uno o più stakeholder può risultare critico
per il successo del progetto
• il loro coinvolgimento nel progetto ha un costo, che va
valutato in termini di rischi / opportunità
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 18

19. Requisiti in conflitto
È normale che in un progetto vi siano requisiti in
conflitto:
• A causa di richieste troppo onerose a fronte di risorse
limitate (budget, tempi)
• o quando gli stakeholder hanno punti di vista
contrastanti
Il conflitto tra requisiti deve emergere il prima possibile
(per poterlo gestire con costi e in tempi contenuti).
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 19

20. Univocità del committente
• il committente è il principale decisore nel progetto…
• quindi deve essere unico, ed il suo ruolo deve essere noto a
tutte le parti interessate
• nel caso di progetti complessi, che coinvolgono numerose
aziende (o aree diverse della medesima azienda), il ruolo di
committente può essere attribuito a:
– un “delegato”
– un “comitato guida”
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 20

21. Incontrare le parti interessate
interviste e incontri vanno preparati con cura:
• per minimizzare i tempi necessari
• per massimizzare i risultati
interviste individuali incontri collettivi
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 21

22. Come scoprire i requisiti
strade complementari:
• interviste e incontri
• analisi di sistemi e/o procedure organizzative
preesistenti
• costruzione di prototipi
• identificazione e descrizione degli scenari di utilizzo del
sistema (casi d’uso)
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 22

23. Ruoli e requisiti
Architetto /
Committente Sviluppatore
Designer
Stakeholder
Responsabile Analista Tester
progetto
Gestore servizio
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 23

24. Legge:
I requisiti devono essere espressi (comunicati)
Variante:
Le modalità di espressione dei requisiti
dipendono al contesto in cui si opera
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 24

25. Criticità dei sistemi
Vita umana
Denaro
Immagine
Nessuna criticità
Tipicamente, diversi livelli di formalizzazione dei requisiti
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 25

26. Interlocutori e requisiti
Esigenza
Committente Realizzatore
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 26

27. Più interlocutori
Esigenza
Committente Analista
Esigenza
Esigenza
Realizzatore Designer
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 27

28. ©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 28

29. Legge:
Più ruoli intermedi esistono tra chi ha
l'esigenza e chi implementa, più sono le
comunicazioni da gestire.
Più queste comunicazioni avvengono in
sequenza e sono basate su documenti
formalizzati, più crescono i tempi di
realizzazione e i rischi di incomprensione.
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 29

30. Perché i requisiti cambiano
Tra i motivi più comuni:
• non ci si era capiti bene prima
• cambiamento di vincoli “esterni” (es. legislativi)
• cambiamento a livello di mercato (es. concorrenti con
prodotti dalle caratteristiche più innovative)
• cambiamento di scenari tecnologici (es. nuove
opportunità, tecnologie in declino)
• cambiamento di committente
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 30

31. Legge:
Il cambio di requisiti in corso d'opera è
una costante in ogni progetto non
elementare.
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 31

32. Legge:
Il cambio di requisiti in corso d'opera è
tanto più costoso quanto più tardi avviene.
Variante:
Il costo del cambiamento per i requisiti non
funzionali è di solito molto superiore a quello
per i requisiti funzionali.
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 32

33. Legge:
Maggiore il tempo che passa tra la
definizione del requisito e la verifica del
suo soddisfacimento, maggiori i rischi.
(il “congelamento dei requisiti” preoccupa molto i
committenti…)
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 33

34. Grazie per l’attenzione!
Per approfondimenti e altri materiali:
www.analisi-disegno.com
© Adriano Comai 2011
©Adriano Comai 2011 Requisiti: leggi e varianti Pag. 1 - 34