I partecipanti al corso Ingegneria dei Requisiti di K-Tech (http://www.k-tech.it), si confronteranno con il processo mentale durante la raccolta dei requisiti e i problemi legati al linguaggio. Comprenderanno cosa sono i requisiti di un progetto e il loro ruolo. Impareranno a riconoscere gli errori più comuni nella loro rilevazione. Faranno propri il concetto di glossario e le definizioni internazionali. Il corso Ingegneria dei Requisiti è articolato in nove moduli: 1. Il problema: premessa dell'ingegneria dei requisiti 2. I requisiti 3. Il processo 4. L'analisi 5. Lo studio di fattibilità di un sistema 6. Il glossario 7. Il documento di specifica (SRS) 8. I casi d'uso 9. La gestione dei requisiti Leggi il programma completo: http://www.k-tech.it/formazione/catalogo/corso_ingegneria_dei_requisiti

1. Corso
Ingegneria dei Requisiti
Modulo 2: I Requisiti
Leggi il programma completo del corso
www.javaportal.it | www.k-tech.it corsi@k-tech.it

2. Agenda
Cap 1 - Il problema
►Cap 2 - I requisiti ◄
Cap 3 - L'ingegneria dei requisiti
Cap 4 - L'analisi
Cap 5 - Lo Studio di fattibilità
Cap 6 - Il glossario
Cap 7 – Il documento di specifica (SRS)
Cap 8 – I casi d'uso
Cap 9 - La gestione
www.javaportal.it | www.k-tech.it corsi@k-tech.it 2

3. Definizioni...
● Qualità, dote o condizione necessaria per poter accedere o aspirare
a una carica, sostenere un esame e sim.: possiede tutti i requisiti per
diventare un bravo medico;...
La Garzanti
● Caratteristica, qualità, titolo o condizione richiesta per raggiungere un
determinato scopo: non possedere i requisiti adatti.
De Mauro
● Ciascuno dei caratteri o degli elementi che costituiscono il modello
astratto, individuato dalla legge, di un atto giuridico, la mancanza di
uno dei quali determina l’invalidità o l’inefficacia dell’atto stesso.
De Mauro
www.javaportal.it | www.k-tech.it corsi@k-tech.it 3

4. ...Definizioni
● I requisiti sono la descrizione dei servizi forniti dal sistema e dei suoi i
vincoli operativi.
● Una condizione o capacità che deve essere verificata o posseduta da
un sistema o un componente di un sistema per soddisfare un
contratto, uno standard, una specifica o qualsiasi altro documento
formalmente specificato. L'insieme di tutti i requisiti formano la base
del successivo sviluppo del sistema o del componente.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 4

5. Definizioni: IEE830
Secondo gli standard “IEEE 830” un requisito deve essere:
● corretto: deve descrivere che cosa vuole lo stakeholder.
● non ambiguo: deve essere soggetto ad una sola possibile interpretazione .
● completo (nell'insieme) : un insieme di requisiti è completo se e solo se descrive
tutti i requisiti significativi per l'utente, inclusi quelli che riguardano le funzionalità, le
performance, i vincoli di disegno, i dati o le interfacce esterne.
● consistente: non deve essere in conflitto con altri requisiti.
● classificato: deve riportare l'importanza per l'utente (grado di soddisfazione del
cliente nel caso in cui il requisito venga implementato con successo) e il grado di
stabilità (un indicatore della probabilità con cui il requisito cambierà in futuro).
● verificabile: deve essere possibile verificare la rispondenza del prodotto al requisito .
● modificabile: deve essere possibile effettuare modifiche al requisito in modo
semplice, completo e coerente.
● tracciabile: deve essere chiara l'origine del requisito, deve essere inoltre possibile
definire una corrispondenza tra il requisito e altri requisiti e tra il requisito e i prodotti
dello sviluppo.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 5

6. Definizioni: NASA SRS
● completo:
● consistente:
● modificabile:
● classificato:
● verificabile:
● tracciabile:
● non ambiguo:
● valido: un SRS è valido solo se tutti i partecipanti al progetto lo possono capire,
analizzare, accettare, o approvare. Questo è uno dei motivi principali per cui il SRS è
scritto usando il linguaggio naturale.
● accurato: un SRS descrive le capacità del sistema nel mondo reale come si
interfaccia e interagisce con esso.
● testabile: un SRS deve essere scritto in maniera tale che i test di verifica possano
essere derivati dallo SRS stesso.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 6

7. IEE 830: Corretto
“Un SRS è corretto se e solo se, ogni requisito ivi indicato è quello
che il software deve soddisfare.”
Non esiste nessun tool o procedura che assicura la correttezza.
L’SRS dovrebbe essere confrontato con qualche specifica superiore,
come la specifica dei requisiti del sistema, altra documentazione di
progetto, standard applicabili, ecc…
Ogni requisito rappresenta fedelmente nel sistema finale qualcosa che è
stato richiesto
www.javaportal.it | www.k-tech.it corsi@k-tech.it 7

8. IEEE 830: Non ambiguo
Un SRS è “NON AMBIGUO” se, e solo se, ogni requisito ivi indicato ha
solo una interpretazione.
In particolare:
1. ciò richiede che ogni caratteristica del prodotto finale sia descritta con
un unico termine.
2. nei casi in cui un termine usato in un particolare contesto, potrebbe
avere più significati, il termine deve essere incluso in un glossario in
cui è fatto il suo significato più specifico.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 8

9. IEEE 830: Completo...
Un SRS è completo se si possiede le seguenti caratteristiche:
1. l'inserimento di tutte le esigenze, sia in materia di funzionalità,
prestazioni, design vincoli, attributi o interfacce esterne.
2. definizione delle risposte del software a tutte le classi di dati in
ingresso in tutte le situazioni di realizzo. E' importante specificare le
risposte valide e non valide per valori di ingresso.
3. l'etichettatura completa ed i riferimenti di tutti i dati, tabelle e
diagrammi in SRS e definizione di tutti i termini e le unità di misura.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 9

10. ...IEEE 830: Completo
Qualsiasi SRS che utilizza l'espressione
... TBD (da determinare) ...
non è un SRS completo. Se è necessario, l'espressione deve essere corredata
da:
1. una descrizione delle condizioni che causano la TBD (per esempio, perché
una risposta non è nota), in modo che la situazione possa essere risolta.
2. una descrizione di ciò che deve essere fatto per eliminare il TBD.
Un documento di progetto basato su un SRS che contiene TBDs, dovrebbe:
● identificare la versione o lo specifico numero di release del SRS associato
con il particolare documento
● escludere noiose commissioni dipendenti da sezioni dell’SRS che sono
ancora identificate come TBDs.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 10

11. IEEE 830: Verificabile
Un SRS è verificabile se e solo se ogni requisito ad esso collegato è
verificabile .
Un requisito è verificabile se e solo se esiste un processo di verifica del
rapporto costo-efficacia con il quale una persona o una macchina può
verificare che il software prodotto soddisfa i requisiti
Un requisito per il quale non si riesce a elaborare un metodo che
determini se il software risponde alla sua particolare esigenza, deve
essere rimosso o rivisto.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 11

12. IEEE 830: Consistente
La consistenza si riferisce alla coerenza interna.
Un SRS è coerente se e solo se non vi siano singoli requisiti in conflitto.
Ci sono tre tipi di probabili conflitti in un SRS:
1. due o più requisiti potrebbero descrivere lo stesso oggetto del mondo
reale, ma usando diversi termini per gli stessi oggetti.
2. la specifica caratteristica di un oggetto nel mondo reale potrebbe
essere in conflitto.
3. vi potrebbe essere un conflitto logico o temporale tra due azioni
specificate.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 12

13. IEEE 830: Modificabile
Un SRS è modificabile se e solo se la sua struttura e lo stile sono tali che
tutte le modifiche necessarie alle esigenze può essere fatto facilmente,
completamente e coerentemente. Perché ciò sia possibile si richiede che
un SRS deve:
● disporre di un sistema organizzato, di facile utilizzo, con una tabella
dei contenuti, un indice, ed espliciti riferimenti incrociati;
● non deve essere ridondante;
● quando la ridondanza è necessaria, l'SRS dovrebbe includere
esplicitamente i riferimenti incrociati che ne facilitano la modificabilità.
● deve essere “Espresso” separatamente, piuttosto che incluso in altri
requisiti.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 13

14. IEEE 830: Tracciabile
Un SRS è rintracciabile, se è tracciata l'origine di ciascuno dei suoi
requisiti e, se è chiaro che, in futuro, faciliterà il referenziamento del
requisito per lo sviluppo o per il potenziamento della documentazione.
Due tipi di tracciabilità sono raccomandati:
1. tracciabilità backward: Ogni requisito esplicita la sua fonte di
riferimento in precedenti documenti.
2. tracciabilità forward: ogni requisito deve avere un nome univoco o un
numero di riferimento.
www.javaportal.it | www.k-tech.it corsi@k-tech.it 14

15. Domande...
www.javaportal.it | www.k-tech.it corsi@k-tech.it 15

16. BREAK
Dopo la pausa:
Altri principi OOP
Leggi il programma completo del corso
www.javaportal.it | www.k-tech.it corsi@k-tech.it 16