Corso Ingegneria dei Requisiti

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

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

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

...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

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

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

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

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

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

...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

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

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

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

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

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

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

Corso Ingegneria dei Requisiti

by K-Tech Formazione on Sep 15, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 178

Statistics

Corso Ingegneria dei Requisiti — Presentation Transcript

http://www.k-tech.it	176
http://www.slideshare.net	2