Ingegneria dei Requisiti
Outline
y Ingegneria dei requisiti
y Tipologie di Requisiti
Ti l i di R
i ii
y Attività per la raccolta dei requisiti
y Documento di Analisi dei requisiti
Software Lifecycle Activities
y
Requirements Requirements System
Elicitation
Design
Analysis
Expressed in
Terms Of
Structured By
Object
Design
Implementation
Implemented
By
y
Realized By
Verified
By
class...
class...
class...
Use Case
Model
Testing
Application
pp
Implementat
SubSystems
Domain
ion Domain
Objects
Objects
Source
Code
?
class.... ?
Test
Cases
R
Requisiti software
iii f
y Requisiti di un sistema software:
R
i i i di i
f
Cosa deve fare il sistema + Vincoli operativi
y Esempi: p
y Il sistema dovrà archiviare i dati di di una biblioteca, in particolare y
y
y
y
dati relativi ai libri, ai giornali, le riviste, video, nastri audio e CD‐
ROM. Il sistema dovrà permettere agli utenti di fare delle ricerche per titolo, autore, o ISBN.
L’interfaccia al sistema dovrà essere realizzata utilizzando un World‐Wide‐Web browser.
Il i t
Il sistema dovrà gestire almeno 20 transazioni per secondo
d à ti l
t
i i d
Il sistema dovrà essere accessibile attraverso l’uso di password
Requirement
q
Engineering
g
g
y L’ingegneria dei requisiti comprende tutte le attività che si occupano di requisiti:
y Raccolta dei requisiti
y Analisi dei requisiti
A li i d i i iti
y Documentazione dei requisiti
y Verifica e Validazione dei requisiti
V ifi V lid i
d i i iti
Fred Brook’s
“The most difficult part of building a software system is to decide precisely what must be built No other part to decide, precisely, what must be built. No other part of the work can undermine so badly the resulting software if not done correctly No other part is so software if not done correctly. No other part is so difficult to fix later.”
Requirement
q
Engineering
g
g ((2))
y La raccolta dei requisiti è l’attività più difficile, perché richiede la collaborazione tra più gruppi di partecipanti con differenti background.
y Stakeholders: tutte le persone in qualche modo p
q
interessate alla messa in opera del sistema
y Il cliente e gli utenti finali sono esperti nel loro dominio e hanno una idea generale (e in molti casi vaga) di cosa il h
id l ( i lti i ) di il sistema debba fare, e poca esperienza nello sviluppo del software
y Gli sviluppatori hanno esperienza nel produrre sistemi software, ma hanno una conoscenza limitata del d i i di dominio di applicazione (ambiente degli utenti finali)
li i
( bi t d li t ti fi li)
Requirement
q
Engineering
g
g ((3))
y Tutti gli stakeholders comunicano tra di loro per definire il sistema da realizzare.
y Fallimenti nella comunicazione (tra i diversi domini) portano a un sistema difficile da usare o che non supporta le funzionalità richieste
y Gli errori introdotti in questa fase sono difficili (e costosi) da risolvere perché sono scoperti nelle ultime fasi del processo di sviluppo del software
y Errori possibili:
y una funzionalità che il sistema dovrebbe supportare non è specificata;
ifi t
y funzionalità incorrette o obsolete;
y interfacce utenti poco intuitive e difficile da usare.
p
Livello di dettaglio
g
y Possono espressi a vari livelli di astrazione e formalismo, dando luogo a 2 tipologie di requisiti:
y Requisiti Utente
y Descrivono i servizi richiesti al sistema (comportamento
osservabile dall’esterno) e i vincoli operativi del sistema. y Scritti in linguaggio naturale.
y Il punto di vista è quello del Cliente, che li sottopone a un possibile Sviluppatore per ottenere una offerta (requisiti aperti a soluzioni alternative)
l
i )
y Requisiti di Sistema
y Formulazione dettagliata, strutturata, di servizi e vincoli. y Scritti in linguaggio naturale, notazioni semi‐formali, linguaggi formali
y Il punto di vista è quello dello Sviluppatore, che li puo’ usare anche per il contratto con il Cliente (requisiti piu’
il il Cli
(
i i i i ’ restrittivi)
i i i)
Un req. utente Î molti req. di sistema
Requirements definition
(one user requirement)
1. The software must provide a means of repr esenting and
1 accessing
1.
i external
t
l files
fil created
t d by
b other
th tools.
t l
p
into some system
y
requirements)
q
)
Requirements specification ((expanded
1.1 The user should be provided with facilities to define the type of
1.2 external files.
1 2 Each
1.2
E h externall file
fil type may have
h
an associated
i d tooll which
hi h may be
b
1.2 applied to the file.
1.3 Each external file type may be represented as a specific icon on
1.2 the user’s display.
p y
1.4 Facilities should be provided for the icon repr esenting an
1.2 external file type to be defined by the user.
1.5 When a user selects an icon repr esenting an external file, the
1 2 effect of that selection is to apply the tool associated with the type of
1.2
1.2 the external file to the file represented by the selected icon.
Tipi di requisiti
p
q
y I requisiti funzionali descrivono i servizi, o funzioni, offerti dal sistema (normalmente attivati da user‐inputs)
y “Quando l’utente richiede la visualizzazione dell’estratto conto… allora il sistema deve …”
y I requisiti non‐funzionali descrivono vincoli sui servizi I requisiti non funzionali descrivono vincoli sui servizi offerti dal sistema, e sullo stesso processo di sviluppo
y “La visualizzazione dell’estratto conto deve avvenire entro 4 secondi dalla sua richiesta secondi dalla sua richiesta” y I requisiti di dominio (funzionali e non‐funzionali) riflettono caratteristiche generali del dominio applicativo
y “L’accesso alla cassa continua da parte dell’addetto bancario al rifornimento deve avvenire secondo le consuete procedure di sicurezza a doppia‐chiave” Requisiti Funzionali
q
y Descrivono le interazioni tra il sistema e il suo ambiente indipendentemente dalla sua implementazione (l’ambiente include l utente e ogni altro sistema esterno) l’utente e ogni altro sistema esterno) y ESEMPIO
y SatWatch è un orologio da polso che visualizza l’orario nella località corrente SatWatch usa un sistema GPS per determinare la sua corrente. SatWatch
posizione ed una struttura dati interna per convertire la posizione in un orario.
y Le informazioni memorizzate in SatWatch e l’accuratezza della determinazione dell’orario non richiedono che il possessore effettui un reset dell’orario. SatWatch modifica l’orario e le informazioni visualizzate quando il possessore attraversa un’area di riferimento e un confine politico.
y SatWatch ha un display basato su due linee, in alto mostra l’orario (ora, minuti, secondi, zona), in basso la data (giorno, mese, anno).
y …
Requisiti Funzionali (2)
q
( )
y E’ fondamentale che i requisiti funzionali siano completi e coerenti
y Completi: devono indicare tutti i servizi richiesti dagli utenti
y Coerenti: i requisiti non devono avere definizioni contraddittorie
y Per sistemi grossi è difficile ottenere requisiti completi e coerenti
y I vari stakeholders hanno esigenze diverse, spesso in contrasto
Requisiti non funzionali
q
y Descrivono gli aspetti del sistema che non sono direttamente legati al comportamento (funzionalità) del g
p
(
)
sistema.
y ESEMPIO (SatWatch). Il tempo di risposta deve essere meno di 1 secondo
y
L’accuratezza deve essere entro un secondo
y
SatWatch deve essere disponibile 24 ore al giorno eccetto
dalle 2:00am‐ 2:01am e 3:00am‐3:01am
y
y Includono una grande varietà di richieste che si riferiscono
a diversi aspetti del sistema, dall’usabilità alle performance
y Varie
V i classificazioni
l ifi i i (Sommerville, Furps+, etc…)
(S
ill F
)
Tipi di requisiti non‐funzionali
Non-functional
requirements
Efficiency
requirements
Reliability
requirements
Usability
requirements
Performance
requirements
Portability
requirements
Delivery
requirements
Space
requirements
External
requirements
Organizational
requirements
Product
requirements
Interoperability
requirements
Implementation
requirements
Ethical
requirements
Standards
requirements
Legislative
requirements
Privacy
requirements
Safety
requirements
Requisiti non Funzionali: Il modello Requisiti
non Funzionali: Il modello
FURPS+
y Chiamati anche requisiti di qualità, sono:
y Usabilità
y facilità per l’utente di imparare ad usare il sistema, e capire il suo funzionamento. Includono: y
y
y
convenzioni adottate per le interfacce utenti portata dell’Help in linea
livello della documentazione utente.
y Affidabilità
y capacità di un sistema o di una componente di fornire la funzione richiesta sotto certe condizioni e per un periodo di tempo. I l d
Includono: y
y
y
un accettabile tempo medio di fallimento l’abilità di scoprire specificati difetti
o di sostenere specificati attacchi alla sicurezza. di t
ifi ti tt hi ll i
Requisiti non Funzionali: Il modello Requisiti
non Funzionali: Il modello
FURPS+
y Performance
y riguardano attributi quantificabili del sistema come y tempo di risposta, quanto velocemente il sistema reagisce a input utenti d
l
l
y throughput, quanto lavoro il sistema riesce a realizzare entro un tempo specificato
y disponibilità, il grado di accessibilità di una componente o del sistema di
ibilità il d di ibilità di t d l i t
quando è richiesta
y Supportabilità
y Riguardano la semplicità di fare modifiche dopo il deployment. Includono
y adattabilità, l
adattabilità l’abilità di cambiare il sistema per trattare concetti abilità di cambiare il sistema per trattare concetti addizionali del dominio di applicazione
y mantenibilità, l’abilità di cambiare il sistema per trattare nuove g
p
tecnologie e per far fronte a difetti Pseudo requisiti: Il modello FURPS+
q
y Chiamati anche vincoli, sono:
y Implementazione
p
y vincoli sull’implementazione del sistema, incluso l’uso di tool specifici, linguaggi di programmazione, o piattaforme hardware
y Interfacce
y vincoli imposti da sistemi esterni, incluso sistemi legacy e formati di scambio
y Operazioni
Ope a o
y vincoli sull’amministrazione e sulla gestione del sistema y Packaging
y vincoli sulla consegna reale del sistema
y Legali
y riguardano licenze, regolamentazioni, e certificazioni
Requisiti di qualità per SatWatch
q
q
p
y Ogni utente che è in grado di leggere un orologio digitale e capire le abbreviazione relative alle zone geografiche dovrebbe essere capace di usare SatWatch (Usabilità)
y Poiché SatWatch non ha bottoni, nessun fallimento che richiede di risettare l’orologio deve verificarsi (Affidabilità)
y SatWatch dovrebbe visualizzare la zona geografica corretta g g
entro 5 minuti dalla fine di un periodo di blackout del sistema GPS (Performance)
y SatWatch dovrebbe visualizzare correttamente il tempo in tutte le 24 zone di tempo (Performance) Verificabilità di requisiti non Verificabilità
di requisiti non
funzionali
y Goal (non verificabile)
y ‘Il sistema deve essere facile da usare per controllori ‘Il i t
d f il d t ll i esperti, e deve essere tale da minimizzare gli errori degli utenti
utenti’
y Requisito non‐funzionale (verificabile) y ‘controllori esperti devono poter imparare a usare tutte controllori esperti devono poter imparare a usare tutte le funzioni del sistema in max. 2 ore di apprendimento. y Dopo l
Dopo l’apprendimento
apprendimento, il controllore deve essere in il controllore deve essere in grado di operare senza commettere piu’ di 2 errori al giorno’.
Quantificazione di requisiti non‐funzionali
Property
Speed
Size
E
Ease
off use
Reliability
Robustness
R b t
Portability
P t bilit
Measure
Processed transactions/second
User/Event response time
Screen refresh time
K Bytes
Number of RAM chips
T i i time
ti
Training
Number of help frames
Mean time to failure
Probability
P b bilit off unavailability
il bilit
Rate of failure occurrence
Availability
Time
Ti to
t restart
t t after
ft failure
f il
Percentage of events causing failure
Probability of data corruption on failure
Percentage
P
t
off target
t
t dependent
d
d t statements
t t
t
Number of target systems
Conflitti fra requisiti non‐funzionali
q
y Esempio: Sistema di rilevamento pattume spaziale
sullo Shuttle
y Req.1 ‐ System should fit into 4Mbytes of memory
y Req.2 ‐
R
System should be written in ADA
S t h ld b itt i ADA
y Puo’ risultare
P ’ i l
i
impossibile
ibil compilare
il
un programma
ADA con le funzionalià richieste, e che occupi solo 4Mbytes: uno dei requisiti va escluso
Requisiti di dominio
q
y Si riferiscono a caratteristiche del sistema che derivano
da caratteristiche generali del dominio applicativo
yP
Problemi:
bl i
y A volte sono Requisiti impliciti: il Cliente li dà per scontati
t ti e non li
li esprime
i
esplicitamente: ma lo li it
t l Sviluppatore non lo sa…
y A volte sono Requisiti espliciti ma oscuri: Il Cliente
descrive requisiti utilizzando termini e concetti che lo pp
ignora…(Î
g
( Glossario))
Sviluppatore
Requisiti di dominio –
q
Esempi
p
y Gestione biblioteca
y ‘There shall be a standard user interface to all databases There shall be a standard user interface to all databases which shall be based on the Z39.50 standard’ y (Lo Standard è noto al personale della biblioteca, non (
p
,
agli sviluppatori)
y Controllo treno
y The deceleration of the train shall be computed as:
y
y
Dtrain = Dcontrol + Dgradient where Dgradient is 9.81ms2 * compensated h D di t i 8
* t d gradient/alpha and where the values of 9.81ms2 /alpha yp
are known for different types of train.
Vincoli per SatWatch
p
y Tutto il software associato a SatWatch, incluso il software di bordo, dovrà essere scritto usando Java, per software di bordo
dovrà essere scritto usando Java per conformarsi alla politica corrente della compagnia (Implementazione)
Validazione dei requisiti
q
y E’ un passo critico nel processo di sviluppo y I requisiti sono continuamente validati da cliente e utenti
q
y Di solito dopo l’analisi dei requisiti
y La validazione dei requisiti richiede di controllare
y Correttezza: una specifica è corretta se rappresenta C
ifi è accuratamente il sistema che il cliente richiede e che gli sviluppatori intendono sviluppare;
y Completezza: una specifica è completa se tutti i possibili C
l
f
l
bl
scenari per il sistema sono descritti, incluso i comportamenti eccezionali y Coerenza: se i requisiti non si contraddicono tra di loro
y Chiarezza: una specifica è chiara se non è possibile interpretare la specifica in due modi diversi
p
p
Criteri per la Validazione dei Criteri
per la Validazione dei
q
requisiti
y Realismo: y La specifica dei requisiti è realistica se può essere implementata t
tenendo conto dei vincoli
d t d i i
li
y Verificabilità:
y La specifica dei requisiti è verificabile se, una volta che il sistema è stato costruito test ripetuti possono essere delineati per dimostrare che il costruito, test ripetuti possono essere delineati per dimostrare che il sistema soddisfa i requisiti
y
Esempio di non verificabilità:
y Il prodotto dovrebbe avere una buona interfaccia –
p
Buono non definito
y Tracciabilità:
y Ogni funzione del sistema può essere individuata e ricondotta al corrispondente requisito funzionale.
y Include anche l’abilità di tracciare le dipendenze tra i requisiti, le funzioni del sistema, gli artefatti, incluso componenti, classi, metodi e attributi di oggetti
y È cruciale per lo sviluppo di test e per valutare i cambiamenti Tipi di raccolta
p
dei requisiti
q
y Classificati sulla base della sorgente dei requisiti:
y Greenfield Engineering
g
g
y Lo sviluppo parte da zero, nessun sistema esiste in precedenza, così i requisiti sono “estratti” dagli utenti e dal cliente
y É guidata dalla necessità dell’utente o dalle esigenze del mercato
g
g
y Re‐engineering
y Un sistema esistente viene riprogettato a causa della disponibilità di g
p
nuove tecnologie o per estendere funzionalità del sistema
y Interface Engineering
y Per fornire i servizi di un sistema esistente in un nuovo ambiente
y Vengono riprogettate le interfacce y Sistemi legacy lasciati inalterati, eccetto che per le interfacce
y È guidata dall’introduzione di nuove tecnologie, e da nuove necessità del mercato