RequirementEngineering - unige.itenrico/IngegneriaDelSoftware/anno... · 2007. 12. 12. · IEEE...

Requirement Engineering

Enrico Giunchiglia

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.


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


Il processo di Requirement Engineering

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument


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.


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


Il Processo di Analisi dei Requisiti

Requirementsvalidation

Domainunderstanding

Prioritization

Requirementscollection

Conflictresolution

Classification

Requirementsdefinition andspecification

Processentry


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)


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


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


Tipi di Requisiti Non Funzionali

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements


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


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 …


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


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


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)


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 )


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


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


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à


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


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


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.


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


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


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.


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


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


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


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

RequirementEngineering - unige.itenrico/IngegneriaDelSoftware/anno... · 2007. 12. 12. · IEEE...

Documents

Transcript of RequirementEngineering - unige.itenrico/IngegneriaDelSoftware/anno... · 2007. 12. 12. · IEEE...