forked from ggiuffre/sweki
-
Notifications
You must be signed in to change notification settings - Fork 3
/
06_ingreqq.html
129 lines (113 loc) · 10.3 KB
/
06_ingreqq.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="it" lang="it">
<head>
<title>Ingegneria dei requisiti - sweki</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="author" content="FIUP" />
<meta name="keywords" content="sweki, ingegneria, software, requisiti" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" type="text/css" href="main.css" />
<link rel="prev" href="05_adminproj.html" />
<link rel="next" href="07_progettazione.html" />
</head>
<body>
<div id="header">
<h1>
<a class="prev" title="prev" href="05_adminproj.html"><</a>
<a href="index.html"><acronym title="SoftWare Engineering wiKI">sweki</acronym></a>
<a class="next" title="next" href="07_progettazione.html">></a>
</h1>
<h2>la wiki di Ingegneria del Software</h2>
</div>
<div id="content">
<h1>Ingegneria dei requisiti</h1>
<h2>Requisito</h2>
<p>I requisiti di un sistema sono le descrizioni di cosa il sistema deve fare, cioè i servizi che offre e i vincoli sul suo funzionamento. Due definizioni un po' più formali sono:</p>
<ul>
<li>ponendoci dal punto di vista del bisogno, requisito è una condizione necessaria a un utente per risolvere un problema o raggiungere un obiettivo;</li>
<li>dal punto di vista della soluzione, invece, requisito è una condizione che dev'essere soddisfatta da un sistema per adempiere a un obbligo.</li>
</ul>
<p>I requisiti hanno a che vedere con il processo di sviluppo del software; tuttavia la loro gestione è qualcosa di costante, che viene iterato lungo <em>tutto</em> il ciclo di vita di un progetto.</p>
<h2>Requisiti utente e di sistema</h2>
<p>"Requisito" è un termine leggermente ambiguo, in quanto viene usato per indicare sia una richiesta generale (astratta, di alto livello) sia una definizione formale e dettagliata di una funzione del sistema. È bene separare questi differenti livelli di descrizione; per questo, distinguiamo tra requisiti utente (di alto livello) e requisiti di sistema (più dettagliati).</p>
<h2>Requisiti di prodotto e di processo</h2>
<p>È bene anche distinguere tra requisiti di prodotto (dei bisogni o dei vincoli sul software da sviluppare) e requisiti di processo (dei vincoli sullo sviluppo del software).</p>
<h2>Requisiti funzionali e non</h2>
<p>Un'ulteriore distinzione viene fatta tra:</p>
<ul>
<li>requisiti funzionali — i servizi che il sistema deve fornire (cioè la sua interfaccia);</li>
<li>requisiti non funzionali — i <em>vincoli</em> sui servizi che il sistema fornisce (requisiti su prestazioni, manutenibilità, sicurezza, affidabilità...).</li>
</ul>
<p>Ma tale distinzione non è sempre netta: ad esempio, il requisito di limitare l'accesso ai soli utenti autorizzati (apparentemente non funzionale) può essere sviluppato più in dettaglio fino a richiedere un servizio di autenticazione (requisito chiaramente funzionale)!</p>
<h2>Piano di qualifica</h2>
<p>Per garantire il rispetto dei requisiti entra in gioco il piano di qualifica, che consiste nel definire le strategie di <strong>verifica</strong> e scegliere metodi, tecniche e procedure da usare per la <strong>validazione</strong>; ha quindi a che fare con due processi:</p>
<ul>
<li>Verifica: accertare che l'esecuzione delle attività di processo non abbia introdotto errori (<q>Did I build the system right?</q>). È rivolta ai processi ma viene svolta sui loro prodotti; accerta il rispetto di norme e procedure.</li>
<li>Validazione: accertare che il prodotto realizzato corrisponda alle attese (<q>Did I build the right system?</q>). È rivolta ai prodotti finali.</li>
</ul>
<p>La validazione dev'essere una <em xml:lang="en">self fulfilling prophecy</em>, cioè bisogna essere certi che non fallirà; la verifica serve proprio a garantire questo. Infatti, il processo di verifica deve assicurarci che lavoriamo bene non <span xml:lang="la">a posteriori</span> ma <em>mentre</em> lavoriamo. Se la verifica assicura i requisiti, la validazione li accerta. Il piano di qualifica nasce assieme ai requisiti.</p>
<p>Potremmo dire che se la validazione è una dimostrazione matematica, la verifica assomiglia più a una prova sperimentale.<!-- idea mia, forse sbagliata --></p>
<h2>Attività</h2>
<p>Il processo di ingegneria dei requisiti raggruppa quattro attività:</p>
<ol>
<li><strong>studio di fattibilità</strong> (stabilire se il sistema in questione è redditizio);</li>
<li>acquisizione<sup class="footnote"><a id="txt1" href="#ftn1">[1]</a></sup> e <strong>analisi</strong> dei requisiti;</li>
<li><strong>specifica</strong> dei requisiti (cioè formalizzare i requisiti e riportarli in un documento);</li>
<li><strong>validazione</strong> dei requisiti.</li>
</ol>
<p>Tale processo riguarda tutti gli <em xml:lang="en">stakeholder</em>. In genere non è possibile soddisfare i requisiti di ognuno di essi, quindi bisogna trovare un buon compromesso; questo presuppone che gli <em xml:lang="en">stakeholder</em> vengano identificati, "pesati" e interpellati.</p>
<h2>Studio di fattibilità</h2>
<p>Lo studio di fattibilità è uno studio breve e chiaro che consiste nel valutare <strong>rischi</strong>, <strong>costi</strong> e <strong>benefici</strong> legati al sistema da sviluppare: tale sistema contribuisce agli obiettivi generali dell'organizzazione? può essere sviluppato rispettando determinati vincoli economici, con la tecnologia corrente? può essere integrato con altri sistemi in uso? una risposta negativa in una qualunque tra queste domande inficia la fattibilità del sistema. Lo studio di fattibilità dovrebbe descrivere in modo chiaro gli <strong>obiettivi</strong> del progetto e valutare approcci alternativi, per capire se il progetto proposto è la migliore alternativa.</p>
<h2>Acquisizione e analisi dei requisiti</h2>
<p>Dopo aver compiuto uno studio di fattibilità, gli analisti devono lavorare assieme a clienti e utenti per individuare il dominio di applicazione e i requisiti del sistema. In generale, tutti gli <em xml:lang="en">stakeholder</em> sono coinvolti in questa attività, che prende il nome di "acquisizione e analisi dei requisiti" e si svolge a grandi linee nel seguente modo:</p>
<ol>
<li>Studio dei bisogni e delle fonti; si cerca di individuare un insieme (non strutturato) di requisiti. Per fare questo, si può:
<ul>
<li>interrogare gli <em xml:lang="en">stakeholder</em> — con interviste chiuse (insieme predefinito di domande) o aperte;</li>
<li>discutere con gli <em xml:lang="en">stakeholder</em> alcuni scenari del sistema (uno scenario è la descrizione di un esempio di interazione col sistema);</li>
<li>discutere con gli <em xml:lang="en">stakeholder</em> i casi d'uso del sistema (tramite diagrammi che individuino le interazioni tra il sistema e i suoi utenti);</li>
<li>studiare un prototipo del sistema;</li>
<li>discutere in modo creativo, tramite <em xml:lang="en">brainstorming</em>;</li>
<li>osservare il sistema in modo etnografico, immergendosi nel suo funzionamento abituale.</li>
</ul>
Interviste e scenari (oltre al capitolato d'appalto, chiaramente) sono fonte di <strong>requisiti espliciti</strong>; per ricavare, invece, i <strong>requisiti impliciti</strong>, gli analisti devono capire il dominio di applicazione del sistema (magari creando un glossario dei termini chiave del dominio).
</li>
<li>Classificazione e organizzazione dei requisiti; l'insieme dei requisiti viene strutturato, dividendo i requisiti in gruppi che rispecchino l'architettura del software (qui, progettazione e analisi procedono spesso insieme).</li>
<li>Modellazione concettuale del sistema (ad esempio tramite diagrammi dei casi d'uso).</li>
<li>Assegnazione dei requisiti a parti distinte del sistema.</li>
<li>Negoziazione con il committente e con i sotto-fornitori: essendoci diversi <em xml:lang="en">stakeholder</em>, è normale che alcuni requisiti siano in conflitto; bisogna dare una priorità ad ogni requisito e negoziare quelli incompatibili, per trovare un compromesso.</li>
</ol>
<p>I requisiti possono cambiare (a causa di condizioni esterne o anche solo perché un'analisi approfondita ha introdotto nuovi requisiti). Proprio per questo, è bene notare che la sequenza di passi che abbiamo riportato diventa spesso un ciclo che si ripete.</p>
<h2>Specifica dei requisiti</h2> <!-- [...!] -->
<p>I requisiti vanno specificati in un documento, usando un linguaggio formale e/o grafico. Vanno ordinati per priorità, classificati e identificati univocamente.</p>
<p>Lo standard <abbr title="Institute of Electrical and Electronics Engineers">IEEE</abbr> 830-1998 raccomanda che la specifica dei requisiti sia:</p>
<ul>
<li>priva di ambiguità</li>
<li>corretta</li>
<li>completa</li>
<li>verificabile</li>
<li>coerente</li>
<li>modificabile</li>
<li>tracciabile</li>
<li>ordinata per rilevanza dei requisiti</li>
</ul>
<p>Lo stesso standard raccomanda, inoltre, che il documento di Analisi dei Requisiti (<em xml:lang="en">Software Requirements Specification</em>) rechi un'introduzione (con scopo del documento, scopo del prodotto, glossario, riferimenti, struttura del documento) e contenga una descrizione generale (con prospettive del prodotto, sue funzioni, caratteristiche degli utenti, vincoli generali, assunzioni e dipendenze).</p>
<h2>Validazione dei requisiti</h2>
<p>Validare i requisiti vuol dire controllare che essi definiscano effettivamente il sistema che il cliente richiede. A partire dal documento generato durante la specifica dei requisiti, bisogna assicurarsi che questi siano:</p>
<ul>
<li>non ambigui;</li>
<li>necessari — ogni requisito deve soddisfare qualche bisogno esplicito (dal capitolato di appalto);</li>
<li>sufficienti — ogni bisogno dev'essere soddisfatto da qualche requisito del documento;</li>
<li>coerenti;</li>
<li>realistici — i requisiti devono essere implementabili con la tecnologia a disposizione;</li>
<li>verificabili — si dovrà essere in grado di dimostrare che il sistema soddisfa i requisiti.</li>
</ul>
</div>
<div id="footnotes">
<ol>
<li id="ftn1"><em xml:lang="en">Requirements elicitation</em>.</li>
</ol>
</div>
</body>
</html>