A3_2 V2.1 Analisi dei Requisiti e Specifica Tecniche e linguaggi Il contenuto del documento è liberamente utilizzabile dagli studenti, per studio personale e per supporto a lezioni universitarie. Ogni altro uso è riservato, e deve essere preventivamente autorizzato dall’ autore. Sono graditi commenti o suggerimenti per il miglioramento del materiale INGEGNERIA DEL SOFTWARE Paolo Salvaneschi Università di Bergamo Facoltà di Ingegneria
39
Embed
Analisi dei Requisiti e SpecificaTecniche di definizione di requisiti e specifiche • Interviste – Strutturate – Non strutturate – Utilizzo del registratore • Questionari
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
A3_2 V2.1
Analisi dei Requisiti e Specifica Tecniche e linguaggi
Il contenuto del documento è liberamente utilizzabile dagli studenti, per studio personale e per supporto a lezioni universitarie.Ogni altro uso è riservato, e deve essere preventivamente autorizzato dall’ autore.
Sono graditi commenti o suggerimenti per il miglioramento del materiale
INGEGNERIA DEL SOFTWARE
Paolo Salvaneschi
Università di BergamoFacoltà di Ingegneria
A3 - Requisiti Paolo Salvaneschi 2
• Tecniche di definizione di requisiti e specifiche
• Elenco strutturato• Scenari e Casi d’uso• Modelli per l’analisi• Prototipi• Forme linguistiche• Documentazione• Sintesi
INDICE
A3 - Requisiti Paolo Salvaneschi 3
Tecniche di definizione di requisiti e specifiche
• Interviste– Strutturate– Non strutturate– Utilizzo del registratore
• Questionari scritti• Osservazione di futuri utenti al lavoro• Studio di documenti• Studio di sistemi esistenti• Incontri periodici tra clienti e sviluppatori
A3 - Requisiti Paolo Salvaneschi 4
Tecniche di estrazione dei requisiti
• Risultato:
Elenco strutturato
Elenco di casi di uso / scenari
Modelli
completezza
Prototipi
A3 - Requisiti Paolo Salvaneschi 5
• Utilizzo strutturato del linguaggio naturale• Caratteristiche comuni:
– Presenza di uno schema– Identificazione di ogni requisito / specifica– Distinzione tra requisiti funzionali e non
funzionali
Elenco strutturato di requisiti
A3 - Requisiti Paolo Salvaneschi 6
CAM2 Gestione magazzino utensili
E’ gestito il data base degli utensili disponibili. Ogni utensile include un insieme di dati come ad esempio:
TipologiaParametri di lavoroControllo dei limiti di sicurezzaDimensione geometricaPosizione, correttore
CAM2.1 Gestione insiemi di utensili (kit)
Più utensili possono essere raggruppati in un insieme (ad esempio una sequenza di utensili usata per una definita lavorazione).E’ gestito il data base degli insiemi disponibili. Sono disponibili funzioni come ad esempio:
Classificazione degli insiemi per tipo di utilizzo;Ricerca;Modifica di un insieme di utensili attraverso opzioni di “escludi / includi di nuovo” da uninsieme senza modificare la lista degli utensili dell’insieme.
Esempio
Prodotto CAM /CAD per la lavorazione del vetro con macchine a controllo numericoRequisiti espressi in linguaggio naturale strutturato
A3 - Requisiti Paolo Salvaneschi 7
Sistema informativo territoriale comunale linguaggio naturale strutturato
Esempio
A3 - Requisiti Paolo Salvaneschi 8
Scenari e Casi d’uso
• Casi d’uso e scenari• Un caso d’uso cattura il comportamento di un
sistema come appare visto dall’esterno in uno specifico utilizzo da parte di un attore
• Un attore è un’entità esterna che interagisce con ilsistema
• Ogni caso può utilizzare più funzioni del sistema
A3 - Requisiti Paolo Salvaneschi 9
CASO D’USOEstendi il prestito Breve descrizione
Un utente desidera prolungare il periodo di prestito
AttoriUtente della biblioteca
PrecondizioniIl libro è già assegnato all’utente
Passi principaliControllare che nessuno l’abbia prenotatoControllare lo stato dell’utenteEstendere il prestito
Situazioni eccezionaliIl libro è già prenotato
PostcondizioniPrestito esteso, stato utente aggiornato
Prendi a prestito la
copia di un libro
Estendi il prestito
Restituisci la
copia di un libro
Utente della
biblioteca
Actor1
Scenari e Casi d’uso
A3 - Requisiti Paolo Salvaneschi 10
Scenari e Casi d’uso
• Casi d’uso e scenari• Utili quando la definizione di modelli è un
processo difficile• Problemi di integrazione tra i casi d’uso /
scenari• I requisiti non funzionali possono essere
proprietà del sistema e non dei singoli casi d’uso
A3 - Requisiti Paolo Salvaneschi 11
Lo sviluppo di un prodotto per il mercato (non per uno specifico cliente)
Non esiste un cliente da "confessare"Esiste una popolazione di possibili clientiEsistono dei prodotti concorrenti
Molti possibili insiemi di requisitiNecessità di priorità
SCENARI
Esempio
A3 - Requisiti Paolo Salvaneschi 12
I requisiti del prodotto software sono espressi utilizzando il concetto di SCENARIO DI UTILIZZO
• Uno scenario di utilizzo e’ un insieme di informazioni che descrivono, dal punto di vista dell’ utilizzatore, un utilizzo del sistema.
• Ci si può immaginare che uno scenario sia un racconto in cui un utente o un commerciale descrivono uno specifico insieme di funzionalità e modalità operative che vengono utilizzate per uno scopo definito e decorano il racconto con informazioni aggiuntive utili dal punto di vista del mercato come ad esempio l’ importanza che attribuiscono a questo insieme di funzionalità o la disponibilità delle stesse all’ interno dei prodotti della concorrenza.
• Uno scenario viene descritto in – Italiano;– Diagrammi di flusso dati– Reti di Petri;– …….
Esempio
A3 - Requisiti Paolo Salvaneschi 13
LISTA SCENARI
Nome Scenario Importanza Presente nella
versione attualePresente in
prodotti concorrenti
Pezzi semplici singoli (antine, parti di mobili per ufficio, ...)
4 si (User Interface parziale)
tutti
Pezzi con lavorazioni piane su facce canoniche (porte, finestre, ...)
4 si (UI parziale) tutti
Pezzi da lavorarsi a 4 assi (schienali di sedie, ..) 3 si XXXXXX Pezzi da lavorarsi a 5 assi (eliche, barche, ...) 3 minimo YYYYYY Pezzi piani digitalizzati 4 si
Esempio
A3 - Requisiti Paolo Salvaneschi 14
Nome scenario : Pezzi semplici singoli (antine, parti di mobili per ufficio, ...)
Codice : L001
Utente : Falegname con minime cognizioni informatiche e geometriche.
Scopo : Permettere ad un utente con poca dimestichezza con il PC (e quindi con i prodottiCAD/CAM) di generare i programmi di lavorazione per macchina a CN di pezzi semplici(ricavabili da grezzi parallelepipedi, con tagli di lama, contornature e scassi con fresa, foratureverticali e orizzontali).
Descrizione delle funzionalità : Creazione e modifica di contorni e scassi nel piano XY,creazione e modifica di fori verticali e orizzontali. Definizione di lavorazioni di taglio con lama, dicontornatura con fresa e di foratura verticale e orizzontale. Simulazione e generazione dellelavorazioni.
Caratteristiche non funzionali : Estrema semplicità di utilizzo, disponibilità dei soli comandinecessari (esiste un solo pezzo, quindi ...), sequenza guidata di utilizzo. Possibilità di usarelavorazioni standard predefinite (meglio avere lavorazioni inserite nella definizione dei percorsi). Possibilità di funzionare sul PC a bordo del controllo numerico (O.S. Win95).
Livello di significatività : Importante.
Presenza nei prodotti dei concorrenti : Tutti (da …… alle foratrici ……al ………….)
Esempio
A3 - Requisiti Paolo Salvaneschi 15
Modelli per l’analisi
• Modelli per l’analisi– Modelli concettuali– Non richiedono competenze informatiche– Sono modelli di business– Per svilupparli è richiesta la conoscenza degli
esperti di dominio
A3 - Requisiti Paolo Salvaneschi 16
Modelli per l’analisi
• Modelli– Struttura statica– Dinamica– Rappresentazioni grafiche– Ragionamento ed analisi– Transizione verso la progettazione– Interazione con gli esperti
A3 - Requisiti Paolo Salvaneschi 17
valutazione del costo di pareggio
Calcolo tariffa vincolata. Valutazione
del risparmio/ benchmark
produzione informazioni di base per offerta
Accettazione offertaSe rifiutata per problemi di prezzo si ridiscute
Se rifiutata per problemi di profilo si riattiva analisi profiloAltrimenti: accettata
offerta accettata
richiesta modifica
costo di pareggiorisparmio/benchmark
offerta
produzione offerta
info di base per offerta
monitoraggio del consumo e analisi del
profilo durante l''esercizio
modifica del profilo durante l''esercizio
profilo
Consuntivo e previsioni venditePrezzi forniture
Autorizzazione offerta
Riattivazioneanalisi profilo
info di base per offerta autorizzata
costo di pareggio
Requisiti espressi attraverso un modello– Reti di Petri interpretate
Sistema informativo di una Utility
Esempio
A3 - Requisiti Paolo Salvaneschi 18
Esempio
Requisiti espressi attraverso un modello– Diagramma E-R
Banca dati per la gestione di misure di monitoraggio ambientale e strutturale
A3 - Requisiti Paolo Salvaneschi 19
Transizione da modello concettuale a implementazione
Esempio
A3 - Requisiti Paolo Salvaneschi 20
Esempio
Transizione da modelloconcettuale a implementazione
A3 - Requisiti Paolo Salvaneschi 21
Prototipi
• Sviluppo di prototipi– Evolutivi– Usa e getta
A3 - Requisiti Paolo Salvaneschi 22
Prototipoper specificaevolutivo
Sistema informativo per siti archeologici
Esempio
A3 - Requisiti Paolo Salvaneschi 23
<omissis>La stesura del documento di specifica funzionale deve essere frutto di una intensa collaborazione con gli esperti applicativi, in modo che esso rifletta la reale pratica operativa e le esigenze degli utenti potenziali, e di un esame approfondito dello stato dell'arte dei sistemi informativi nel settore applicativo.In questa fase si decide di procedere alla realizzazione di un primo prototipo,prodotto in anticipo temporale rispetto "versione di base" richiesta per la fine della fase 1 della ricerca. Scopo del prototipo è raggiungere una migliore comprensione delle esigenze attraverso una "specifica animata". Il prototipo è realizzato, presentato agli esperti applicativi e sottoposto a dettagliata critica. Da ciò emerge una nuova stesura del documento di specifica con un contenuto più robusto e condiviso.<omissis>Si noti che i dati introdotti sono solo parzialmente relativi al sito di Pompei. Altri dati sono stati caricati al puro scopo di rendere più esemplificativa la presentazione.E' opinione del gruppo di progetto che questo modo di procedere (specifica testuale aiutata da prototipo reale il più possibile anticipato temporalmente) sia stato determinante per riuscita del progetto.
Esempio
A3 - Requisiti Paolo Salvaneschi 24
3. Caratteristiche TECNOLOGICHE del prototipoDal punto di vista tecnologico il prototipo è realizzato nella stessa tecnologia Intranet/Internet che verrà utilizzata per il prodotto finale.Esso consiste di :• Un server WWWW alfanumerico e multimediale;• Un server WWW cartografico.Ai server si accede attraverso un qualunque navigatore Internet.La scelta di realizzare il prototipo nella stessa tecnologia Intranet/Internet che sarà utilizzata per il prodotto finale permette di ottenere due risultati:• valutare il comportamento del prodotto nel suo ambiente reale di esercizio;• valutare la robustezza della tecnologia per la specifica applicazione.
Esempio
A3 - Requisiti Paolo Salvaneschi 25
Sistema finale
Esempio
A3 - Requisiti Paolo Salvaneschi 26
Forme linguistiche
• Stili di specifica (formalismo)– informali: linguaggio (testuale o grafico) dal formato
libero, (es: specifiche in linguaggio naturale)
– semi-formali: linguaggio (testuale o grafico) con sintassi definita in modo formale (almeno parzialmente) e semantica definita in modo informale (es: diagrammiEntità - Relazione)
– formali: linguaggio (testuale o grafico) con sintassi e semantica definite in modo formale (ad esempio: specifiche algebriche degli ADT)
A3 - Requisiti Paolo Salvaneschi 27
Forme linguistiche
• Stili di specifica (proceduralità)– operazionali: descrivono il comportamento desiderato
di un prodotto– dichiarative (descrittive): descrivono le proprieta’
desiderate di un prodotto
Esempio: specifica della figura geometrica ellisse
OPERAZIONALE:Traiettoria di due punti che si muovono nel piano in modo tale che la sommadella loro distanza da due punti fissi P1 e P2 resti costante
DICHIARATIVA Curva i cui punti hanno coordinate che soddisfano l’equazione ax2+by2+c=0
A3 - Requisiti Paolo Salvaneschi 28
Linguaggio naturale
Rappresentazioni grafiche
Linguaggio naturale strutturato
diagrammi a blocchi
Diagrammi di flussodei dati DFD
Reti di Petri
Automi a stati finiti
Linguaggio naturale
Rappresentazioni grafiche
Diagrammi Entità-Relazione E/R
Modelli ad oggetti
Specifiche algebriche
Specifiche logiche
Forme linguistiche
operazionali
descrittive
informali semi-formali formali
A3 - Requisiti Paolo Salvaneschi 29
Forme linguistiche
• Quale è la tecnica / il linguaggio “migliore” ?
Tecniche e Linguaggi
•Tipo di applicazione•Vincoli
TempiCostiTipo di clienteSkill…
• Quale sono le tecniche /i linguaggi “più adeguati al caso” ?• Integrazione di tecniche e linguaggi
A3 - Requisiti Paolo Salvaneschi 30
• Quale è il punto di vista più importante ?
Rigore e formalitàCompletezza
…
Condivisione con le parti interessate
ComprensioneIdentificazione delle criticità
…
Forme linguistiche
A3 - Requisiti Paolo Salvaneschi 31
Documentazione
• L’analisi dei requisiti e la definizione delle specifiche produce un documento
• Schemi di documento
A3 - Requisiti Paolo Salvaneschi 32
Esempio
A3 - Requisiti Paolo Salvaneschi 33
INDICEStoria delle revisioni1 Introduzione2 Riferimenti3 Sottosistema Entità Territoriali3.1 Gestione componente afferente al patrimonio immobiliare3.2 Gestione componente non afferente al patrimonio immobiliare3.3 Gestione flussi intersettoriali4 Specifiche funzionali4.1 Schema di interazione con le entità4.2 Transazioni4.3 Storicizzazione4.4 Gestione separata di geometrie e anagrafiche4.5 Ambiente di disegno4.6 Gestione componente afferente al patrimonio immobiliare4.6.1 Gestione Aree di circolazione e toponomastica4.6.2 Gestione Accessi4.6.3 Gestione Corpi di fabbrica4.6.4 Gestione Unità edilizie elementari4.6.5 Gestione Ingressi4.6.6 Gestione Dati Catastali4.6.7 Gestione Unità immobiliari urbane4.6.8 Gestione tabelle minori4.6.9 Attività aggiuntive4.7 Gestione componente non afferente al patrimonio immobiliare4.7.1 Gestione interventi in atto4.7.2 Gestione generalizzata delle entità con valenza informativa e cartografica4.7.3 Gestione generalizzata entità cartografiche4.8 Gestione transazione5 Specifiche non funzionali6 Indice funzionalità7 Definizioni, abbreviazioni e sigle
Esempio
A3 - Requisiti Paolo Salvaneschi 34
Indice
1. Introduzione1.1 Scopo1.2 Abbreviazioni e sigle1.3 Riferimenti1.4 Bibliografia2. Obiettivi3. Funzionalità principali del sistema informativo4. Utenti4.1 Utenti in sito4.2 Utenti remoti fruitori delle informazioni connesse al sistema archeologico5. Descrizione generale6. Suddivisione in sottosistemi7. Sistema Centrale7.1 Dati7.1.1 La banca dati multimediale7.1.2 I dati territoriali7.1.3 I modelli e le ricostruzioni7.2 Le funzioni di gestione dei dati7.2.1 Le funzioni di gestione della Banca Dati Multimediale7.2.2 Le funzioni di gestione dei dati territoriali7.2.3 Le funzioni di gestione di modelli e ricostruzioni7.2.4 Le funzioni di supporto agli scavi7.3 Funzioni di integrazione e comunicazione7.3.1 La funzione di comunicazione per gli specialisti7.3.2 La funzione di comunicazione per il pubblico8. Sottosistema di acquisizione8.1.1 Le funzioni di acquisizione dati9. Sottosistema di modellazione e ricostruzione9.1.1 Le ricostruzioni 2D e 3D10. Specifiche non funzionali
Esempio
A3 - Requisiti Paolo Salvaneschi 35
Documentazione
• Storia delle revisioni• Introduzione
– Scopo– Definizioni, abbreviazioni e sigle– Riferimenti
• Contesto di riferimento– Situazione attuale– Limiti della situazione attuale
• Obiettivi• Requisiti e specifiche funzionali• Requisiti e specifiche non funzionali• Profili Utente• Allegati
Indice tipo
A3 - Requisiti Paolo Salvaneschi 36
Sintesi
Contesto/ Dominio
Nuovo sistema
A3 - Requisiti Paolo Salvaneschi 37
Modello del contesto
/ dominio
ObiettiviRequisiti
Sintesi
A3 - Requisiti Paolo Salvaneschi 38
Modello del contesto
/ dominio
ObiettiviRequisiti
Modello del sistema
valutazione del costo di pareggio
Calcolo tariffa vincolata. Valutazione
del risparmio/ benchmark
produzione informazioni di base per offerta
Accettazione offertaSe rifiutata per problemi di prezzo si ridiscute
Se rifiutata per problemi di profilo si riattiva analisi profiloAltrimenti: accettata