requirementengineering - star-labenrico/ingegneriadelsoftware/anno03-04/rep.pdf · enrico...
TRANSCRIPT
Enrico Giunchiglia Ingegneria del Software II 2
Requisiti
� Requisito: Ogni informazione (ottenuta in qualche modo) circa le funzionalità, i servizi, le modalità operative e di gestione del sistema da sviluppare
� … può quindi variare da una descrizione astrattaed imprecisa del sistema, fino a una descrizionedettagliata e matematica dello stesso.
Enrico Giunchiglia Ingegneria del Software II 3
Requirement Engineering
� Il Requirement Engineering è il processo secondo cui i requisiti del sistema sono evidenziati, analizzati e validati.
� Scopo del Requirement Engineering è la produzione di un documento (il requirementdocument) che definisca le funzionalità e i servizi offerti dal sistema da realizzare
� Tale documento deve pertanto dire che cosa(piuttosto che come) il sistema dovrebbe fare
Enrico Giunchiglia Ingegneria del Software II 4
Il processo di Requirement Engineering
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
Enrico Giunchiglia Ingegneria del Software II 5
Elicitazione dei Requisiti
� L’Elicitazione dei requisiti è il processo di acquisizione di informazioni sul sistema da sviluppare.
� Tale processo può coinvolgere diverse persone (end-users, managers, programmatori, esperti dominio), ma può anchecomportare l’analisi della legislazione e/o di realizzazionipre-esistenti.
� Le diverse persone coinvolte in tale processo rappresentanogli stakeholders.
Enrico Giunchiglia Ingegneria del Software II 6
Problemi nell’Analisi dei Requisiti� Gli Stakeholders difficilmente hanno una chiara idea di
quello che esattamente vogliono (soprattutto all’inizio)� Gli Stakeholders usano un loro linguaggio (molto spesso
tipico del dominio) molte volte non noto all’analista� E’ facile che diversi stakeholders abbiano richieste diverse,
e quindi pongano requisiti in conflitto� I requisiti del sistema possono dipendere da fattori esterni al
sistema stesso (esigenze derivate da motivi organizzativiaziendali, o politico/legislativi)
� I requisiti (così come gli stakeholder) possono cambiaredurante la fase di analisi
Enrico Giunchiglia Ingegneria del Software II 7
Il Processo di Analisi dei Requisiti
Requirementsvalidation
Domainunderstanding
Prioritization
Requirementscollection
Conflictresolution
Classification
Requirementsdefinition andspecification
Processentry
Enrico Giunchiglia Ingegneria del Software II 8
Classificazione dei requisiti
I requisiti si possono dividere (o classificare) in diversi modi, in base a diversi parametri, quali
1. Le caratteristiche descritte (funzionali o non)
2. La sorgente del requisito (i view points)3. L’oggetto descritto (sistema vs. modulo)
Enrico Giunchiglia Ingegneria del Software II 9
Requisiti Funzionali e Non
� I Requisiti Funzionali (Functional Requirement) descrivono le funzionalità ed i servizi forniti dal sistema
� I Requisiti Non Funzionali (Non FunctionalRequirement) non sono collegati direttamente con le funzioni implementate dal sistema, ma piuttosto alle modalità operative, di gestione, … . Definiscono vincoli sullo sviluppo del sistema
Enrico Giunchiglia Ingegneria del Software II 10
Esempio: Bancomat� Si consideri un sistema bancomat. Il servizio deve mettere a
disposizione le funzioni di prelievo, saldo, estratto conto. Il sistema deve essere disponibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie. …..
Enrico Giunchiglia Ingegneria del Software II 11
Esempio: Bancomat� Si consideri un sistema bancomat. Il servizio deve mettere a
disposizione le funzioni di prelievo, saldo, estratto conto. Il sistema deve essere disponibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie. …..
Enrico Giunchiglia Ingegneria del Software II 12
Esempio: Bancomat� Si consideri un sistema bancomat. Il servizio deve mettere a
disposizione le funzioni di prelievo, saldo, estratto conto. Il sistema deve essere disponibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie. …..
Enrico Giunchiglia Ingegneria del Software II 13
Tipi di Requisiti Non Funzionali
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
Enrico Giunchiglia Ingegneria del Software II 14
Altri tipi di requisiti: di Dominio
� Domain Requirements: derivano dal dominio in cui il sistema deve operare. Es.:
� La decelerazione del treno deve essere computata come Dtrain = Dcontrol + Dgradient dove Dgradient dipende dal tipo di treno
� Il sistema deve garantire la privatezza delle informazioni trattate, ed in particolare deve essere garantito da intrusioni esterne
Enrico Giunchiglia Ingegneria del Software II 15
Altri tipi di Requisiti: Utente
� User Requirements: descrizione astratta, non tecnica del sistema. Deve essere comprensibile agli utenti del sistema. Di solito, sono specificati in linguaggio naturale. Es.
� Il sistema permetterà all’utente di inserire/modificare/cancellare nodi attraverso menu a finestra …
Enrico Giunchiglia Ingegneria del Software II 16
Risoluzione dei Conflitti
� Può accadere che si abbiano inconsistenze frarequisiti non funzionali di sistemi complessi, soprattutto quando le sorgenti sono diverseEs.� “Il sistema deve essere operativo e funzionante entro X mesi”
� “Il sistema deve garantire Y funzionalità” vs “Il sistemanon deve costare più di Z”
� Soluzione: rimozione di uno dei due requisiti
Enrico Giunchiglia Ingegneria del Software II 17
Prioritizzazione
� Più frequentemente si hanno conflitti fra requisiti non funzionali. � Es.: “Al fine di minimizzare il consumo di energia, si deve minimizzare il numero di chip utilizzati preferendo quelli a basso consumo” vs “Si devono garantire tempi di risposta
adeguati”
� Soluzione: Prioritizzazione
Enrico Giunchiglia Ingegneria del Software II 18
Validazione dei Requisiti
Il documento prodotto alla fine dell’analisi è:� Corretto: La descrizione rappresenta fedelmente
i vincoli indicati dall’utente?� Completo: La descrizione comprende tutte le
funzioni ed i vincoli indicati dall'utente?
� Consistente: Ci sono incongruenze tra i requisiti?� … (vedi IEEE 830-1993)
Enrico Giunchiglia Ingegneria del Software II 19
Specifica dei Requisiti
� Processo attraverso il quale i requisiti vengono rappresentati e strutturati in modo organico
� Tecniche diverse si adattano a diverse categorie di problemi. É importante quindi scegliere la tecnica di specifica più adatta al problema e/o dominio
� Le tecniche si suddividono� rispetto al grado di formalità linguaggio usato� rispetto a cosa descrivono del sistema (il loro stile )
Enrico Giunchiglia Ingegneria del Software II 20
Verifica/Validazione dei Requisiti
Al fine di verificare una specifica, vi sono due possibilità:
1. Analisi delle proprietà del sistema, deducendole dalla specifica
2. Osservazione del comportamento dinamico del sistema:
1. Simulazione
2. Prototipazione
Enrico Giunchiglia Ingegneria del Software II 21
Il Requirement Document
� Documento ufficiale risultato del RequirementEngineering Process
� Stabilisce “che cosa” il sistema deve fare, piuttosto che “come” si deve fare
� Usato sia in fase di sviluppo che di validazione/verifica del sistema
Enrico Giunchiglia Ingegneria del Software II 22
IEEE 830-1993Lo standard IEEE 830-1993 è espressamente dedicato al
Software Requirements Specification (SRS).
Il punto di partenza è costituito dalla definizione di otto attributi di qualità cui deve rispondere un SRS. Questi sono1. Non ambiguità2. Correttezza3. Completezza4. Verificabilità5. Consistenza6. Modificabilità7. Tracciabilità8. Priorità
Enrico Giunchiglia Ingegneria del Software II 23
IEEE Std. 830-1993 – NON AMBIGUO
An SRS is unambiguous if and only if every requirementstated therein has only one interpretation. As a minimum, this requires that each characteristic of the final product isdescribed using a single unique term. In cases where a term used in a particular context could have multiple meanings, the term must be included in a glossary whereits meaning is made more specific.
� Ogni requisito ha una sola interpretazione possibile, sia per chi lo definisce (“chi scrive”), sia per chi lo usa (“chi legge”).
Enrico Giunchiglia Ingegneria del Software II 24
IEEE Std. 830-1993 – CORRETTOAn SRS is correct if and only if every requirement stated
therein is one that the software shall meet.
� Ogni requisito rappresenta fedelmente nel sistema finale qualcosa che è stato richiesto
Da questa definizione segue che: � Non può esistere nessun tool o procedura che verifica la
correttezza fino a quando il sistema non è implementato� E’ possibile verificare la correttezza delle specifiche rispetto
ad altre specifiche, ad esempio più astratte
Enrico Giunchiglia Ingegneria del Software II 25
IEEE Std. 830-1993 – COMPLETOAn SRS is complete if it posses the following qualities:1. Inclusion of all significant requirements, whether relating to functionality,
perfomance, design constraints, attributes or external interfaces.2. Definition of the responses of the software to all reliable classes of input
data in all realizable classes of situations. Note that it is important to specifythe responses to valid and invalid input values.
3. Full labelling and referencing of all figures, tables, and diagrams in the SRS and definition of all terms and units of the measure.
Any SRS that uses the phrase “… TBD ...” is not comple. If it is ncessary, itshould be accompanied by:
� A description of the conditions causing the TBD (for example, why ananswer is not known) so that the situation can be solved.
� A description of what must be done to eliminate the TBD.
� Contiene i requisiti di tutte le funzionalità del sistema, e specifica, per tutte le possibili classi di input, la risposta del sistema. La completezza è spesso ottenibile solo incrementalmente, dopo raffinamenti successivi.
Enrico Giunchiglia Ingegneria del Software II 26
IEEE Std. 830-1993 –VERIFICABILE
An SRS is verifiable if and only if every requirement statedtherein is verifiable. A requirement is verifiable if and only ifthere exists some finite cost-effective process with which a person or machine can check that the software productmeets the requirement. If a method cannot be devised todetermine whether the software meets a particularrequirement then that requirement has to be removed or revised.
� Ogni requisito deve essere chiaro. Se un requisito non è esprimibile in termini verificabili nel momento in cui l’SRS viene definito, dovrebbe essere definito un momento del ciclo di vita del software entro cui il requisito deve essere presentato in una forma verificabile
Enrico Giunchiglia Ingegneria del Software II 27
IEEE Std. 830-1993 –CONSISTENTE
Consistency refers to internal consistency. An SRS isconsistent if and only if no set of individual requirementsdescribed in it conflict. There are three types of likelyconflicts in an SRS:� two or more requirements might describe the same real world object
but use different terms for that objects.
� the specified characteristics of the real world object might conflict.
� there might be a logical or temporal conflict between two specifiedactions.
� non esistono requisiti che non sono consistenti con altri
Enrico Giunchiglia Ingegneria del Software II 28
IEEE Std. 830-1993 –MODIFICABILE
An SRS is modifiable if and only if its structure and style are such that any necessary changes to the requirements can be made easily, completely and consistently. Modifiability generally requires an SRS to:� have a coerent and easy-to-use organization, with a tableof contents, an index, and explicit cross-referencing;
� not to be redundant. Whenever redundancy is necessary, the SRS should include explicit cross-references to makeit modifiable.
� Express each requirement separately, rather thanintermixed with other requirements.
Enrico Giunchiglia Ingegneria del Software II 29
IEEE Std. 830-1993 –TRACCIABILE
An SRS is traceable if the origin of each of its requirementsis clear and if it facilitates the referencing of the requirement in future development or enhancement of the documentation. Two types of traceability are recommented:1. Backward Traceability: depends upon each requirement explicitly
referencing its source in previous documents.
2. Forward Traceability: depends upon each requirement in the SRS having a unique name or reference number.
� Ogni requisito deve essere identificabile univocamente (FT). Quando un requisito A nell’SRS deriva da un altro requisito B, deve essere specificata la dipendenza di A da B (BT).
Enrico Giunchiglia Ingegneria del Software II 30
IEEE Std. 830-1993 – PRIORITA’
An SRS is ranked for importance and/or stability ifeach requirement in it has an identifier to indicate either the importance or stability of that particularrequirement. Typically, all of the requirements thatrelate to a software product are not equallyimportant. Some requirements may be essential, while others may be desiderable. Each requirementin the SRS should be identified to make thesedifferences clear and explicit
Enrico Giunchiglia Ingegneria del Software II 31
Struttura del RequirementsDocument (IEEE/ANSI 830-1993)1. Introduzione
1. Obiettivo del Requirement Document2. Obiettivo del prodotto3. Definizioni, acronimi, abbreviazioni4. Riferimenti5. Struttura del documento
2. Descrizione Generale1. Descrizione del prodotto dai diversi punti di vista2. Funzionalità del prodotto3. Caratteristiche utente4. Vincoli sul prodotto
3. I Requisiti (funzionali, non-funzionali, lato utente …)4. Appendici5. Indice
Enrico Giunchiglia Ingegneria del Software II 32
Struttura del RequirementsDocument (I. Sommerville)1. Glossario: Definisce i termini tecnici utilizzati2. Modelli del sistema: Definisce i modelli mostrando i componenti del
sistema e le loro relazioni3. Definizione dei requisiti funzionali: Descrive i servizi forniti4. Definizione requisiti non funzionali: Definisce i vincoli sul sistema
ed il processo di sviluppo5. Evoluzione del sistema: Definisce le assunzioni principali su cui si
basa il sistema e le modifiche future6. Specifica dei requisiti: Specifica dettagliata dei requisiti funzionali7. Appendici: Descrizione dettagliata collegata all’applicazione da
sviluppare. (Es. piattaforma hardware da usare, schema della base dei dati)
8. Indice