Post on 01-May-2015
transcript
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