32
Requirement Engineering Enrico Giunchiglia

RequirementEngineering - STAR-LABenrico/IngegneriaDelSoftware/anno03-04/REP.pdf · Enrico Giunchiglia Ingegneria del Software II 10 Esempio: Bancomat Si consideri un sistema bancomat

  • Upload
    haliem

  • View
    220

  • Download
    0

Embed Size (px)

Citation preview

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.

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