Analisi dei Requisiti e Definizione delle Specifiche

Transcript

1 e Definizione delle Specifiche Scopi della fase Processo di specifica dei requisiti Analisi del problema Specifica dei requisiti Caratteristiche dell SRS la Validazione delle specifiche 1 Analisi e Specifica dei Requisiti Scopi della fase: Definizione di funzioni, vincoli, prestazioni, interfacce e qualsiasi altra caratteristica che il sistema dovrà possedere per soddisfare le necessità del cliente Redazione di un Documento di Specifica dei Requisiti Software, che sia completo, preciso, consistente, non ambiguo, comprensibile sia al committente che allo sviluppatore Predisposizione di un piano di test e della versione 0 del manuale utente N.B. Definizione di COSA il sistema dovrà fare senza descrivere COME 2 1

2 La necessità di un SRS Un SRS (documento di Specifica dei Requisiti Software) costituisce il punto di convergenza di tre diversi punti di vista: cliente, utente, sviluppatore Un SRS fornisce un punto di riferimento per la validazione del prodotto finale Un SRS di qualità è il pre-requisito per un software di alta qualità un errore nell SRS produrrà errori nel sistema finale Un SRS di qualità riduce i costi di sviluppo correggere un errore dell SRS dopo lo sviluppo costa 100 volte più che correggerlo durante la fase di Analisi FASE COSTO (in ore uomo) 2 Progettazione 5 Codifica 15 Test di accettazione 50 Esercizio e manutenzione Il Processo di specifica dei Requisiti Analisi del problema: Partendo da una generale definizione delle necessità dei potenziali utenti, comprendere: il problema, le condizioni di risoluzione ed i vincoli. Lo scopo è di comprendere cosa deve fare il sistema software che si vuole costruire. Specifica dei requisiti trasformazione dei requisiti in un documento di specifiche tecniche e funzionali caratterizzanti il sistema Validazione delle specifiche le specifiche, formalizzate, vengono riviste con l utente/ committente per validarle 4 2

3 Il Processo di specifica dei Requisiti Bisogni utente Analisi del Problema Definizione Specifiche Validazione Processo con feedback fra le attività Durante l analisi: decomporre il problema in più parti e relative relazioni uso di modelli per rappresentare le informazioni raccolte (DFD, Object,) Transizione da analisi a specifica: non immediata, giacchè l analisi fissa la struttura del problema, mentre la specifica definisce il comportamento esterno del sistema 5 L Analisi del Problema ottenere una chiara comprensione delle necessità del committente/utente, cosa è desiderato dal sistema Sw, quali i vincoli da assumere comprensione del dominio applicativo dal punto di vista del committente/utente e del comportamento esterno individuazione degli elementi che lo compongono attività svolte informazioni trattate e delle relazioni esistenti tra essi il principio del partizionamento può essere applicato sia rispetto agli oggetti che alle funzioni del dominio applicativo può basarsi su una rappresentazione (modello) del dominio applicativo 6 3

4 Approcci all analisi dei requisiti Approccio informale nessun modello formale del sistema viene costruito la raccolta di informazioni sul sistema è ottenuta grazie ad interazioni dell analista col cliente e l utente finale, l uso di questionari, studio di documentazione esistente, si procede attraverso la formulazione e il raffinamento di vari SRS che sono sottoposti alla validazione nell ambito di opportuni meeting Approccio basato su modelli concettuali del problema produce rappresentazioni formali del problema Approccio basato sulla prototipazione il problema viene analizzato ed i requisiti sono compresi grazie all uso di un prototipo del sistema da parte di cliente ed utenti 7 Alcuni approcci basati su modelli concettuali La tecnica dell Analisi Strutturata basata sull uso di Data Flow Diagrams e Dizionario dei Dati l analisi del problema viene eseguita usando l approccio della decomposizione delle funzioni Analisi Object-Oriented l analisi del problema viene eseguita usando l approccio della decomposizione in oggetti (entità/ concetti del dominio del problema) Modello Entità- Relazioni per modellare i dati e le relative relazioni usato per progettare database 8 4

5 La Specifica dei Requisiti La fase di analisi non definisce tutti gli aspetti del software quali: interfacce utente, gestione dei casi di errorre, vincoli di prestazioni, di progettazione, aderenza agli standard, pertanto La conoscenza acquisita nella fase di analisi dovrà essere tradotta nella Specifica dei requisiti la traduzione non è immediata Quali caratteristiche di qualità dovrà possedere un buon SRS? 9 Le caratteristiche di un buon SRS... Corretto se ogni requisito presente nell SRS è realmente richiesto al sistema finale Completo se ogni funzione richiesta al software ed il suo comportamento rispetto ad ogni possibile input è specificato Non Ambiguo ogni requisito ha una sola interpretazione (formale vs. informale) Verificabile se è possibile verificare che il sistema realizzi ogni requisito (richiede la non ambiguità dei requisiti) 10 5

6 le caratteristiche di un buon SRS Consistente se nessun requisito è in contraddizione con gli altri Modificabile se la struttura e lo stile dell SRS sono tali da consentire facili modifiche, preservando consistenza e completezza (un SRS con ridondanze non si modifica facilmente) Tracciabile se l origine di ciascun requisito è chiara e può essere referenziata nello sviluppo futuro (def. IEEE) forward traceability: requisito collegabile a qualche elemento del progetto e del codice backward traceability: dal progetto e dal codice è possibile risalire al requisito corrispondente 11 Le parti fondamentali di un SRS Requisiti Funzionali la specifica di quali output sono prodotti dal sistema rispetto a dati input e la logica (non l algoritmo) con cui gli output sono ottenuti. Inoltre il range di input validi, il comportamento rispetto ad input/output non validi, Requisiti sulle Prestazioni statiche:# terminali, #utenti simultanei, # file da processare dinamiche: tempi di risposta, throughput Vincoli di progettazione standard da seguire, limiti nelle risorse hardware/ software impiegate, ambiente operativo, affidabilità, sicurezza Requisiti sulle Interfacce esterne la specifica delle modalità con cui il software interagisce con l utente, hardware ed altro software 12 6

7 Linguaggi per la Specifica informali: le specifiche del sistema sono descritte in linguaggio naturale formali: la specifica è un oggetto formale rappresentata in una notazione definita in modo rigoroso sul piano sintattico e semantico semiformali: si collocano in una posizione intermedia fra i due estremi; utilizzano, in genere, notazioni grafiche, con semantica poco formalizzata; sono di facile interpretazione; non consentono, o almeno riducono, interpretazioni ambigue; sono accompagnate da descrizioni in linguaggio naturale I modelli semiformali sono allo stato dell arte i più flessibili ed i più usati 13 Struttura dell SRS (IEEE94) Table of contents 1.Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, Acronyms and Abbreviations 1.4. References 1.5. Overview 2.General Description 2.1. Product Perspective 2.2. Product Functions 2.3. User Characteristics 2.4. General Constraints 2.5. Assumptions and Dependencies 3.Specific Requirements 3.1. Functional Requirements Functional Requirement Introduction Inputs Processing Output Functional Requiremtnt Functional Requirement n 3.2. External Interface Requirements User Interfaces Hardware Interfaces Software Interfaces Communications Interfaces 3.3. Performances Requirements 3.4. Design Constraints Standard Compliance Hardware Limitation 3.5. Attributes Security Maintenability 3.6. Other Requirements DATABASE Operati Site Adaptation 14 7

8 La Validazione delle Specifiche L obiettivo è quello di assicurare che l SRS rifletta accuratamente e con chiarezza i requisiti effettivamente richiesti al software Tipi di errori riscontrabili in un SRS Omissione (mancata presenza di un requisito) Inconsistenza (contraddizione fra i vari requisiti o dei requisiti rispetto all ambiente operativo) Incorrettezza (fatti non corretti nell SRS) Ambiguità (requisiti con significati multipli) Le tecniche di validazione devono puntare su tali errori 15 Tecniche di validazione di un SRS Revisioni ed ispezioni manuali le tecniche più efficienti per la individuazione di errori/ difetti partecipano alle riunioni di revisione l autore dell SRS, il cliente, un progettista, un esperto di qualità ogni partecipante rivede l SRS prima della riunione uso di checklist durante l ispezione Tecnica di Reading qualcuno diverso dall autore legge l SRS per coglierne potenziali problemi (ambiguità, ) Uso di Scenari relativi alle varie modalità operative del sistema 16 8

9 Un esempio di SRS - Il sistema di scheduling dei corsi (v. Jalote) Il Problema: un Dipartimento universitario offre vari corsi per ogni semestre (due tipi di corsi: Post GraduatePG e Under Graduate UG), che vengono schedulati nelle aule del dipartimento usando gli orari a disposizione. In partenza tale schedulazione è fatta a mano dal segretario del dipartimento il quale raccoglie le richieste su carta dei vari docenti con le relative preferenze di orario ed il numero di persone attese. I seguenti criteri vengono usati per la schedulazione: le richieste vengono servite nell ordine di arrivo i corsi PG hanno la precedenza sugli UG due corsi PG non possono essere schedulati negli stessi orari 17 L analisi del problema di scheduling dei corsi Docenti Raccolta moduli Moduli raccolti Schedula Schedulazione Docenti moduli Il modello DFD del sistema di schedulazione di partenza Il processo di schedulazione prevede la separazione dei moduli in tre pile, una per ogni tipo di corso, dopodichè sono schedulati prima i PG, poi gli UG e infine i restanti corsi senza preferenze Le aule sono assegnate con capienza sufficiente per il numero di studenti attesi ed una stessa aula non è mai assegnata a due corsi contemporaneamente 18 9

10 Il DFD del processo Schedulazione Moduli raccolti Separa Corsi UG Schedulazione parziale Schedula Schedula Schedula PG UG Corsi PG Schedulazione il resto parziale Schedulazione Corsi senza preferenza Moduli raccolti= [nome docente+ numero_corso+[preferenze]*]* Schedulazione= [corso+numero_classe+orario]* 19 Dall analisi verso le specifiche del sistema I corsi da schedulare con le relative preferenze dei docenti saranno composti in un file, unitamente ai corsi i cui docenti non hanno espresso preferenze Il formato del file è simile a quello usato in precedenza dal segretario Il sistema dovrà verificare la presenza di errori di formato nel file Lo schedulazione avverrà con le stesse regole precedenti, ed in più dovrà essere evitato che un corso UG con preferenza renda un corso PG senza preferenza non accontentabile Bisogna fornire una spiegazione per le preferenze che non si siano potute accontentare Le informazioni relative alle aule, gli orari, ed i corsi validi saranno registrate in un file 20 10

11 L SRS finale