"**:T** *0*******************(*S* YMl* **(
Download
Report
Transcript "**:T** *0*******************(*S* YMl* **(
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
Comprensione
Modellazione
Analisi
•L’ascensore deve fermarsi se il sensore del
piano selezionato rileva il passaggio
dell’ascensore
Movimento
Convalida
Negoziazione
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)
Controllo Porte
Stato porte =
aperta|chiuse+tempo
Sensore
Approccio
Piano
chiuse
Ev_aprireporte(x)
Ev_chiudereporte(x)
Ev_portechiuse(x)
Ev_pianoascensore(x)
Ev_fermopianoascensore(x)
Sistema Meccanico fermo al piano
stato
Movimento
Prossima richiesta
tempo
pianocorrente
nuovopianocorrente
timer
Richieste
Utente
Stato Ascensore (piano
ascensore)
richiestenonordinate
ordina
richiesteordinate
ABILITA
richiesta
Gestione richieste
Ev_pulsantepremuto(x)
Ev_illumina
Pulsanti
Ev_disabilita(x)
Richieste da
Servire
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
può riusare o riferirsi
Comprensione
Requisiti
Linguaggio
(Collezione +
Modello
Comune
Documento dei Requisiti)
Modellazione
Analisi
Convalida
Negoziazione
Verifica
devono essere non contradditori
(verifica)
Prototipo (*)
(*) dipende dal processo
Modellazione
Modello dei Requisiti
o
Modello
Specifica dei Requisiti)
Linguaggio
(Modello Analitico
Comune
Notation
Informale
Structured
natural
language
Design description
languages
Graphical
Semi-Formale
notations
Mathematical
specifications
Formale
Description
This approach depends on defining standard forms or templates to
express the requirements specification.
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.
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.
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 combinazione
Notazioni alternative per la
specifica dei requisiti e la
determinazione dei requisiti
Esempio
Fermare
Descritto come
Spegnere i pulsanti
(una passo del
Descritto come
caso d’uso)
Descritto come
Partire (una caratteristica del
sistema)
traced to (from)
I problemi del linguaggio comune
per esprimere i requisiti
• 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
Esempio di misure di qualità dei
requisiti scritti in linguaggio comune
Imperatives
Directives
identified by words such as “shall”,
indicated by tables, figures etc
“must”, “is required”, etc.
these strengthen the quality of the
Imperatives measure how explicit
document
a requirement document is.
Size
Continuances follow an imperative and
in terms of lines of text, indicators
introduce requirements
and subjects
indicated by “below:”, “as follows:”
roughly, the number of subjects for all
etc.
the imperatives
measure the structure of an a
Text structure
requirement document.
measures the number of statement
Option
identifiers
indicated by words such as “can”,
Specification depth
“may”, “optionally” etc.
measures how deep are the subsections
measure how much latitude does
of the a requirement document
a requirement document leave
gives an indication of a requirement document
structure.
Weak phrases
cause uncertainty
e.g. “adequate”, “as applicable” etc.
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 predecessorsuccessor 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
Esistono affermazioni “perfette”
per i requisiti?
espandere
ambiguo
espandere
sintetizzare
formalizzare
ridondante
inconsistente
spiegare
ridurre
incomprensibile
formalizzare
incompleto
risolvere
Importanza della Tracciabilità
Verification and Validation
assessing adequacy of test suite
assessing conformance to requirements
assessing completeness, consistency,
impact analysis
assessing over- and under-design
Assessing change requests
Tracing design rationale
Document access
ability to find information
quickly in large documents
Process visibility
ability to see how the software
investigating high level behaviour impact on was developed
detailed specifications
provides an audit trail
detecting requirements conflicts
Management
checking consistency of decision making
change management
across the lifecycle
risk management
Maintenance
control of the development
process
I requisiti hanno sempre un
doppio ruolo
requisito
Committente
Affermazione
sufficientemente
precisa, anche
sufficientemente
comprensibile al
committente,
giustificata in
termini della sua
richiesta
non contradditori
(verifica)
Progettisti,
Sviluppatori,
Committente
Affermazione
sufficientemente
precisa (cioè non
ambigua),
(direttamente)
usabile da progettisti
e sviluppatori e,
talvolta, anche al
committente
Esempio I: il doppio ruolo dei requisiti
Cosa è più
comprensibile per il
Committente?
• 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…..
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
per rispondere
adeguatamente alla
richiesta del
Committente?
Dest+Arr |
Dest+Arr+Hp|Ha | …
utente
Cosa è necessario
Rif. Esempio Treno affinché sia possibile
progettare il software?
Ricercare
Treni
If Dest and Arr are
available then Seleziona
Treni tali che…
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
If Ev_ascensorepiano(x) and
Direction=Down and
ProssimaRichiesta(y) and
x<y then Rallentare Motore;
…
Ev_ascensorepiano(x)
Sensori
Rif. Esempio Ascensore
Fermare&
Partire
If Ev_ascensorepiano(x) and
ProssimaRichiesta(y) and
x=y then Rallentare Motore;
…
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)
Casi d’Uso
Diagrammi di Sequenza
Classi
(attributi ed operazioni)
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
Non-functional
requir ements
Product
requir ements
Ef ficiency
requir ements
Reliability
requir ements
Usability
requirements
Performance
requirements
Or ganizational
requir ements
Portability
requirements
Delivery
requirements
Space
requir ements
External
requirements
Interoperability
requirements
Implementation
requir ements
Ethical
requirements
Standards
requirements
Legislative
requirements
Privacy
requirements
Safety
requirements
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 Usate
Linguaggio (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)
Casi d’Uso
Diagrammi di Sequenza
Classi
(attributi ed operazioni)
Statecharts
Cosa è stato fatto nell’esempio
dell’ascensore
Leggendo i
passi
Fermare
Partire
nomeclasse
Cabina
Sensore
Tipo
Stato
Tempo di reazione
Data controllo
Pulsante
Stato
Tempo di reazione
Direzione
Data controllo
Piano
numero
classe: una
tipologia di
oggetti, con
propri attributi
ed operazioni
Sensore Piano
Richiesta
Porta
attributi
Cosa è stato fatto nell’esempio
dell’ascensore
Partire
Pulsante
Stato
Tempo di reazione
Direzione
Data controllo
illuminare( )
spegnere()
operazioni
Leggendo
l’operazione
Leggendo i
passi
Cosa è stato fatto nell’esempio
dell’ascensore
Cosa è necessario per eseguire l’operazione
“dimmi quali sono i pulsanti da illuminare”
cardinalità
Cabina
Sensore
Tipo
Stato
Tempo di reazione
Data controllo
Pulsante
1
1
0..1
illuminare( )
spegnere()
associazione
1 1
classe: una
tipologia di
oggetti, con
propri attributi
ed operazioni
Sensore Piano
Stato
Tempo di reazione
Direzione
Data controllo
Piano
numero
1
1..*
0..1 0..1
1
Richiesta
Porta
attributi
Sistematizzazione dei passaggi nel
caso del modello di analisi objectoriented (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
incrementare
Diagramma Casi d’Uso
Diagrammi Sequenza
Relazione tra Ingegneria dei Sistemi
ed Ingegneria dei Requisiti
Sistema(i), requisiti del software:
una visione d’insieme
Rif. Esempio Treno
Diminuire le code
Con quale
software?
Ricerca
Prenotazione
Requisiti del
software
Cercare,
Prenotare,
Pagare etc.
Con quale
sistema?
Requisiti del sistema
ove sistema =
software +
ambiente del software
Sistema e Requisiti del Software:
relazione fondamentale
(Requisiti del Software
AND
Ipotesi sull’ambiente circostante il Software)
SODDISFA
Requisiti del Sistema
dove:
Provare formalmente? (= Verificare)
Sistema=Software+Ambiente circostante al software
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)
SODDISFA
Requisiti 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
Richiesta del committente
Desiderata del sistema
Ingegneria
di sistema
Estrarre
Requisiti del sistema
Soddisfare
Estrarre, dedurre, etc.
Ipotesi ambiente del
software
Requisiti del software
Ingegneria
dei
requisiti
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?
st art c onv ey or line
get c onv ey or speed
read bar c ode
valid bar code
invalid bar code
det er m ine bin loc at ion
Diagramma
attività (UML)
set f or rejec t bin
send shunt
c ont rol dat a
get shunt st at us
get c onv ey or st at us
read bar c ode
produc e report ent ry
conveyor st opped
conveyor in m ot ion
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