Ingegneria dei Requisiti (Requirements Engineering)

1
Ingegneria dei Requisiti(Requirements
Engineering)
Paolo Giorgini http//www.dit.unitn.it/pgiorgio
2
Progetti Software

• Tuttavia del 26 non tutti sono esenti da
  problemi
• Denver Airport più di 50 milioni di US per
  errori del sistema di controllo dei bagagli
• London Ambulance Service il sistema è stato
  disattivato dopo un giorno di funzionamento

3
Tom De Marco

• Il 56 degli errori di un software
  possono essere
  riferiti ai requisiti
• Durante lo sviluppo di un software, più tardi un
  errore viene rilevato più costoso sarà risolverlo
  
• Molti errori sono fatti durante la raccolta e
  lanalisi dei requisiti
• Molti errori relativi ai requisiti possono (e
  devono) essere rilevati il prima possibile
• Errori tipici uso di fatti non corretti,
  omissioni, inconsistenze e ambiguità
• Errori nella specifica dei requisiti sono uno dei
  problemi principali per lindustria software

4
Costi
5
in Europa

• Un questionario inviato a 3.805 società ha
  rilevato
• Per gli analisti I problemi principali sono
• Specifica dei requisiti (53)
• Gestione dei requisiti (43)
• Ducomentazione (36)
• Test (35)

6
Definizione

• Lingegneria dei requisiti è una sotto area
  dellingegneria del software che studia il
  processo di definizione dei requisiti del sistema
  da realizzare.
• E una nuova area che ha avuto origine nel 1993
  con the 1st International Symposium on RE Ora
  siamo alla 12 edizione.
• Il processo di definizione dei requisiti è
  uninterfaccia tra i desideri (o bisogni) dei
  clienti e la realizzazione dei questi requisiti
  come sistema software

7
unaltra definizione

• Lingegneria dei requisiti è
• Lo sviluppo e luso di tecnologie per
  raccogliere, specificare e analizzare i requisiti
  degli utenti/clienti (stakeholders) che saranno
  poi realizzati da un sistema software

8
Fred Brooks

• The most difficult part of building a software
  system is 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 difficult to fix
  later.

9
Breve storia

• Requriements Engineering come disciplina 1993
• RE (93, 95, 97, 99. 01)
• ICRE (94, 96, 98, 00)
• WER (98, 99, 00, 01)
• Requirements Engineering Journal
• Passato System Analysis
• Oggi A network of processes
• Pressione da parte del mercato per software di
  qualità
• Libri (Sommerville, Jackson, Loucopoulos, )
• Tools (Doors, Requisite-Pro, Caliber-RM)

10
Requisiti di sistema

• Definiscono che cosa un sistema deve fare e sotto
  quali vincoli deve operare, ad esempio
• Il sistema dovrà archiviare i dati di di una
  biblioteca, in particolare 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.
• Linterfaccia al sistema dovrà essere realizzata
  utilizzando un World-Wide-Web browser.
• Il sistema dovrà gestire almeno 20 transazioni
  per secondo
• Il sistema dovrà essere accessibile attraverso
  luso di password

11
Tipi di requisiti

• Requisiti Funzionali definiscono parte delle
  funzionalitaà del sistema
• Requisiti di implementazione come il sistema
  dovrà essere implementato
• Requisiti di prestazione specificano le
  prestazioni minime accettabili per il sistema
• Requisiti di usabilità specificano il tempo
  massimo per mostrare luso del sistema
• Requisiti non funzionali
• Esprimono vincoli sotto i quali il software dovrà
  operare
• Possono essere visti come qualità specifiche che
  il software dovrà avere (come il software
• Requisiti-1
• Condizioni che non devono mai accadere
• Solitamente associati a requisiti non funzionali

12
Probelmi legati ai requisiti

• I requisiti non riflettono i reali bisogni dei
  clienti
• I requisit i sono inconsistenti e/o incompleti
• E costoso cambiare i requisiti dopo che sono
  stati definiti e concordati
• Possono esserci delle incomprensioni tra i
  clienti e chi a raccolto e anlizzato i requsiti,
  tra chi ha raccolto i requisiti e il prgettista,
  e tra il progettista e chi realizzerà il sistema.

13
Un esempio di incompletezza

• Il sistema dovrà permettere agli utenti di fare
  delle ricerche per titolo, autore, o ISBN.
• Che cosa significa per i CD-ROM?
• Possono non avere un ISBN
• Vale solo per i libri
• Immaginate se realizzate il sistema con questo
  requisito senza considerare i CD-ROM.
• Naturalmente non possiamo scrivere requisiti
  universali, ma possiamo tentare di essere il più
  possibile completi.

14
Determinazione dei requisiti

• Fornire una definizione informale dei requisiti,
  funzionali e non
• Generalmente in questa fase si parla anche di
  servizi attesi dal sistema e vincoli a cui deve
  sottostare
• Lattività di raccolta dei requisiti è svolta da
  un analista di business (o di sistema)
  utilizzando tecniche diverse, che possono
  spaziare dalle tradizionali interviste ai clienti
  andando (se necessario) fino alla costruzione di
  prototipi.
• Analisi delle duplicazioni e contraddizioni
• Revisioni e rinegozazione dei requisiti
• Documento dei requisiti

15
Raccolta dei requisiti

• Discussione con clienti e esperti del dominio
• Esperti del dominio ? conoscenza del dominio
• Clienti ? requisiti (casi duso)
• Casi duso e conoscenza del domino devono essere
  integrati

16
Metodi di raccolta requisiti

• Tradizionali
• Interviste
• Questionari
• Osservazioni
• Studio dei docuemnti e dei sistemi software
• Metodi moderni
• Prototipi
• Sviluppo cooperativo delle applicazioni
• Sviluppo rapido delle applicazioni

17
Interviste

• Condotte principalemnte con i clienti (anche gli
  esperti possono essere intervistati)
• Problemi
• Generalmente i clienti hanno solo una vaga idea
  dei requisiti del sistema e non sono in grado di
  esprimerli
• Possono anche richiedere funzionalità che vanno
  fuori i costi e gli obiettivi del progetto
• Possibili conflitti
• Due tipi di intervista
• Strutturata (formali)
• Non strutturate (informali)

18
Interviste

• Strutturate
• Preparate in anticipo
• Unagenda
• Domande predeterminate (aperte o chiuse)
• Sono generalemnte accompagnate da interviste
  informali (non strutturate)
• Non strutturate
• Incontri informali
• Senza domande anticipate o obiettivi prederminati
• Incoraggiare il cliente a parlare di ciò che ha
  in mente, su cui lanalista potrebbe non aver
  riflettuto
• Per entrambe si parte da un contesto di
  discussione (ad esempio un breve documento
  inviato in anticipo)

19
Doamnde da evitare

• Domande sulle quali lintervistatore esprime
  (direttaemnte o indirettamente) la propria
  opinione sul problema
• dobbiamo fare le cose nel modo in cui le
  facciamo?
• Domande prevenute, simili alle precedenti,
  eccetto che lopinione dellintervistatore è
  chiaraemnte espressa
• non intendi fare questo, vero?
• Domande contenenti già la risposta
• devi fare le cose in questo modo, non è vero?

Importante è ascoltare
20
Questionari

• In aggiunta alle interviste
• Sostituiscono le interviste quando il progetto è
  a basso rischio con obiettivi ben definiti
• Non è possibile chiarimenti sui quesiti e le
  risposte
• Vantaggi tempo per valutare la risposta, anonomi
• Svantaggi non cè la possibilità di discutere e
  approfondire i quesiti
• I quesiti dovrebbero essere chiusi (evitare i
  quesiti aperti)
• Tre tipi
• A scelta multipla
• A punteggio
• Con ordinamento

21
Osservazioni

• Ricerca di fatti attraverso losservazione
• Osservazione passiva lanalista osserva le
  attività senza interruzioni o coinvolgimento
  diretto del cliente che lavora (anche con
  videocamera).
• Osservazione attiva lanalista partecipa
  direttamente alle attività ed entra a far parte
  del gruppo di lavoro.
• Svolte per periodi lunghi e con differenti
  carichi di lavoro
• Difficoltà le persone tendono a comportarsi
  diversaemnte quando osservate

22
Studio dei documenti e dei sistemi software

• Importante per approfondire la conoscenza di
  dominio
• Documenti organizzativi modulustica aziendale
  (compilata, se possibile), descrizione delle
  procedure lavorative e delle politiche di
  intervento, piani di business, organigrammi,
  corrispondenza fra uffici, minute di incontri,
  registrazioni contabili, corrispondenza esterna,
  lamentele clienti, ecc.
• Moduli e rapporti di sistema schermate e
  rapporti computerizzati (con la relativa
  documentazione), manuali operativi di sistema,
  docuemntazione utente, documentazione tecnica,
  modelli di analisi di progetto, ecc.
• Libri, riviste, pacchetti proprietari (sistemi
  ERP) - internet

23
Negoziazione e validazione

• In parallelo alla raccolta dei requisiti
• Validazione e negoziazione fatta sul docuemnto
  dei requisiti (acquisiti)
• Revisione del documento
• Requisiti fuori dal contesto
• Matrice di dipendenza dei requisiti
• Priorità e rischi associati ai requisiti

24
Matrice di dipendenza
Requisito R1 R2 R3 R4
R1
R2 Conflitto
R3 Indipendenti Indipendenti
R4 Indipendenti Sovrapposto Sovrapposto

• Conflitti discussi con i clienti
• Sovrapposti riscritti per eliminari le
  sovrapposizioni

25
Priorità e rischi associati ai requisiti

• Analisi del rischio identifica i requisiti che
  potrbbero causare difficoltà nello sviluppo
• Tipologie di rischio rischio tecnico, rischio di
  prestazione, rischio di sicurezza, rischio di
  integrità dei database, rischio nel processo di
  sviluppo, rischio politico, rischio legale,
  rischio di volatilità
• Valutazione della priorità permette al
  ritaratura del progetto rispetto ai ritardi (es.
  scaricando i requisiti con bassa priorità per
  rispettare tempi di progetto).
• Le priorità devono essere negoziate con incontri
  di gruppo tendo conto dei fattori di rischio

26
Modellizzazione dei casi duso (UML - Unified
Modeling Language)

• Attori venditore, cliente e magazzino

27
Casi duso

• Rappresentà ununità funzionale che fornisce
  valore ad un attore
• Un attore che non comunica con almeno un caso
  duso è privo dinteresse, mentre il contrario
  non è necessariamento vero
• Un caso duso che non comunica con alcun attore è
  permesso
• Esistono generalizzazioni o specializzazioni di
  casi duso
• Quali sono le responsabilità e le aspettative
  dellattore verso il sistema?
• Spesso un caso duso corrisponde ad un requisito
  funzionali

28
Acquisti online (requisiti)

• (R1) Il cliente usa la pagina web del produttore
  per vedere la configurazione standard del
  computer (server, desktop, portatile) scelto. Il
  prezzo è esplicitamente mostrato
• (R2) Il cliente sceglie di vedere i dettagli
  della configurazione, per lacquisto oppure per
  definire unaltra configurazione più adatta. Il
  costo di qualunque configurazione può essere
  calcolato su richiesta del cliente
• (R3) Il cliente può scegliere di ordinare il
  computer direttamente online oppure può
  richiedere un incontro con il venditore prima di
  confermare lordine, per ottenere maggiori
  spiegazioni sui dettagli dellordine, una
  negoziazione del costo, etc.
• (R4) Per ordinare, il cliente deve riempire
  online un modulo con i dettagli della spedizione,
  lindirizzo di fatturazione, e i dettagli di
  pagamento (carta di credito o assegno)
• (R5) Dopo che lordine del cliente è stato
  inviato e confermato, il venditore invia
  elettronicamente una richiesta al magazzino con i
  dettagli della configurazione ordinata
• (R6) I dettagli della transazione, compresi un
  numero dordine e un numero cliente, sono inviati
  via e-mail al cliente, permettendo a questultimo
  di controllare lo stato dordine
• (R7) Il magazzino riceve la fattura dal venditore
  e spedisce il computer al cliente

29
Acquisti onlineAssegnazione dei requisiti ad
attori e casi duso
Requisito Attore Caso duso
R1 Cleinte Mostrare configurazione Computer Standard
R2 Cliente Costruire Configurazione Computer
R3 Cliente, Venditore Ordinare Computer configurato, richiedere contatto commerciale
R4 Cliente Ordinare Computer configurato, verificare e accettare pagamento cliente
R5 Venditore, Magazzino Informare magazzino su ordine
R6 Cliente, Venditore Ordinare computer configurato, aggiornare stato ordine
R7 Venditore, Magazzino Stampare fattura
30
Casi duso
31
Diagramma dei casi duso
32
Altri esempi
Inserire Piano di Studi include sempre
Convalidare piano di studi ogniqualvolta il
piano di studi è inserito, deve essere anche
convalidato
33
ancora
Generalizzazione Il manager Servizi clienti è un
tipo di Impiegato Servizi Cliente il quale, a sua
volta, è un tipo di Impiegato
34
Documento dei requisiti

• 1. Premessa
• 1.1 Obiettivo e scopo del prdotto
• 1.2 Contesto di business
• 1.3 Stackeholders
• 1.4 Soluzioni preliminari
• 1.5 Sintesi del docuemnto
• 2. Servizi del sistema
• 2.1 Scopo del sistema
• 2.2 Requisiti funzionali
• 2.3 Requisiti non funzionali
• 3. Vincoli di sistema
• 3.1 Requisiti di interfaccia
• 3.2 Requisiti di presentazione
• 3.3 Requisiti di sicurezza
• 3.4 Requisiti operativi
• 3.5 Requisiti politici e legali
• 3.6 Altri vincoli
• 4. Aspetti progettuali
• 4.1 Problemi aperti