Corso di Ingegneria del Software a.a. 2009/2010 Ingegneria dei …infocom.uniroma1.it/~cdainformazione/uploads/Ingegneria... · 2010. 3. 19. · Corso di Ingegneria del Software a.a

Corso di Ingegneria del Software a.a. 2009/2010 Ingegneria dei Requisiti

Corso di Ingegneria del Softwarea.a. 2009/2010

Ingegneria dei Requisiti

Mario Vacca

[email protected]


L’elicitazione dei requisiti

L’ingegneria dei requisiti

Sommario

1. Il processo di ingegneria dei requisiti

2. L’elicitazione dei requisiti (cont’d)

3. Le altre attivita

4. Attivita propedeutiche

5. Bibliografia



Tecniche e approcci per l’elicitazione dei requisiti

Brainstorming, Group Work, JAD e RW

I BrainstormingE un processo nel quale i partecipanti discutono informalmente econtribuiscono alla elicitazione di spunti e idee generali. Promuovefreethinking and espressione.

I Group WorkMeeting collaborativo; difficile da organizzare e gestire.

I Joint Application Development (JAD)Joint Application Development (JAD) coinvolge tutti glistakeholders per indagare, attraverso una discussione generale, suiproblemi e le possibli soluzioni. (lo scopo e prefissato).

I Requirements workshop (RW)




Ethnography, Osservazione, Protocol Analysis, Apprendistato

Tecniche costose che richiedono skill particolari.

I EthnographyE lo studio delle persone nel loro ambiente; coinvolge gli analisti chepartecipano attivamente o no alle normali attivita degli utenti.Si usa dove l’usabilita e un parametro importante.

I OsservazioneL’analista osserva l’esecuzione di processi esistenti da partedell’utente, senza interfferenza.E usata in congiunzione con le interviste o task analysis.

I Protocol AnalysisI partecipanti compiono un task e lo descrivono ad alta voce.

I ApprenticingApprenticing coinvolge l’analista nell’apprendimento dei compitisotto la supervisione di un istruttore/ utente esperto.




Prototyping

I prototipi sono sviluppati usando requisiti preliminari o esempi esistenti osimilari.Di solito sono usati in congiunzione con altre tecniche di elicitazione, comeinterviste o JAD.




Goal Based Approaches

Figura: Goal in TROPOS

John Mylopoulos “Tropos at the Age of 6:Status and Research Directions” University

of Trento, March 2, 2006, DIT, UniTN, Trento

http://www.troposproject.org/view/Presentations




Scenari e Viewpoint

I ScenariScenari sono narrative e decrizioni specifiche che includono azioni einterazioni tra utente e sistema.Richiedono un approccio iterativo e incrementale per il loro sviluppo.

I ViewpointsModellano il dominio da differenti prospettive/punti i vista (es. intermini di operazioni, implementazione o interfacce; punto di vistautente o sistema).Una critica: non rappresntano facilmente i requisiti non funzionali esono costosi in termini di sforzo richiesto per la loro descrizione.




Confronto di tecniche

“Ultimately, each situation is unique and the answers to these questionsare highly dependant on the context of the project and system. We ac-knowledge that because of this there is always the possible for exceptionsto any rule made along these lines;. . . ”

Aybuke Aurum, Claes Wohlin “Engineering and Managing Software Requirements“

Springer, 2005, pag. 32



Tecniche e approcci per l’elicitazione dei requisitiUso delle tecniche

Figura: Tecniche alternative e complementari

Aybuke Aurum, Claes Wohlin “Engineering and Managing Software Requirements“

Springer, 2005, pag. 33


Le altre attivita


Sommario



3. Le attivita


5. Bibliografia


Le altre attivita

Il processo di ingegneria dei requisiti

Attivita del processo di ingegneria dei requisiti

I Elicitation and capturing of requirementsvengono raccolti presso il cliente i requisiti (le sue esigenze).

I Requirement analysisi requisiti raccolti vengono analizzati per capirne la fattibilita enegoziarne le priorita.

I Requirement specificationvengono specificati in un documento quali requisiti verrannosoddisfatti dal software

I Requirement validationil documento di specifica dei requisiti viene validato dal cliente.

I Requirement managementi requisiti possono evolvere durante lo sviluppo: queste modifichevanno gestite.


Le altre attivita









Le altre attivita









Le altre attivita









Le altre attivita









Le altre attivita

Analisi dei requisiti

Dopo aver raccolto le informazioni di contesto dal cliente e le sue as-pettative in termini di requisiti per il prodotto da sviluppare, bisogna:

I verificare la realizzabilita di tali richieste (nell’ambito delle risorsedisponibili e dei vincoli del progetto, ad es. il tempo e il budget),

I negoziare l’elenco delle aspettative da soddisfare e le priorita con lequali vanno soddisfatte.

Negoziazione e compromesso

L’analista puo proporre al cliente compromessi tra funzionalita,prestazioni, costo, tempo di sviluppo, qualita, sicurezza etc..


Le altre attivita


Negoziazione

Nella fase di negoziazione i requisiti sono classificati in classi di importanzae priorita, in funzione del valore che si assegna loro.Ad esempio:

I Requisiti obbligatoriSono quelli irrinunciabili.

I Requisiti desiderabiliSono quelli non strettamente necessari, ma utili.

I Requisiti opzionaliSono quelli relativamente utili o contrattabili in un secondo tempo.


Le altre attivita


Cosa rappresentare al cliente

E utile rappresentare al cliente cio che si e capito rispetto alle sue aspet-tative attraverso un modello, in modo da poter analizzare e discutere irequisiti.Il modello puo rappresentare:

I le funzioni che il software offre all’utente (ad es. con degli use case)

I il comportamento del software (es. activity diagrams, data flowdiagrams, diagrammi degli stati)

I la struttura statica dell’architettura del software (ad es. con idiagrammi delle classi).


Le altre attivita


Riesame dei requisiti

L’analista, se l’incarico ricevuto relativamente allo sviluppo del softwarederiva da un contratto, deve

I verificare se i requisiti sono compatibili con i vincoli e le previsioni(l’ordinativo) contenute nel contratto.

I evidenziare le eventuali differenze tra cio che e chiesto nel contrattoe i requisiti raccolti e valutato l’impatto che avrebbe la realizzazionedi questi requisiti “non contrattuali” sui vincoli imposti dal contrattoal progetto (tempi di consegna, budget)

L’organizzazione cui e stato affidato lo sviluppo dovrebbe anche valutarela propria capacita di realizzare anche questi nuovi requisiti.


Le altre attivita

Validazione dei requisiti

La validazione del documento SRS deve essere fatta dal cliente.Tra i criteri che si possono utilizzare, oltre la verifica puntuale che l’analistaabbia compreso le sue esigenze, vi sono:

1. Correttezza

2. Consistenza

3. Completezza

4. Non ambiguita

5. Verificabilita

6. Modificabilita

7. Tracciabilita

8. Realizzabilita

9. Comprensibilita

10. Adattabilita


Le altre attivita


I CorrettezzaLe funzioni che svolge il sistema sono esattamente quelle richiestedall’utente?

I ConsistenzaCi sono incongruenze/contraddizioni tra i vari requisiti?

I CompletezzaLa descrizione comprende tutti i requisiti emersi nella fase di analisi?Ogni concetto introdotto e stato definito?

I Non ambiguitaOgni requisito ha una sola interpretazione?(Puo essere utile costruire un dizionario per effettuare questaverifica).


Le altre attivita


I VerificabilitaI requisiti sono scritti in modo che possano essere facilmenteverificati in modo “quantitativo” nel prodotto finale?Non usare termini vaghi per definire degli obiettivi posti al software,ma usare misure!

I ModificabilitaLa struttura del documento SRS e tale che sono possibili facilmentemodifiche?

I TracciabilitaOgni requisito e identificato in modo univoco?E collegato alla sua fonte (chi l’ha espresso)? E censita la storia diogni sua modifica? E tracciata la sua eventuale connessione con altrirequisiti?


Le altre attivita


Altre caratteristiche desiderabili dei requisiti:

I RealizzabilitaI requisiti sono realizzabili con la tecnologia ed il budget disponibile?

I ComprensibilitaI requisiti sono espressi in forma chiara per le diverse tipologie dilettori (manager, utenti, progettisti, addetti alla gestione delsoftware, ecc.)?

I AdattabilitaI singoli requisiti possono essere modificati senza influenzare altrirequisiti? Ovvero sono tracciate le interdipendenze?


Le altre attivita

Gestione dei requisiti

I requisiti evolvono durante lo sviluppo.Sono detti volatili quelli che subiscono maggiori modifiche.Tra le cause piu frequenti:

I variazione delle esigenze del cliente,

I variazioni dell’ambiente operativo/tecnologico,

I migliore comprensione del sistema da realizzare (il processo stesso dispecifica genera la conoscenza del sistema da sviluppare)

I variazioni del budget delle scadenze della disponibilita di risorse


Le altre attivita


Approcci

I Secondo alcuni modelli le modifiche vanno pianificate, in termini dicosti, impatto, tracciabilita, e concordate con il cliente.

I Secondo altri modelli (es. agili) le modifiche vanno assecondate.


Le altre attivita


Approcci

I Secondo alcuni modelli le modifiche vanno pianificate, in termini dicosti, impatto, tracciabilita, e concordate con il cliente.

I Secondo altri modelli (es. agili) le modifiche vanno assecondate.


Le altre attivita


Tracciabilita dei Requisiti

Un requisito e tracciabile se e direttamente connesso all’origine.La tracciabilita e una proprieta della specifica dei requisiti.Bisogna essere capaci di tracciare i requisiti nei componenti di progetto,nel codice, nei casi di test, ecc.


Le altre attivita





Le altre attivita





Le altre attivita





Le altre attivita


Tracciabilita dei Requisiti: Tipi

I Tracciabilita dell’origineIndica la sorgente/origine di ciascun requisito: persone (es. ilcommittente); documento (es. uno standard sulla sicurezza)Esempio:“I parametri da controllare in fase di validazione sono:Il tipo di dato (string, integer, real, etcO)Il set di caratteri consentitoLa lunghezza minima e massimaControllare se e permesso il tipo NULLControllare se il parametro e richiesto o menoIntervallo numerico”(Parametri OWASP per la validazione dell’input)


Le altre attivita



I Tracciabilita della descrizioneIndica perche i requisiti sono stati specificati

I Tracciabilita delle dipendenzeIndica i collegamenti con altri requisiti


Le altre attivita



I Tracciabilita dei sottosistemiIndica i sottosistemi in cui i requisiti sono implementatiI requisiti possono essere suddivisi per categorie in base aisottosistemi che li implementano.

I Tracciabilita del progettoCollega i requisiti con componenti specifici del sistema che sonousati per implementarli

I Tracciabilita dell’interfacciaIndica le interfacce interne ed esterne del sistema che premettono diutilizzare i requisiti.


Le altre attivita


Tecniche di tracciabilita

Si codificano i requisiti (si assegna un numero univoco a ciascun requisitohtipo � requisitoi hnumero � requisitoiSi costruscono matrici requisiti x aspetti per collegare i requisiti ai variaspetti considerati.


Le altre attivita

Tracciabilita dei RequisitiTecniche di tracciabilita

Requisito/ Interfaccia

I1 I2 I3

R1

R2

R3

R4

R5

R6

R7

Requisito/ Modulo

M1 M2 M3 M4 M5

R1

R2

R3

R4

R5

R6

R7

Requisito/ Sorgente

Utente1 Utente2 Utente3 Linee Sicurezza

R1

R2

R3

R4

R5

R6

R7


Le altre attivita

Ingegneria dei requisiti

Consigli pratici

I Cercare di capire quali funzionalita/servizi deve fornire il software,non come funzionaBisogna concentrarsi soprattutto all’inizio sul “cosa” il software devefare, non sul “come” lo fara e mediante quale tecnologieSe ci si concentra subito troppo sul “come” il software lavora, sirischia di anticipare all’inizio scelte progettuali tecniche, che devonoviceversa derivare dalla analisi delle esigenze e non “guidarla”.

I Rappresentare il sistema al livello di astrazione dell’utente, non delprogettista del software

I Evitare di anticipare scelte tecniche che dovrebbero essere compitodei progettisti del software.


Le altre attivita


Consigli pratici

I La fonte primaria dei requisiti sono gli utenti. Ma:

I gli utenti non sempre sanno veramente cosa vogliono (possono farerichieste non realizzabili, almeno nei limiti del progetto), o non losanno subito,

I gli utenti si esprimono nel loro linguaggioI utenti diversi possono esprimere requisiti in conflitto tra loro

I Evitare di esser ambigui o vaghi. Meglio precisare e se possibilequantificare ogni scelta.

I i requisiti possono precisarsi o anche emergere durante il progetto,non solo all’inizio. I requisiti variano spesso!


Attivita propedeutiche


Sommario





5. Bibliografia




Lo Studio di Fattibilita

I Nei progetti piu rilevanti, l’inizio dello sviluppo dovrebbe esserepreceduto dalla stesura di un documento chiamato Studio diFattibilita.

L’obiettivo dello Studio di Fattibilita e fornire al Committente di un pro-getto le informazioni che gli permettono di acquisire la indispensabile con-sapevolezza sulla portata e le conseguenze dell’investimento che intenderealizzare.

Lo studio non individua le esigenze (che devono essere gia esistenti) ma per-mette valutare se procedere nel progetto e di scegliere tra possibili soluzionia fronte del budget disponibile, dei possibili rischi e di altri limiti specificidel contesto.


















I contenuti dello Studio di Fattibilita

I la soluzione di massima individuata per risolvere le esigenze espresse dal cliente

I i requisiti tecnici ed organizzativi (sempre di massima) necessari a realizzare lasoluzione

I altri vincoli da rispettare durante lo sviluppo

I il piano di massima di realizzazione della soluzione

I l’investimento necessario, i tempi, le risorse, i benefici che si possono conseguire,

I i rischi da valutare ed eventuali contromisure,

I cio che e necessario alla messa in esercizio ed alla manutenzione del sistemarealizzato,

I i costi da sostenere per realizzare e gestire il software.

I la scelta della soluzione

La soluzione identificata deve essere valutata in confronto con altre possibilisoluzioni. La scelta tra le alternative si deve basare su criteri espliciti edoggettivi, che vano identificati e discussi. Va valutato l’impatto organizzativodella soluzione scelta, e i benefici ottenibili rispetto ai costi da sostenere.




Studio di Fattibilita: Make or Buy?

Una delle analisi da compiere nello Studio di Fattibilita e la scelta dellemodalita di acquisizione della soluzione software. Le opzioni sono:

I farlo in casa (se si hanno le risorse), in tutto od in parte(assemblando sviluppi ad hoc e prodotti COTS, ricorrendo al riuso disoftware gia esistente)

I affidarne la realizzazione all’esterno (ad es. tramite una gara tra piufornitori),

I acquistare pacchetti di mercato o licenze d’uso.

La scelta dipende da fattori economici, esigenze di riservatezza,opportunita, compatibilita con altri sistemi, tempi, ecc




Piano di progetto

Il Piano di progetto e piano di massima di realizzazione della soluzione.Il Piano deve descrivere

I le attivita principali da svolgere

I le principali scadenze temporali

I le interrelazioni tra le attivita, se significative.

La definizione di dettaglio del Piano e demandata alla successiva faseoperativa di attuazione del progetto.




Capitolato Tecnico

Nel caso piu generale, se lo Studio di Fattibilita certifica la convenienzadel progetto, il cliente ne affida la realizzazione a un “fornitore” (supplier).Il fornitore viene individuato attraverso una procedura di negoziazione, chepuo svolgersi in forma di una gara o di una trattativa privata tra le parti.Nella gara l’acquirente rende noto a tutti i possibili concorrenti

I i contenuti della fornitura (i requisiti del prodotto)

I le modalita di svolgimento dei lavori che dovranno essere seguite dalvincitore che si aggiudica la

I i tempi di consegna

I il prezzo massimo che e disposto a pagare.

Le gare sono aggiudicate all’offerta piu vantaggiosa per l’acquirente dalpunto di vista tecnico e economico.




Capitolato Tecnico

Il Capitolato Tecnico e Il documento dove il committente definisce i requi-siti della fornitura oggetto del contratto e gli altri elementi che il fornitoredovra soddisfare.Il Capitolato Tecnico contiene anche gli elementi necessari allaeffettuazione del collaudo di quanto realizzato, a fine lavori.




Capitolato Tecnico

Oggetto della fornituraDescrive in maniera sintetica tutti gli oggetti (software e no) che il fornitoredeve consegnare all’acquirente.Tra gli oggetti non software ma correlati al software vanno previsti la doc-umentazione progettuale, d’uso, gestione operativa e manutenzione, i casie i piani di test, il piano di progetto e quello della qualita etc..).Per ognuno degli oggetti che il fornitore deve consegnare all’acquirente vadefinito se deve essere sviluppato ad hoc, se si tratta di prodotti COTS (alicenza d’uso) se va costruito a partire dal riuso di software gia esistente(in tutto o in parte), se va costruito assemblando software ad hoc conprodotti COTS, se si tratta di parametrizzazione di prodotti COTS etc.



Ingegneria dei requisitiCapitolato Tecnico

M. Benimeo, G. Polese, M. Vacca, “Verso un Tool per la Gestione di E-learning Data Warehouse”,2009.




Esempio di Capitolato Tecnico

Appalto per Sistema Integrato di Consultazione die-learning repositories

Azienda: Corso Ingegneria del SoftwareAutore: Mario VaccaData di creazione: 10.03.2010Versione: 1.1Indice del documento1. Oggetto della fornitura1.1 Termini usati, loro uso e significato





1. Oggetto della fornituraIl presente capitolato ha per oggetto l’affidamento della fornitura di un sistema software

integrato per la consultazione di e-learning repositories.

L’obiettivo del progetto e affrontare le problematiche tecnologiche della consultazione di

repository di learning object mediante un plugin per la piattaforma MOODLE. Il sistema

deve integrare LOR multipli e deve consentire di consultarli.

1.1 Termini usati, loro uso e significatoSistema e l’oggetto della presente fornitura.LO significa Learning Object. LOR significa Learning Object Repository.LOR virtuale e la vista dei LOR.I requisiti obbligatori saranno introdotti usando il verbo dovere.I requisiti non obbligatori, ma che si preferirebbe che fossero realizzati saranno introdottida “dovrebbe”I requisiti facoltativi sono introdotti da puo o potrebbe.I requisiti non desiderati sono introdotti da “non dovrebbe”.

I requisiti che assolutamente non devono essere presenti sono introdotti da “non deve”.




Capitolato Tecnico

I Dimensionamento della fornituraPer ognuno degli oggetti che il fornitore deve consegnareall’acquirente definisce le dimensioni attese dal cliente, espressenell’unita di misura appropriata (punti funzione, giorni persona etc..).

I Profilo di qualita della fornituraDescrive quali caratteristiche dovranno possedere gli oggetti softwareconsegnati a fine lavori




Capitolato Tecnico

I Modalita di svolgimento della fornituraDescrive gli aspetti metodologici che devono essere rispettati dalfornitore nello svolgimento delle attivita.Tra gli aspetti che si possono definire vi sono il ciclo di svilupposcelto (ad es. iterativo e incrementale), il ricorso a tools,

I Modalita di gestione dei requisitiDescrive le modalita con le quali i requisiti vanno tracciati e gestitinelle loro varianti durante il processo di sviluppo.





2. Requisiti2.2 Requisiti non funzionaliIl sistema deve essere integrato nella piattaforma MOODLE sot-to forma di plugin. Il prodotto deve quindi essere realizza-to all’interno della piattaforma MOODLE, utilizzando gli strumen-ti software messi a disposizione dalla stessa piattaforma e documen-tati sul sito http://docs.moodle.org/en/Development La piattaforma(http://moodle.org/) e open source.L’interfaccia deve essere visuale. Il sistema deve riuscire a collegarsi con irepository e deve consentire di scaricare LO in tempi ragionevoli (ordine dipochi secondi).Solo gli utenti autenticati devono poter scaricare LO dai LOR.Solo l’amministratore puo aggiungere o cancellare LOR.





2.3 Requisiti di interfacciaIl sistema deve essere composto da due interfacce.2.3.1 Interfaccia per insegnantiGli insegnanti accedono al LOR virtuale mediante l’ontologia OIOrealizzata graficamente.2.3.2 Requisiti dell’interfaccia dell’amministratoreMediante questa interfaccia l’amministratore deve poter scegliere irepository da integrare, aggiungere repository o cancellarne altri.3. Variazioni ai requisitiNon sono ammesse variazioni se non a evidente miglioramento di quantorichiesto dal committente. Non e esclusa la comunicazione, da parte delcommittente, di variazioni ai requisiti sia precedentemente alla consegnadelle offerte che durante la realizzazione del sistema.




Capitolato Tecnico

I Modalita di gestione dei testDescrive quali tipologie di test vanno effettuati sui diversi elementiprodotti dal ciclo di sviluppo, in quali fasi lavorative e con qualitecniche.

I Modalita di collaudo della fornituraDescrive quali prove saranno effettuate dall’acquirente a fine lavorisu quanto realizzato, al fine della sua accettazione e del suopagamento. Vanno descritti anche l’ambiente (hardware e software)utilizzati per le prove.




Capitolato Tecnico

I Documentazione della fornituraDescrive i documenti che devono essere consegnati dal fornitore:

I Il documento di specifica dei requisiti utenteI L’architettura logico funzionale del sistema software da produrreI Il disegno tecnico del sistema software da produrreI Il piano dei testI I manuali d’uso, manutenzione e gestione operativa





5. DocumentazioneLa consegna del sistema deve comprendere i manuali d’uso, il codice sor-gente, e ogni altra documentazione necessaria per l’utilizzo del sistema eper l’estensione futura del sistema.6. Garanzia e manutenzioneIl fornitore dovra garantire in sede di collaudo il funzionamento corretto delsistema. L’eliminazione dei difetti e delle non conformita eventualmenteemersi in sede di collaudo sono a totale carico del fornitore.Le modalita di collaudo e i dati di collaudo sono allegati al presentedocumento e ne costituiscono parte integrante.




Capitolato Tecnico

I Ambiente di sviluppoDescrive l’eventuale ambiente tecnico che il fornitore dovra utilizzare.Va definito anche come gestire la configurazione di cio che vienerealizzato.Andrebbe definito anche come gestire i requisiti del cliente e le lorovariazioni con strumenti automatici.

I Profili professionaliVanno descritti i profili professionali minimi delle persone delfornitore che lavoreranno nelle varie fasi e attivita del progetto.


Bibliografia


Sommario





5. Bibliografia


Bibliografia

Bibliografia

Riferimenti bibliografici - Generali

1. R. Pressman “Ingegneria del software” Mc Graw Hill Italia, 5aedizione, 2007, capitolo 9.

2. P. Jalote “A Concise Introduction to Software Engineering”Springer, 2008, capitolo 3.


Bibliografia

Bibliografia

Riferimenti bibliografici - Specifici

1. Aybuke Aurum, Claes Wohlin “Engineering and Managing SoftwareRequirements“ Springer, 2005.

2. M. Glinz, “On Non-Functional Requirements.”, RE 2007, pag. 21-26

3. N. Niu, S. Easterbrook, “Discovering Aspects in Requirements withRepertory Grid”, EA 2006, pag. 35-41


Bibliografia

Bibliografia

Riferimenti bibliografici - Siti utili

1. Progetto TROPOShttp://www.troposproject.org/

2. Volere Requirements Specification Templatehttp://www.volere.co.uk/

3. CaliberRMhttp://www.borland.com/us/products/caliber/index.html

4. RequisitProhttp://www-01.ibm.com/software/awdtools/reqpro/features/

5. Objectiverhttp://www.objectiver.com/index.php?id=6

http://www.troposproject.org/

http://www.volere.co.uk/

http://www.borland.com/us/products/caliber/index.html

http://www-01.ibm.com/software/awdtools/reqpro/features/

http://www-01.ibm.com/software/awdtools/reqpro/features/

http://www.objectiver.com/index.php?id=6

Documents

Corso di Ingegneria del Software a.a. 2009/2010 Ingegneria dei …infocom.uniroma1.it/~cdainformazione/uploads/Ingegneria... · 2010. 3. 19. · Corso di Ingegneria del Software a.a