Corso di Ingegneria del Software · Astrazione dei requisiti (Davis) Ingegneria del Software 5...

Corso di Ingegneria del Software

Paolo Bottoni

Blocco 4: Ingegneria dei Requisiti

Lucidi tradotti e adattati a partire dalla versione in inglese presente a http://iansommerville.com/software-engineering-book/slides/

Blocco4RequisitiIngegneria del Software 2

Obiettivi

• Descrivere attività di ingegneria requisiti

• Introdurre tecniche di estrazione e analisi requisiti

• Introdurre concetti di requisiti utente e sistema

• Descrivere requisiti funzionali e non-funzionali

• Fornire indicazioni su scrittura dei requisiti

• Discutere validazione e cambiamento di requisiti

Processo di ingegneria dei requisiti

• Stabilisce servizi cliente che richiede a sistema e

vincoli sotto cui sistema opera ed è sviluppato

• Requisiti di sistema sono descrizioni di servizi di

sistema e vincoli generati durante processo

Ingegneria del Software 3Blocco4Requisiti


Cos’è un requisito?

• Da descrizione ad alto livello di servizio o vincolo a specifica funzionale matematica dettagliata

• Diversi tipi e funzioni:– Base per offerta per contratto

• Aperta a interpretazione

– Base per contratto• Da definire in dettaglio

– Base per pianificazione test• Aspetti funzionali e non-funzionali

• Scenari di successo e scenari di errore

Astrazione dei requisiti (Davis)

Ingegneria del Software 5

“If a company wishes to let a contract for a large software development

project, it must define its needs in a sufficiently abstract way that a

solution is not pre-defined.

The requirements must be written so that several contractors can bid for

the contract, offering, perhaps, different ways of meeting the client

organization’s needs.

Once a contract has been awarded, the contractor must write a system

definition for the client in more detail so that the client understands and

can validate what the software will do.

Both of these documents may be called the requirements document for

the system.”

Blocco4Requisiti

Due tipi di documenti di requisiti

• Definizione dei requisiti: elenco completo di

quanto cliente vuole ottenere

– Descrive anche entità in ambiente di installazione

(anche detti Requisiti utente)

• Specifica dei requisiti: riformula requisiti per

specificare come deve comportarsi sistema proposto

(anche detti Requisiti di Sistema)


Ambiente e sistema

• Requisiti definiti ovunque in dominio ambiente, inclusa

interfaccia sistema

• Specifica ristretta a interfaccia fra sistema e ambiente



Processi di ingegneria dei requisiti

• Dipendenza da dominio applicativo, persone

coinvolte, organizzazione responsabile requisiti

• Attività generiche comuni

– Estrazione requisiti

– Analisi requisiti

– Convalida requisiti

– Gestione requisiti

Studio di

fattibilità

Elicitazione e

analisi requisiti

Specifica

requisiti

Validazione

requisiti

Rapporto di

fattibilità Modelli di

sistema

Requisiti di

utente e sistema

Documento dei

requisiti


Studio di fattibilità

• Decide se sistema proposto è valido

• Breve studio focalizzato che verifica se:

– Sistema contribuisce a obiettivi organizzazione

– Realizzabile con tecnologia corrente, entro budget

– Integrabile con altri sistemi in uso


Implementazione studio di fattibilità

• Basato su:

– definizione informazioni (cosa è richiesto)

– raccolta informazioni

– scrittura rapporto

• Domande per persone nell’organizzazione

– Cosa succederebbe se non implementato

– Problemi attuali processo

– Come aiuterebbe sistema attuale

– Quali saranno problemi di integrazione

– Occorre nuova tecnologia? Nuove competenze?

– Quali funzioni vanno supportate da sistema proposto?


Estrazione e analisi (scoperta requisiti)

• Coinvolge personale tecnico che lavora con clienti

per ottenere informazioni su:

– dominio applicativo

– servizi che sistema deve fornire

– vincoli operativi su sistema

• Stakeholder:

– utenti finali

– dirigenti

– ingegneri coinvolti in mantenimento

– esperti di dominio

– sindacati, etc.

• Attenzione: stakeholder non necessariamente utenti

Ingegneria del Software

Stakeholder per Mentcare I

• Pazienti con informazione registrata in sistema

• Dottori responsabili valutazione e trattamento

• Personale infermieristico che coordina consultazioni

con medici e somministra trattamenti

• Personale accettazione che gestisce appuntamenti

• Personale IT responsabile installazione e

manutenzione sistema


Stakeholder per Mentcare II

• Gestore etico che deve garantire conformità

con linee guida etiche per cura pazienti

– Non necessariamente utente

• Gestori sanitari che ottengono informazioni di

gestione da sistema

• Personale per cartelle cliniche devono garantire

che informazione possa essere mantenuta e

conservata e che procedure di registrazione

siano implementate correttamente

– Non necessariamente utente



Problemi dell’analisi dei requisiti

• Stakeholder non sanno cosa vogliono veramente

• Esprimono requisiti con loro linguaggio

• Stakeholder diversi possono avere requisiti in conflitto

• Influenza di fattori politici e organizzativi

• Requisiti cambiano durante il processo di analisi.

– Emergenza di nuovi stakeholder

– Cambiamento ambiente economico

• Un po' di Folklore

Ingegneria del Software

whatTheUserWanted.pdf

Processo di elicitazione e analisi


4. Specifica

requisiti2. Classificazione

e organizzazione

requisiti

1. Scoperta

requisiti

3. Negoziazione e

organizzazione

requisiti


Modello a spirale per specifica requisiti

Specifica dei

requisiti

Validazione

dei requisiti

Elicitazione

dei requisiti

Modellazione e

specifica requisiti di

sistema

Elicitazione

requisiti di

sistema

Specifica

requisiti utente

Specifica requisiti

di business

Prototipazione

Studio di fattibilità

Revisione

Documento requisiti di sistema

Elicitazione

requisiti utente

Classificazione e

organizzazione requisiti

Prioritizzazione e

negoziazione requisiti

Documentazione requisiti

Scoperta requisiti


Attività su requisiti in ciclo a spirale

• Scoperta – Interazione con stakeholder per scoprire loro requisiti

– Si scoprono anche requisiti di dominio

• Classificazione e organizzazione– Raggruppare requisiti collegati

– Organizzarli in raggruppamenti coerenti

• Prioritizzazione e negoziazione– Dare priorità e risolvere requisiti contrastanti

• Documentazione– Requisiti documentati e introdotti in prossimo giro spirale


Scoperta dei requisiti

• Raccoglie informazione su sistemi

– proposti e esistenti

• Estrae requisiti utente e di sistema

• Fonti di informazione:

– documentazione

– stakeholder per sistema

– specifiche di sistemi simili

Interviste

• Interviste formali o informali con stakeholder

• Tipi di interviste

– Chiuse, lista predeterminata di domande

– Aperte, questioni esplorate con stakeholder

• Interviste efficaci

– Apertura mentale, evitare preconcetti, ascoltare

– Stimolare intervistato partendo da domande o

proposta di requisiti, o lavoro comune su prototipo

– Non chiedere semplicemente cosa pensano

– Normalmente mistura di domande aperte e chiuse

– Ottenere comprensione generale di cosa fanno stakeholder e come interagiscono con sistema


Specifica dei requisiti

• Processo di scrittura in documento requisiti

(requisiti utente e di sistema)

• Requisiti utente comprensibili da utenti finali e

clienti senza conoscenze tecniche

• Requisiti sistema più dettagliati, possono includere

informazione tecnica

• Requisiti possono essere parte di contratto

– Completezza importante

• In RUP, requisiti espressi mediante casi d’uso



Tipi di punti di vista

• Interattori

– Persone o sistemi che interagiscono direttamente col sistema

• Per Mentcare, medici

• Indiretti

– Stakeholder che non usano sistema, ma influenzano requisiti

• Per Mentcare, personale amministrativo

• Del dominio

– Caratteristiche e vincoli di dominio che influenzano requisiti

• Per Mentcare, responsabili conformità a standard etici e legali

Requisiti funzionali per Mentcare

• Un utente dovrà essere in grado di esplorare le liste

di appuntamento per tutte le cliniche

• Il sistema genererà ogni giorno, per ogni clinica, una

lista di pazienti con appuntamenti quel giorno

• Ogni membro del personale che usi il sistema sarà

univocamente identificato dalla sua matricola a 8 cifre



Scenari

• Esempi da vita reale: come sistema

potrebbe essere usato

• Dovrebbero includere

– Descrizione situazione di partenza

– Descrizione normale flusso eventi

– Descrizione di cosa può andare male

– Informazione su attività concorrenti

– Descrizione stato a conclusione scenario

Condivisione foto in classe (iLearn)

• Jack is a primary school teacher in Ullapool (a village in northern Scotland). He has

decided that a class project should be focused around the fishing industry in the area,

looking at the history, development and economic impact of fishing. As part of this,

pupils are asked to gather and share reminiscences from relatives, use newspaper

archives and collect old photographs related to fishing and fishing communities in the

area. Pupils use an iLearn wiki to gather together fishing stories and SCRAN (a history

resources site) to access newspaper archives and photographs. However, Jack also

needs a photo sharing site as he wants pupils to take and comment on each others’

photos and to upload scans of old photographs that they may have in their families.

Jack sends an email to a primary school teachers group, which he is a member of to

see if anyone can recommend an appropriate system. Two teachers reply and both

suggest that he uses KidsTakePics, a photo sharing site that allows teachers to check

and moderate content. As KidsTakePics is not integrated with the iLearn

authentication service, he sets up a teacher and a class account. He uses the iLearn

setup service to add KidsTakePics to the services seen by the pupils in his class so

that when they log in, they can immediately use the system to upload photos from

their mobile devices and class computers.


Caricamento foto (iLearn)

• Initial assumption: A user or a group of users have one or more digital

photographs to be uploaded to the picture sharing site. These are saved on

either a tablet or laptop computer. They have successfully logged on to

KidsTakePics.

• Normal: The user chooses upload photos and they are prompted to select

the photos to be uploaded on their computer and to select the project name

under which the photos will be stored. They should also be given the option of

inputting keywords that should be associated with each uploaded photo.

Uploaded photos are named by creating a conjunction of the user name with

the filename of the photo on the local computer.

• On completion of the upload, the system automatically sends an email to the

project moderator asking them to check new content and generates an on-

screen message to the user that this has been done.


Caricamento foto

• What can go wrong:

• No moderator is associated with the selected project. An email is automatically

generated to the school administrator asking them to nominate a project moderator.

Users should be informed that there could be a delay in making their photos visible.

• Photos with the same name have already been uploaded by the same user. The user

should be asked if they wish to re-upload the photos with the same name, rename the

photos or cancel the upload. If they chose to re-upload the photos, the originals are

overwritten. If they chose to rename the photos, a new name is automatically

generated by adding a number to the existing file name.

• Other activities: The moderator may be logged on to the system and may approve

photos as they are uploaded.

• System state on completion: User is logged on. The selected photos have been

uploaded and assigned a status ‘awaiting moderation’. Photos are visible to the

moderator and to the user who uploaded them.



Imprecisione dei requisiti

• Problemi se requisiti non espressi precisamente

• Requisiti ambigui possono essere interpretati diversamente da sviluppatori e utenti

• Termine ‘esplorare’ in requisito 1 in Mentcare

– Intenzione utente – ricerca nome paziente in su

appuntamenti in ogni clinica

– Interpretazione sviluppatore – ricerca ogni volta su

clinica particolare, dopo avere scelto clinica


Convalida dei requisiti

• Dimostrazione che requisiti definiscono sistema

che utente vuole realmente

• Importanza convalida: alto costo errori requisiti

– Costo correzione errore dopo consegna fino a 100

volte costo correzione errore implementazione

• Attenzione: convalida riguarda formulazione

requisiti, non realizzazione


Tecniche di convalida dei requisiti

• Revisioni dei requisiti– Analisi manuale sistematica

• Prototipizzazione– Uso di modello eseguibile sistema

• Generazione casi di prova– Sviluppo di prove per requisiti per analizzabilità


Controllo dei requisiti

• Validità. Sistema fornisce funzioni che meglio

supportano esigenze utente?

• Coerenza. Ci sono conflitti fra requisiti?

• Completezza. Tutte funzioni richieste cliente incluse?

• Realismo. Requisiti implementabili con bilancio e

tecnologia disponibili?

• Verificabilità. Soddisfazione requisiti controllabile?


Revisioni dei requisiti

• Revisioni regolari mentre si formula definizione

• Personale cliente e azienda produttrice

• Formali (con documenti completi) o informali

– Comunicazione efficace fra sviluppatori, clienti e

utenti può risolvere problemi in stadio precoce


Controlli della revisione

• Verificabilità. Realmente controllabile?

• Comprensibilità. Correttamente compreso?

• Tracciabilità. Origine chiara?

• Adattabilità. Modificabile con poco impatto?


Requisiti durevoli e volatili

• Durevoli

– Requisiti stabili attività organizzazione cliente

• Es. ospedale avrà sempre dottori, infermiere

– Derivabile da modelli dominio

• Volatili

– Cambiano durante sviluppo o uso

• es. in ospedale, requisiti da politiche sanitarie


Classificazione dei requisiti volatili

Tipo requisito Descrizione

Mutevole Cambia con ambiente operativo organizzazione.

Emergente Cambia con aumento comprensione sistema

cliente. Progettazione può rivelarne di nuovi.

Consequenziale Introduzione sistema cambia processi.

Compatibilità Dipende da processi di sistema o di business.


Tracciabilità

• Relazioni tra requisiti, origine, progetto sistema

• Tracciabilità origine

– Collegamento fra requisito e stakeholder proponente

• Tracciabilità requisiti

– Collegamenti tra requisiti dipendenti

• Tracciabilità progetto

– Collegamento da requisiti a progetto


Gestione dei cambiamenti dei requisiti

• Stadi principali

– Analisi problema

• Discutere problema con requisito e proporre cambiamento

– Analisi cambiamento e valutazione costi

• Stabilire effetti cambiamento su altri requisiti

– Implementazione cambiamento

• Modificare documento requisiti per riflettere cambiamento


Matrice di dipendenze

Req.

id

1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2

1.1 D R

1.2 D D D

1.3 R R

2.1 R D D

2.2 D

2.3 R D

3.1 R

3.2 R

D: Riga dipende da colonna

R: Relazione generica


Supporto da strumenti

• Memorizzazione requisiti

– Requisiti in memoria sicura e gestita

• Gestione del cambiamento

– Processo di flusso di lavoro

• stadi definiti e automatizzazione parziale flusso informazione

• Gestione della tracciabilità

– Ritrovamento automatico collegamenti tra requisiti


Struttura del documento dei requisiti

• Prefazione

• Introduzione

• Glossario

• Definizione dei requisiti utente

• Architettura di sistema

• Specifica dei requisiti di sistema

• Modelli di sistema

• Evoluzione del sistema

• Appendici

• Indice


Utenti di un documento dei requisiti

Usano requisiti per sviluppare

test di sistema

Usano requisiti per capire quale

sistema va sviluppato

Ingegneri test

sistema

Dirigenza

Ingegneri

sistema

Specificano e leggono requisiti per

verificare che soddisfino bisogni.

Specificano cambiamenti requisiti

Utenti

sistema

Usano requisiti per comprendere

sistema e relazioni tra parti

Ingegneri

manutenzione

Usano requisiti per pianificare offerta e

processo di sviluppo


Requisiti funzionali e non-funzionali

• Funzionali– Cosa sistema dovrebbe fornire,

– Come dovrebbe reagire a particolari ingressi

– Come dovrebbe comportarsi in particolari situazioni

• Non-funzionali– Vincoli su servizi o funzioni offerte da sistema,

– Vincoli di tempo

– Su processo di sviluppo

– Standard, ecc.

• Requisiti di dominio– Da dominio applicativo

• Caratteristiche particolari


Completezza e coerenza dei requisiti

• Completi– Includere descrizioni di ogni utilità richiesta

• Coerenti– Non dovrebbero esserci conflitti o contraddizioni

in descrizioni utilità sistema

• In pratica impossibile produrre documento requisiti completo e coerente

Processi di messa in questione

• Rimozione

– Requisito scartato

• Generalizzazione

– Ci sono casi particolari?

• Distorsione

– Requisito modificato per incorporare situazioni


Tipi di requisiti

• Requisito funzionale: descrive comportamento

richiesto in termini di attività richieste

• Requisito di qualità o Requisito non-funzionale:

descrive caratteristiche che sistema deve possedere

• Vincolo di progetto: imposti da stakeholder, e.g.

scelta di piattaforma o componenti interfaccia

• Vincolo di processo: restrizione su risorse o

tecniche utilizzabili per costruzione sistema



Tipi di requisito

• Requisiti utente

– Scritti per clienti

– Composti da

• Frasi in linguaggio naturale

• Diagrammi servizi

• Vincoli operativi

• Requisiti sistema

– Documento strutturato

• Descrizioni dettagliate funzioni, servizi, vincoli operativi

– Definisce cosa implementare

– Può essere parte di contratto fra cliente e fornitore


Requisiti utente

• Dovrebbero descrivere requisiti funzionali e

non-funzionali comprensibili per utenti sistema

senza conoscenza tecnica dettagliata

• Definiti usando linguaggio naturale, tabelle e

diagrammi comprensibili da ogni utente

• Attenzione: se formulate da cliente, non

necessariamente riflettono vere richieste utenti


Requisiti di sistema

• Specifiche più dettagliate di funzioni, servizi e

vincoli di sistema che in requisiti utente

• Devono fornire base per progetto sistema

• Possono essere incorporati in contratto

• Possono essere definiti o illustrati usando

modelli di sistema

Requisiti utente e specifiche di sistema



Requisiti non-funzionali

• Definiscono proprietà e vincoli sistema.– es. affidabilità, tempo di risposta, requisiti di memoria

• Vincoli sono capacità di I/O di strumenti, rappresentazioni interne sistema

• Requisiti di processo: come condurre progetto– Es. particolare sistema CASE, linguaggio di

programmazione o metodologia di sviluppo

• Requisiti non-funzionali possono essere più critici di funzionali– Se non soddisfatti, sistema inutile


Classificazioni non-funzionali

• Requisiti di prodotto

– Richieste su comportamenti prodotto consegnato

• es. velocità di esecuzione, affidabilità

• Requisiti organizzativi

– Conseguenza di politiche e procedure organizzative

• es. standard di processo, requisiti di implementazione

• Requisiti esterni

– Da fattori esterni a sistema e processo di sviluppo

• es. interoperabilità, aspetti legali


Tipi di requisiti non funzionali

Requisiti

prestazionali

Requisiti di

spazio

Requisiti di

usabilità

Requisiti di

efficienza

Requisiti di

affidabilità

Requisiti di

portabilità

Requisiti di

interoperabilitàRequisiti etici

Requisiti legaliRequisiti di

implementazione

Requisiti su

standard

Requisiti di

consegna

Requisiti di

sicurezza

Requisiti di

privatezza

Requisiti di

prodotto

Requisiti

organizzativi

Requisiti

esterni

Requisiti non-

funzionali

Requisiti non-funzionali per Mentcare


Product requirement

The Mentcare system shall be available to all clinics during

normal working hours (Mon–Fri, 0830–17.30). Downtime within

normal working hours shall not exceed five seconds in any one

day.

Organizational requirement

Users of the Mentcare system shall authenticate themselves

using their health authority identity card.

External requirement

The system shall implement patient privacy provisions as set out

in HStan-03-2006-priv.

Blocco4Requisiti


Obiettivi e requisiti

• Formulazione precisa requisiti non-funzionali difficile

• Requisiti imprecisi difficili da verificare

• Obiettivo– Intenzione generale utente

• es. Facilità d’uso

• Requisito non-funzionale verificabile– Frase che usa misura sperimentabile oggettivamente

• Obiettivi utili a sviluppatori– Indicano intenzioni utenti sistema


Esempi

• Obiettivo di sistema

– “Sistema dovrebbe essere facile da usare da parte

del personale medico e dovrebbe essere organizzato

in modo da minimizzare gli errori dell’utente.”

• Obiettivo non-funzionale verificabile

– “Personale medico dovrebbe essere capace di usare

tutte le funzioni del sistema dopo un addestramento

di quattro ore. Dopo addestramento, numero medio di

errori commessi da utenti esperti non dovrebbe

essere superiore a due per ora di lavoro.”


Misure per operazionalizzazione requisiti

Proprietà Misura

Velocità Transazioni / secondo elaborateTempo di risposta Utente /EventoTempo di rigenerazione dello schermo

Taglia MBytesNumero di schede ROM

Facilità d’uso Tempo di addestramentoNumero di quadri di aiuto

Affidabilità Tempo medio fino a fallimentoProbabilità di indisponibilitàTasso di occorrenza dei fallimentiDisponibilità

Robustezza Tempo per ripartire dopo fallimentoPercentuale di eventi che causano fallimentoProbabilità di corruzione di dati su fallimento

Portabilità Percentuale di istruzioni dipendenti da piattaformaNumero di piattaforme bersaglio

Implementazione requisiti non-funzionali

• Possono influenzare architettura generale,

piuttosto che componenti individuali

– Per esempio, per soddisfare requisiti su prestazioni

sistema deve minimizzare comunicazioni

• Singolo requisito non-funzionale, es. relativo a

sicurezza, può generare vari requisiti funzionali

che definiscono servizi di sistema richiesti

– O generare requisiti che restringono quelli esistenti



Interazione fra requisiti

• Conflitti fra requisiti non-funzionali– Comuni in sistemi complessi

• Nave spaziale– Per minimizzare peso, numero di chip separati

sistema deve essere minimizzato

– Per minimizzare consumo di energia, utilizzare chip a bassa potenza

– Quale requisito più critico?


Requisiti di dominio

• Derivano da dominio applicativo; descrivono

caratteristiche sistema che riflettono dominio

– Es. nuovi requisiti funzionali, vincoli su requisiti esistenti,

definire computazioni specifiche

• Se non soddisfatti, sistema può essere inutilizzabile


Problemi con requisiti di dominio

• Comprensibilità

– Espressi in linguaggio dominio applicativo

– Spesso non capito da ingegneri software

• Impliciti

– Specialisti dominio conoscono area così bene

che non pensano di renderli espliciti


Problemi con linguaggio naturale

• Ambiguità– Lettori e autori requisito devono interpretare stesse

parole in stesso modo. Linguaggio naturale ambiguo.

– Precisione difficile da raggiungere senza rendere

lettura documento difficile

• Confusione dei requisiti

– Mescolanza requisiti funzionali e non-funzionali

• Amalgamazione dei requisiti

– Requisiti diversi espressi insieme.

• Eccessiva flessibilità– Stessa cosa detta varie volte in modi diversi.

Esempio requisiti per pompa insulina


3.2 The system shall measure the blood sugar and deliver

insulin, if required, every 10 minutes. (Changes in blood

sugar are relatively slow so more frequent measurement

is unnecessary; less frequent measurement could lead to

unnecessarily high sugar levels.)

3.6 The system shall run a self-test routine every minute

with the conditions to be tested and the associated actions

defined in Table 1. (A self-test routine can discover

hardware and software problems and alert the user to the

fact the normal operation may be impossible.)

Blocco4Requisiti


Requisito LIBSYS

4.5 “LIBSYS fornirà un sistema di tenuta conto

finanziario che mantiene traccia di tutti i pagamenti

fatti dagli utenti. I gestori del sistema possono

configurare questo sistema in modo che utenti regolari

possano ricevere tariffe scontate.”


Requisito di editor a griglie

2.6 Grid facilities Per favorire il posizionamento di entità in un

diagramma, l’utente può attivare una griglia in centimetri o

pollici, attraverso un’opzione sul pannello di controllo.

Inizialmente, la griglia non è presente. Può essere attivata e

disattivata in ogni momento durante una sessione di editing e

può venire alternata fra centimetri e pollici in ogni momento.

Un’opzione griglia sarà fornità nella vista “reduce-to-fit”, ma il

numero di linee della griglia sarà ridotto per evitare di riempire

il diagramma rimpicciolito con linee di griglia.


Problemi dei requisiti

• Requisito su base di dati include informazione sia concettuale sia dettagliata– Descrive concetto di sistema di rendicontazione finanziaria

da integrare in LIBSYS

– Include dettaglio configurabilità da parte utente• Non necessario a questo livello

• Requisito su griglia mescola tre diversi tipi– Requisito funzionale concettuale (necessità griglia)

– Requisito non-funzionale (unità griglia)

– Requisito non-funzionale di UI (attivazione griglia)


Presentazione strutturata

2.6.1 Strumenti griglia

L'editor offrirà uno strumento griglia in cui una matrice di linee orizzontali

e verticali fornirà uno sfondo alla finestra dell'editor. Questa griglia sarà una

griglia passiva, in cui l'allineamento delle entità è responsabilità dell'utente.

Motivazione: Una griglia aiuta l'utente a creare un diagramma pulito con entità

ben spaziate. Sebbene una griglia attiva, in cui le entità si attaccano alle linee

della griglia può essere utile, il posizionamento è impreciso. L'utente è la persona

più indicata per decidere dove dovrebbero essere posizionate le entità.

Specifica: ECLIPSE/WS/Tools/DE/FS Section 5.6

Fonte: Ray Wilson, Glasgow Office


Linee guida per scrittura di requisiti

• Trovare formato standard per ogni requisito

• Usare linguaggio in modo coerente. Usare

“deve” (o futuro) per requisiti obbligatori,

“dovrebbe” per requisiti desiderabili

• Usare evidenziazione per parti chiave requisito

• Evitare gergo informatico


Requisiti e progetto

• Requisito stabilisce cosa deve fare sistema

• Progetto descrive come lo fa

• In pratica requisiti e progetto spesso correlati

– Architettura di sistema può essere progettata per strutturare

requisiti

• Es. se architettura three tier, requisiti di Sistema possono avere

impatto su strati diversi

– Sistema può interoperare con altri sistemi che generano

requisiti di progetto

– Uso di modello di processo può essere requisito di dominio

• Anche derivabile da requisito legale


Alternative a linguaggio naturale

Notazione Descrizione

Linguaggio naturale strutturato

Forme standard o modelli per esprimere specifiche requisiti.

Linguaggi di descrizione del progetto

Linguaggio simile a linguaggio di programmazione, caratteristiche più

astratte per specifica requisiti attraverso modello operazionale sistema. Non molto usato, ma utile per specifica di interfacce.

Notazioni

grafiche

Linguaggio grafico, con annotazioni testuali, per definire requisiti

funzionali sistema. Casi d'uso e diagrammi di sequenza usati

comunemente.

Specifiche matematiche

Notazioni basate su concetti matematici: macchine a stati finiti,insiemi.Specifiche non ambigue riducono discussioni fra cliente e sviluppatori

su funzionalità sistema. Molti clienti non capiscono specifiche formali

e sono riluttanti ad accettarle in un contratto di sistema.


Specifiche in linguaggio strutturato

• Limita libertà autore: schema predefinito

• Requisiti scritti in modo standard

• Limitare terminologia usata in descrizione

• Mantiene espressività linguaggio naturale, ma impone grado di uniformità


Specifiche basate su moduli

• Definizione funzione o entità

• Descrizione ingressi e loro origine

• Descrizione uscite e loro destinazione

• Indicazione altre entità richieste

• Pre- e post-condizioni (se appropriato)

– verificabili

• Effetti collaterali funzione (se presenti)


Specifica di nodo basata su modulo

Insulin Pump/Control Software/SRS/3.3.2

Funzione Computa dose insulina: Livello di zucchero sicuro.

Descrizione Computa la dose di insulina da rilasciare quando il livello corrente di zucchero

misurato è nella zona sicura tra 3 e 7 unità.

Ingressi Lettura corrente dello zucchero (r2), le due letture precedenti (r0 e r1)

Origine Lettura zucchero corrente da sensore. Altre letture da memoria

Uscite CompDose – dose di insulina da rilasciare.

Destinazione Ciclo di controllo principale

Azione CompDose è zero se livello di zucchero è stabile, in discesa, o livello di zucchero sta

crescendo, ma tasso di crescita sta diminuendo. Se livello sta crescendo e tasso di

crescita sta aumentando, allora CompDose è calcolato dividendo per 4 la differenza

fra il livello corrente di zucchero e quello precedente e arrotondando il risultato. Se il

risultato è arrotondato a zero, allora CompDose è fissato a minima dose rilasciabile.

Richiede Due letture precedenti per calcolare tasso di cambiamento in livello di zucchero.

Pre-condizione Riserva di insulina contiene almeno la minima dose di insulina permessa.

Post-condizione r0 è rimpiazzato da r1; r1 è rimpiazzato da r2

Effetti collaterali Nessuno

Blocco4Requisiti


Specifica tabulare

• Complementa linguaggio naturale

• Utile quando definiti possibili corsi alternativi.

Condizione Azione

Livello di zucchero in caduta (r2 < r1) CompDose = 0

Livello di zucchero stabile (r2 = r1) CompDose = 0

Livello di zucchero in crescita e tasso di

crescita in diminuzione (r2-r1)<(r1-r0)

CompDose = 0

CompDose = round((r2-r1)/4)If CompDose = 0 then CompDose = MinimumDose

Livello di zucchero in crescita e tasso di

crescita stabile o in crescita (r2-r1)≥(r1-r0)

Blocco4Requisiti


Modelli grafici

• Utili quando occorre mostrare cambiamenti

di stato o sequenze di azioni

• Forniti principalmente da UML

• Diagrammi di sequenza, stato, attività

– (discussi in relazione a UML)

Blocco4Requisiti


Specifica di interfacce

• Per sistemi che devono operare con altri sistemi, interfaccia operativa specificata come parte requisiti

• Tre tipi di interfacce:– Procedurali

– Strutture dati scambiate

– Rappresentazioni dati

• Notazioni formali tecnica efficace per specifica

Blocco4Requisiti


Descrizione di interfaccia

interface PrintServer {

// defines an abstract printer server

// requires: interface Printer, interface PrintDoc

// provides: initialize, print, displayPrintQueue, cancelPrintjob, switchPrinter

void initialize(Printer p);

void print(Printer p, PrintDoc d);

void displayPrintQueue(Printer p)

void cancelPrintJob(Printer p, PrintDoc d);

void switchPrinter(Printer p1, Printer p2, PrintDoc d);

// } PrintServer

Blocco4Requisiti

Corso di Ingegneria del Software · Astrazione dei requisiti (Davis) Ingegneria del Software 5...

Documents

Transcript of Corso di Ingegneria del Software · Astrazione dei requisiti (Davis) Ingegneria del Software 5...