Ingegneria dei Requisiti - e dei Sistemi -

Giuseppe Berio

DI-Unito

2007

Ingegnerie dei Requisiti - e dei Sistemi -: Punti chiave

• Determinazione e specifica dei requisiti del software (senza distinguere lo studio di fattibilità, senza distinguere le due attività che possono essere svolte al contempo)

• Uso di notazioni (o linguaggi) nella Ingegneria dei Requisiti – e dei Sistemi -

• Formalizzazione della relazione tra Ingegneria dei Sistemi ed Ingegneria dei Requisiti

Sintesi• Due casi di determinazione dei requisiti ove si è visto che

l’attività di determinazione dei requisiti (o comunicazione) e quella di specifica (o modellazione analitica) sono state svolte a partire da una richiesta del committente (dal nulla – greenfield engineering - con richiesta più o meno innovativa)

• Si è evidenziato che: – La richiesta del committente, in generale, non indica direttamente i requisiti

del software ma tali requisiti devono essere esplicitamente determinati; infatti, la richiesta del committente, in generale, riguarda • un sistema in cui il software da sviluppare è solo una parte (il sistema è perciò

costituito sia dal software da sviluppare che dall’ambiente circostante a tale software e che con questo interagisce),

• indica, in particolare, cosa tale sistema dovrebbe permettere, anche dicendo poco o nulla su come tale sistema dovrà essere realizzato

– La tracciabilità di un requisito è, di conseguenza, un elemento fondamentale poiché giustifica un requisito in termini della richiesta del committente

Sintesi• Non si è distinto tra le due attività:

– Le diverse notazioni – semiformali – (cioè DFD, DFD esteso, UML) usate sono servite per svolgere analisi per verificare se ciò che è stato fatto è corretto, è completo o per ragionare su alternative possibili (determinazione dei requisiti), quindi permettere eventuale negoziazione anche in termini di tempi e costi

– E fatto osservare che i requisiti del software da sviluppare devono essere esplicitamente accettati o convalidati dal committente; il ruolo dell’ingegnere del software è solo quello di aiutare il committente nel definire e nel convalidare i requisiti del software (determinazione dei requisiti)

– Ma si è anche detto che ciò che è rappresentato con una o più notazioni è efficacemente usabile per progettare il software (specifica dei requisiti)

• Nell’uso delle notazioni si è evidenziato come l’ingegneria del software è sistematica cioè tenta di applicare regole definite per costruire diverse rappresentazioni (dei requisiti) con la medesima o diverse notazioni

•Se un sensore non funziona, il sistema dovrebbe fermare l’ascensore in funzione ai piani precedenti o successivi

•L’ascensore deve fermarsi se il sensore del piano selezionato rileva il passaggio dell’ascensore

Movimento

Comprensione

Modellazione

Analisi ConvalidaNegoziazione

Verifica Ammettiamo che un sensore non funziona; cosa accade?

Sensori

Ev_ascensorepiano(x)Movimento

Notazioni usate per la modellazione

• Matrici

• DFD

• Casi d’Uso (UML)

• Statechart (UML)

• DFD estesi

• Diagramma delle classi (UML)

• Diagramma di sequenza (UML)

Movimento

ordina

Gestione richieste

Sistema Meccanico -fermo al piano

Controllo Porte

SensoreApproccio

Piano

Pulsanti

RichiesteUtente

Richieste daServire

timer

Stato porte =aperta|chiuse+tempo

Stato Ascensore (pianoascensore)

richiesta

richiestenonordinate richiesteordinate

Prossima richiesta

pianocorrente

chiuse

stato

tempo

ABILITA

Ev_pianoascensore(x)

Ev_fermopianoascensore(x)

Ev_portechiuse(x)Ev_aprireporte(x)Ev_chiudereporte(x)

Ev_illumina Ev_disabilita(x)Ev_pulsantepremuto(x)

nuovopianocorrente

+avviaremotore()+diminuirevelocità()+fermarsi()

Motore

sensore

+pianoascensore(parameter = X)+esiste una richiesta da servire?()+pianorichiesta=X()+dimmi pulsanti da spegnere()

Fermare

+porte chiuse(parameter = X)+richiesta da servire()+qual è peso corrente()+dimmi i pulsanti da illuminare()+primarichiesta()+porte chiuse?()

Partire

+Illuminare(parameter = 'INARRIVO")+spegnersi()+illuminarsi-per conferma richiesta()

Pulsante

-stato-piano

Richiesta

0..1

0..*

0..1

0..*

+confermarsi come servita()

RichiestaDaServire

GestorePorte

+pulsante premuto()+qual è il peso()+è possibile fare una richiesta per il piano del pulsante premuto?()+dimmi i pulsanti da illuminare()+disabilitarepossibilità di fare richieste per lo stesso piano()

RichiestaInterna

PIanoVisual Paradigm for UML Standard Edition(Universita di Torino)

: sensore : Fermare

1: pianoascensore()

8: dimmi pulsanti da spegnere()

2: esiste una richiesta da servire?()

3: pianorichiesta=X()

ilmotore: : Motore

4: diminuirevelocità()

6: fermarsi()

5:

7:

: Pulsante

9: spegnersi()

10:

: RichiestaDaServire

11: confermarsi come servita()

12:

Visual Paradigm for UML Standard Edition(Universita di Torino)

Generalizzazione

Determinazione dei Requisiti: una definizione

• Obiettivo: arrivare ad una collezione, sufficientemente dettagliata, completa e condivisa (cioè priva di conflitti) tra tutti i partecipanti (stakeholder) dei requisiti che il prodotto software dovrà possedere, una volta prodotto

• La determinazione dei requisiti inizia da una richiesta del committente che, in generale, evidentemente, non indica necessariamente i requisiti del software da sviluppare; in particolare, spesso non indica una chiara distinzione tra ciò che è software da sviluppare e ciò che è l’ambiente circostante al software; i requisiti si devono perciò dedurre, estrarre, identificare, elaborare, negoziare, convalidare e forse anche analizzare

• La collezione raccoglie e, talvolta, permette di visualizzare, in varie forme, i requisiti di cui è composta, e i legami tra tali requisiti (inclusa la tracciabilità)

• Spesso tale collezione coincide con un documento dei requisiti

Specifica dei requisiti: una definizione• Obiettivo: produrre una “specifica dei requisiti” cioè una precisa

descrizione (modello) informale, semiformale ovvero formale, di tutti requisiti determinati, che permette di passare sistematicamente alla progettazione del software

• Qualunque sia il modo di operare, dovrebbe essere chiaro il legame tra i requisiti determinati e il modello qui costruito (tracciabilità)

• La specifica può essere più o meno formale ma dovrebbe essere sempre sufficientemente precisa, completa e corretta; come vedremo, la scelta per una specifica formale è essenzialmente legata alla necessità di provare una relazione fondamentale, tra i requisiti del software, il comportamento dell’ambiente circostante il software e, ciò che è richiesto dal committente

I prodotti principali delle due attività e le loro relazioni

• Il documento dei requisiti (una o più notazioni) che raccoglie la collezione organizzata dei requisiti determinati

• Il modello dei requisiti o modello analitico (una più notazioni) che rappresenta in modo opportuno la collezione dei requisiti determinati

• Il modello dei requisiti può far riferimento a modelli già presenti nel documento dei requisiti

• I due elaborati devono essere consistenti cioè non devono essere mutuamente contradditori

Dettaglio delle attività di determinazione e specifica dei requisiti

Comprensione

Modellazione

Analisi Convalida

NegoziazioneVerifica

Prototipo (*)

Modellazione

(*) dipende dal processo

può riusare o riferirsi

devono essere non contradditori (verifica)

Requisiti (Collezione +

Documento dei Requisiti) Modello

Linguaggio Comune

Modello dei Requisiti (Modello Analitico o

Specifica dei Requisiti) ModelloLinguaggio

Comune

Notazioni alternative per la specifica dei requisiti e la

determinazione dei requisiti

Notation Description Structured natural language

This approach depends on defining standard forms or templates to express the requirements specification.

Design description languages

This approach uses a language like a programming language but with more abstract features to specify the requirements by defining an operational model of the system.

Graphical notations

A graphical language, supplemented by text annotations is used to define the functional requirements for the system. An early example of such a graphical language was SADT (Ross, 1977; Schoman and Ross, 1977). More recently, use-case descriptions (Jacobsen, Christerson et al., 1993) have been used.

Mathematical specifications

These are notations based on mathematical concepts such as finite-state machines or sets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality. However, most customers don’t understand formal specifications and are reluctant to accept it as a system contract.

Una

loro

com

bina

zion

e

Formale

Semi-Formale

Informale

EsempioFermare

Spegnere i pulsanti (una passo del caso d’uso)

Partire (una caratteristica del sistema)

Descritto come

Descritto come

Descritto come

traced to (from)

• Rumore

– le affermazioni non indicano informazioni utili

• Silente

– qualcosa di non coperto dalle affermazioni

• Sovra-specificato

– si indica nelle affermazioni troppo sul come realizzare

• Contraddizione

– parti delle affermazioni che si contraddicono.

• Ambiguità

– esistono varie interpretazioni di un’affermazione, non necessariamte contradditorie

• Forward reference

– riferimenti a termini o altri elementi non ancora definiti nelle affermazioni

• Non validabile

– non si è certi che è possibile convalidare ciò che è affermato

• Frammentati

– gli elementi chiave contenuti nelle affermazioni sono dispersi in un documento

• Requisiti oca

– affermazioni formalmente corrispondenti a standard

• Terminologia inconsistente

– Invenzioni e modifiche della terminologia usata nelle affermazioni

• Rimandare il problema ad altri

– Obbligo per chi deve usare le affermazioni di decifrare il loro significato

• Formulazione per il lettore ostile

I problemi del linguaggio comune per esprimere i requisiti

Esempio di misure di qualità dei requisiti scritti in linguaggio comune

Imperatives

identified by words such as “shall”,

“must”, “is required”, etc.

Imperatives measure how explicit

a requirement document is.

Continuances follow an imperative and

introduce requirements

indicated by “below:”, “as follows:”

etc.

measure the structure of an a

requirement document.

Option

indicated by words such as “can”,

“may”, “optionally” etc.

measure how much latitude does

a requirement document leave

Weak phrases

cause uncertainty

e.g. “adequate”, “as applicable” etc.

Directives

indicated by tables, figures etc

these strengthen the quality of the

document

Size

in terms of lines of text, indicators

and subjects

roughly, the number of subjects for all

the imperatives

Text structure

measures the number of statement

identifiers

Specification depth

measures how deep are the subsections

of the a requirement document

gives an indication of a requirement document structure.

Readability statistics

e.g average number of syllables per

word, number of words per sentence

Cos’è un requisito del software

• Un requisito del software è un’affermazione sul software che riguarda proprietà, comportamenti, vincoli (di varia natura) del software

• Tali affermazioni possono riguardare come si deve comportare (requisiti funzionali), ed altre affermazioni sul software ovvero del prodotto software (requisiti non funzionali)

• Ma per essere requisiti, tali affermazioni dovrebbero possedere almeno alcune caratteristiche!

Caratteristiche di un requisito (qualunque sia la notazione)

• Grado di priorità• Grado di stabilità• Grado di rischio• Condiviso • Non ambiguo• Completo• Non in conflitto• Tracciabile• Verificabile• Manutenibile

•Traceability (IEEE) : the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another

•Traceability (ISO 8402) : is the ability to trace the history, application or location of an

entity by means of recorded identifications

ambiguo

ridondante inconsistente

incomprensibile

incompleto

espandere

sintetizzare

ridurre

spiegare

formalizzare

espandere

risolvere

Esistono affermazioni “perfette” per i requisiti?

formalizzare

Verification and Validation

assessing adequacy of test suite

assessing conformance to requirements

assessing completeness, consistency, impact analysis

assessing over- and under-design

investigating high level behaviour impact on detailed specifications

detecting requirements conflicts

checking consistency of decision making across the lifecycle

Maintenance

Assessing change requests

Tracing design rationale

Document access

ability to find information quickly in large documents

Process visibility

ability to see how the software was developed

provides an audit trail

Management

change management

risk management

control of the development process

Importanza della Tracciabilità

I requisiti hanno sempre un doppio ruolo

requisitoCommittente

Affermazione sufficientemente precisa, anche sufficientemente comprensibile al committente, giustificata in termini della sua richiesta

Affermazione sufficientemente precisa (cioè non ambigua), (direttamente) usabile da progettisti e sviluppatori e, talvolta, anche al committente

Progettisti,Sviluppatori, Committente

non contradditori

(verifica)

Esempio I: il doppio ruolo dei requisiti• Un utente deve poter inserire la

sua partenza e la sua destinazione, le ore ed i giorni di partenza e di arrivo

• E’ possibile effettuare una ricerca sui possibili treni esistenti secondo i seguenti criteri…..

RicercareutenteTreni

Cosa è più comprensibile per il Committente?

If Dest and Arr are available then Seleziona Treni tali che…

Cosa è necessario per rispondere adeguatamente alla richiesta del Committente?

Rif. Esempio Treno

Dest+Arr | Dest+Arr+Hp|Ha | …

Il requisito espresso in linguaggio comune pur astrattamente ambiguo

potrebbe essere accettabile se il committente e l’ingegnere dei requisiti sono d’accordo che questo rappresenta tutte le possibili situazioni ovvero

una qualunque situazione

Cosa è necessario affinché sia possibile progettare il software?

Esempio II: il doppio ruolo dei requisiti• Se un sensore non funziona, il

sistema dovrebbe fermare l’ascensore in funzione ai piani precedenti o successivi

• L’ascensore deve fermarsi se il sensore del piano selezionato rileva il passaggio dell’ascensore

Fermare&Partire

SensoriEv_ascensorepiano(x)

If Ev_ascensorepiano(x) and Direction=Down and ProssimaRichiesta(y) and x<y then Rallentare Motore;

…

If Ev_ascensorepiano(x) and ProssimaRichiesta(y) and x=y then Rallentare Motore;

…Rif. Esempio Ascensore

Il documento dei requisiti• In generale il documento dei requisiti raccoglie in

modo organizzato i requisiti determinati, descritti in una o più notazioni, ed anche informazioni ulteriori sulla richiesta del committente e su come la determinazione ha avuto luogo

• La forma di tale documento è generalmente standardizzata nella forma e nei contenuti dalla meteodologia adottata (anche perché spesso costituisce una base contrattutale)

• Tale standardizzazione può essere relativa alla metodologia specifica ovvero coincidere con uno standard di riferimento come ad esempio IEEE-830-1993

Il documento dei requisiti

Il documento dei requisiti contiene generalmente diagrammi e, collegate, affermazioni in linguaggio comune

La forma del modello analitico

• In generale una metodologia propone una forma del modello analitico che s’ispira all’uso di una o più notazioni, legate da regole più o meno precise

• Le metodologie si differenziano spesso in base alla tipologia delle notazioni usate (non alla notazione poiché si è detto che esistono notazioni diverse per DFD, DFD estesi, mentre per UML la notazione è adattabile ovvero si possono usare diverse notazioni per esprimere classi, scambio di messaggi etc.)

(Analisi Strutturata)

Modello Object-Oriented di Analisi (Esempio)

Classi (attributi ed operazioni)

Diagrammi di Sequenza

Casi d’Uso

Statecharts

Quali requisiti vengono specificati• I requisiti sono di varia natura; i requisiti che vengono

specificati sono:– I requisiti funzionali– Parte dei requisiti non funzionali, se necessario

• I requisiti funzionali indicano tipicamente le funzionalità, i comportamenti, le proprietà ovvero le informazioni desiderati

• I requisiti non funzionali indicano talvolta delle proprietà desiderate che devono essere soddisfatte dal prodotto software; l’interesse per i requisiti non funzionali deve essere considerato nella specifica dei requisiti funzionali (ad esempio, nel caso ascensore, se il tempo di trattamento per richieste prioritarie deve essere inferiore a 0,01ms può obbligare a requisiti funzionali diversi)

Una tassonomia dei requisiti non funzionali

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements

Uso delle notazioni nella Ingegneria dei Requisiti

Metodi-Pratiche• Metodi/Pratiche che aiutano a trasformare una descrizione

testuale anche imprecisa in un diagramma (per estrarre, dedurre, etc. i requisiti)

• Metodi/Pratiche che aiutano a trasformare una notazione in un’altra (ed associati, Metodi/Pratiche che aiutano a verificare la eventuale “equivalenza”):– Per passaggio,– Per incremento.

• Metodi/Pratiche di analisi che aiutano a valutare la completezza e la correttezza di ciò che è stato rappresentato tramite un diagramma (per estrarre, dedurre, etc. i requisiti)

• Metodi/Pratiche per provare formalmente la relazione fondamentale (verificare)

Riepilogo: Notazioni UsateLinguaggio (notazione) Uso

Diagramma dei casi d’uso Scenari

DFD Funzioni

DFD di contesto Funzione

DFD ed ER Funzioni e Dati

DFD Estesi (con Statechart) Comportamento

Statechart Comportamento

Diagramma delle classi Oggetti concettuali

Diagramma di sequenza Interazioni degli oggetti (concettuali)

Sistematizzazione dei passaggi usati negli esempi (Metodi-Pratiche)

• Che abbiamo usato:– DFD --- DFD– Un caso d’uso (passo) --- una funzione (Treno)– Un caso d’uso --- uno stato (Ascensore)– Un caso d’uso --- una transizione di stato (Ascensore)– Una condizione --- un evento (Ascensore)– Statechart --- DFD estesi (Ascensore)– Statechart --- casi d’uso (Ascensore)

Un passaggio è tipicamente caratterizzato dal fatto che

la rappresentazione da cui si parte è SOSTITUITA

dalla nuova rappresentazione

Modello Object-Oriented di Analisi (Esempio)

Classi (attributi ed operazioni)

Diagrammi di Sequenza

Casi d’Uso

Statecharts

Cosa è stato fatto nell’esempio dell’ascensore

Partire

Sensore Piano

Piano

numero

Pulsante

StatoTempo di reazioneDirezioneData controllo

Porta

SensoreTipoStatoTempo di reazioneData controllo

classe: una tipologia di oggetti, con

propri attributi ed operazioni

nomeclasse

attributi

Fermare

Cabina

Richiesta

Leggendo i passi

Cosa è stato fatto nell’esempio dell’ascensore

: Partire

7: dimmi i pulsanti da illuminare()

2: richiesta da servire()

3: qual è peso corrente()

11: qual è peso corrente

12: porte chiuse?()

ilmotore : Motore

4: avviaremotore()

: Richesta

5: confermati come da servire()

13:

14: confermati come da servire

15: illuminare ("INARRIVO")

6:

: Pulsante

8: Illuminare()

9:

ilgestoredell...

1: porte chiuse()

: RichiestaInterna

10: primarichiesta()

Visual Paradigm for UML Standard Edition(Universita di Torino)

Partire

Leggendo i passi

Pulsante

StatoTempo di reazioneDirezioneData controllo

illuminare( )spegnere()

Leggendo l’operazione

operazioni

Cosa è stato fatto nell’esempio dell’ascensore

Sensore Piano 11..*

Pianonumero

1

Pulsante

StatoTempo di reazioneDirezioneData controllo

illuminare( )spegnere()

Porta

SensoreTipoStatoTempo di reazioneData controllo

1

1

classe: una tipologia di oggetti, con

propri attributi ed operazioni

associazione

attributi

Cabina

Richiesta

1

1

0..1

0..1

0..1

: Partire

7: dimmi i pulsanti da illuminare()

2: richiesta da servire()

3: qual è peso corrente()

11: qual è peso corrente

12: porte chiuse?()

ilmotore : Motore

4: avviaremotore()

: Richesta

5: confermati come da servire()

13:

14: confermati come da servire

15: illuminare ("INARRIVO")

6:

: Pulsante

8: Illuminare()

9:

ilgestoredell...

1: porte chiuse()

: RichiestaInterna

10: primarichiesta()

Visual Paradigm for UML Standard Edition(Universita di Torino)

Cosa è necessario per eseguire l’operazione “dimmi quali sono i pulsanti da illuminare”

cardinalità

Sistematizzazione dei passaggi nel caso del modello di analisi object-

oriented (Metodi-Pratiche)• Che abbiamo usato:

– Casi d’uso (passo) --- classi, attributi– Casi d’uso --- sequenza– Sequenza --- classi e operazioni– Precondizioni --- messaggi (operazioni)

• Che si possono usare:– Sequenza --- Statechart– Statechart --- classi, Statechart

Sistematizzazione degli incrementi modello di analisi object-oriented

(ordinati) (Metodi-Pratiche)Che abbiamo usato:

– Operazioni --- associazioni, attributi

Che si possono usare:– Classe --- Statechart– Classe --- Classe– Classe --- associazioni– Classe --- attributi

Un incremento è tipicamente caratterizzato dal fatto che

la rappresentazione da cui si parte è COMPLETATA

dalla nuova rappresentazione

Sistematizzazione degli incrementi modello di analisi object-oriented

(ordinati) (Metodi-Pratiche)

Diagramma delle Classi

Diagramma Casi d’Uso Diagrammi Sequenza

incrementare

Relazione tra Ingegneria dei Sistemi ed Ingegneria dei Requisiti

Sistema(i), requisiti del software: una visione d’insieme

Diminuire le code

Cercare, Prenotare, Pagare etc.Ricerca

Prenotazione

Con quale sistema?

Con quale software?

Requisiti del software

Requisiti del sistema ove sistema = software +

ambiente del software

Rif. Esempio Treno

Sistema e Requisiti del Software:relazione fondamentale

(Requisiti del Software AND Ipotesi sull’ambiente circostante il Software)SODDISFARequisiti del Sistema

dove:

Sistema=Software+Ambiente circostante al software

Provare formalmente? (= Verificare)

Treno

(Requisiti del Software: Casi d’uso

AND

Ipotesi sull’ambiente circostante il Software: almeno il 5% dei clienti possiede una carta di credito AND …)

SODDISFA

Requisiti del Sistema: le code devono diminuire del 10% rispetto alla situazione attuale)

Treno

(Requisiti del Software: Casi d’uso

AND

Ipotesi sull’ambiente circostante il Software: almeno il 5% dei clienti possiede una carta di credito AND almeno il 30% dei clienti abituali userà il software AND …)

SODDISFA

Requisiti del Sistema: le code devono diminuire del 10% rispetto alla situazione attuale)

Ascensore

(Requisiti del Software: casi d’uso + statechart + DFD esteso (formalizzabile)

AND Ipotesi sull’ambiente circostante il Software: statechart

dei vari dispositivi o software circostanti al software da sviluppare) (formalizzabile)

SODDISFARequisiti del Sistema: in condizioni normali di

operatività, se un utente preme il pulsante, l’ascensore arriva mediamente in 1’ (proprietà formalmente esprimibile)

Organizzazione della Ingegneria del Sistema e dei Requisiti

Desiderata del sistema

Estrarre

Requisiti del sistema Soddisfare

Estrarre, dedurre, etc.

Ipotesi ambiente del software

Requisiti del software

Ingegneria di sistema

Ingegneria dei requisiti

Richiesta del committente

Ascensore: un caso d’Ingegneria di Prodotto

• L’ingegneria di prodotto (una tipologia di ingegneria dei sistemi) si pone come finalità la costruzione di un prodotto nel perseguimento di determinati obiettivi

• Il punto chiave è la definizione e la valutazione delle alternative per sviluppare il prodotto

• Ad esempio, nel caso dell’ascensore è importante dare una risposta ai seguenti quesiti: quanti sensori è necessario avere, quale manutenzione dei componenti dovrebbe essere messa in opera, quante cabine devono essere disponibili etc.

Ingegneria di Processo• Pressman propone come

esempio di sistema industriale un sistema d’instradamento di scatole su nastro trasportatore

• Come decidere su qual è il software da sviluppare?

get conveyor speed

send shunt

control data

get shunt status read bar code

start conveyor line

determine bin location

valid bar code

set f or reject bin

conveyor in motion

read bar code

get conveyor status

produce report entry

conveyor stopped

invalid bar code

Diagramma attività (UML)

Capitoli del Pressman per Ingegneria dei Requisiti – e dei Sistemi -

• 5, 6, 7, 8 (alcuni paragrafi verranno trattati in dettaglio più avanti parlando di test)

• Tranne 5.3, 5.4.2, 5.5, 5.6