Syllabus REQB® Livello Foundation - Ita-Stqb

Sillabo
REQB®
Certified Professional for Requirements Engineering
Livello Foundation
Version 2.1
2014
I diritti di autore (copyright) di questa edizione del Sillabo, sono di REQB e ITA-STQB
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Storia delle modifiche
Versione
1.0
Data
Mar. 15, 2013
2.0
Mag. 20, 2013
3.0
2.1
Gen. 22, 2014
Dic. 01, 2014
Versione v2.1 - 2014
Pagina 2 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
Modifiche
Prima versione del Sillabo,
basata sulla versione inglese
v1.3.1 del 10.07.2011
Seconda versione del Sillabo,
basata sulla versione inglese
v1.3.1 del 10.07.2011.
Aggiornamenti rispetto al
Glossario e aggiunta Indice in
italiano
Correzione errori ortografici
Nuova versione del Sillabo,
basata sulla versione inglese
v2.1 del 09.02.2014, a cui viene
allineata la numerazione della
versione italiana
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Obiettivi
Il tema centrale di questo Sillabo è che la complessità dei sistemi e del software e la nostra
dipendenza da questi sono in continua crescita. Questo ci porta ad essere sempre più dipendenti
dall’avere software, hardware o altri prodotti privi di errori.
Requirements Engineering Qualifications Board (REQB) ha quindi deciso di creare uno standard
internazionale uniforme nell’area dell’Ingegneria dei Requisiti. Come per i linguaggi, anche per gli
standard, solo se si comprendono è possibile lavorare in modo efficiente ed efficace. Per creare un
linguaggio uniforme in questa importante area dell’Ingegneria dei Requisiti, esperti internazionali si
sono riuniti nel gruppo REQB e hanno sviluppato questo schema.
Autori della versione inglese
Requirements Engineering Qualifications Board Working Party Foundation Level (Edition 2013):
(Karolina Zmitrowicz (chair), Sergey Kalinov, Beata Karpińska, Andrey Konushin, Salvatore Reale,
Alexander Lindner, Ingvar Nordström, Alain Ribault)
Versione italiana



Autore della traduzione italiana: Cristina Sobrero
Revisore: Fabio Milanese
Approvato da ITA-STQB Steering Committee: Gualtiero Bazzana, Salvatore Reale, Marco Sogliani
Versione v2.1 - 2014
Pagina 3 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Indice dei Contenuti
Indice dei Contenuti ................................................................................................................................ 4
Introduzione ............................................................................................................................................ 5
1
Introduzione ai Requisiti ............................................................................................................... 11
Il Concetto di Requisito ........................................................................................................ 13
1.1.1 Il Concetto di Problema, Soluzione e Prodotto ............................................................... 13
1.1.2 Definizione e Classificazione dei Requisiti ....................................................................... 13
1.1.3 Attributi Comuni dei Requisiti ......................................................................................... 15
1.1.4 Qualità dei requisiti ......................................................................................................... 17
1.1.5 Ingegneria dei Requisiti, Gestione dei Requisiti e Sviluppo dei Requisiti ........................ 19
Standard e normative .......................................................................................................... 21
2
Contesto dell’Ingegneria dei Requisiti .......................................................................................... 23
2.1
Ingegneria dei Requisiti nel Contesto .................................................................................. 24
2.2
Processi Correlati ................................................................................................................. 26
3
Processo di Ingegneria dei Requisiti ............................................................................................. 27
3.1
Introduzione al Processo di Ingegneria dei Requisiti ........................................................... 28
3.2
Processo Generico di Ingegneria dei Requisiti ..................................................................... 29
3.3
Ruoli e Responsabilità .......................................................................................................... 33
4
Gestione dei Requisiti ................................................................................................................... 36
4.1
Introduzione alla Gestione dei Requisiti .............................................................................. 38
4.2
Gestione di Progetto e Gestione del Rischio ........................................................................ 39
4.3
Tracciabilità dei Requisiti ..................................................................................................... 43
4.4
Configuration Management e Change Management .......................................................... 45
4.5
Garanzia della Qualità .......................................................................................................... 49
5
Sviluppo dei Requisiti.................................................................................................................... 53
5.1
Introduzione allo Sviluppo dei Requisiti............................................................................... 55
5.2
Identificazione (Elicitazione) dei Requisiti ........................................................................... 56
5.3
Analisi dei Requisiti .............................................................................................................. 68
5.3.1 Modellazione della Soluzione .......................................................................................... 72
5.4
Specifica dei Requisiti........................................................................................................... 76
5.5
Verifica e Validazione dei Requisiti ...................................................................................... 80
6
Ingegneria dei Requisiti nei Modelli ............................................................................................. 81
6.1
Modelli di Sviluppo e Manutenzione e relativi Approcci ..................................................... 82
6.2
Modelli di Maturità .............................................................................................................. 87
7
Supporto degli Strumenti ............................................................................................................. 89
7.1
Vantaggi degli Strumenti...................................................................................................... 90
7.2
Categorie di Strumenti ......................................................................................................... 91
7.3
Selezionare gli Strumenti ..................................................................................................... 92
8
Letteratura .................................................................................................................................... 94
9
Indice ............................................................................................................................................ 96
Versione v2.1 - 2014
Pagina 4 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Introduzione
Scopo del Sillabo
Questo Sillabo definisce il Livello “Foundation” del programma di formazione per ottenere una
qualifica Professionale Certificata REQB per l’Ingegneria dei Requisiti (in forma abbreviata CPRE,
Certified Professional for Requirements Engineering). REQB ha sviluppato questo Sillabo in
collaborazione con “Global Association for Software Quality” (GASQ). L’ambito del programma
REQB copre il processo di Ingegneria dei Requisiti per tutti i tipi di prodotti che si riferiscono all’IT,
dove un prodotto può includere l’hardware, il software, i servizi ed i processi di business con la
relativa documentazione.
REQB fornisce questo Sillabo, che deve servire:
1. Ai Board Nazionali, per tradurlo nella loro lingua locale e accreditare i Fornitori della
Formazione. La traduzione può includere adattamenti al Sillabo rispetto a particolari
esigenze di tale lingua e modifiche ai riferimenti (libri e pubblicazioni) in modo da potersi
adattare alle pubblicazioni locali, se esistenti.
2. Ai Board Esaminatori, per poter creare le domande d’esame nella lingua locale,
adattandole agli Obiettivi di Apprendimento definiti in questo Sillabo.
3. Ai Fornitori della Formazione che stanno cercando un accreditamento come Fornitori
riconosciuti della Formazione REQB per l’erogazione dei corsi. Tutte le aree di questo
Sillabo devono essere incorporate nei rispettivi documenti utilizzati per il corso.
4. Ai candidati per la certificazione REQB Foundation, come materiale preparatorio per
l’esame di certificazione. Tutte le aree elencate in questo Sillabo sono quindi importanti
per l’esame, che può essere svolto sia al termine di un corso di formazione accreditato, sia
in modo indipendente, in una sessione d’esame pubblica.
5. Alla comunità internazionale di Ingegneria dei Requisiti, per migliorare la professione di
Ingegnere dei Requisiti
Esame
L’esame per conseguire la Certificazione Professionale REQB (CPRE) per l’Ingegneria dei Requisiti è
basato su questo Sillabo. Tutte le sezioni di questo Sillabo possono quindi essere oggetto di
domande d’esame. Le domande d’esame non sono necessariamente derivate da un singolo
capitolo; una domanda può far riferimento a diversi capitoli.
Il formato delle domande d’esame è a scelta multipla.
Gli esami possono essere svolti dopo aver partecipato al corso di formazione accreditato, oppure
in una sessione d’esame pubblica (senza un corso precedente). Informazioni dettagliate sulla
Versione v2.1 - 2014
Pagina 5 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
durata dell’esame sono disponibili nella relativa sezione REQB del sito "ITAlian Software Testing
Qualifications Board”, ITA-STQB (http://reqb.ita-stqb.org).
Accreditamento
I fornitori della formazione per il Corso di Certificazione Professionale REQB per l’Ingegneria dei
Requisiti, Livello Foundation, devono essere accreditati da ITA-STQB.
I loro esperti svolgono una revisione (review) della documentazione del Fornitore della
Formazione per verificarne la precisione e la conformità al contenuto e agli Obiettivi di
Apprendimento del Sillabo. Un corso accreditato è considerato conforme al Sillabo. Al termine di
tale corso, un esame ufficiale per la Certificazione Professionale REQB per l’Ingegneria dei Requisiti
(esame CPRE) può essere tenuto da un istituto di certificazione indipendente (in base alle norme
ISO 17024).
Fornitori della Formazione accreditati possono essere identificati dal logo ufficiale di Fornitore
della Formazione Accreditata REQB.
Internazionalità
Questo Sillabo è stato sviluppato con la cooperazione tra esperti internazionali. Il contenuto di
questo Sillabo può quindi essere visto come uno standard internazionale. Il Sillabo permette di
erogare formazione ed effettuare esami in ambito internazionale allo stesso livello.
Benefici sul Business
Gli obiettivi, i benefici e i punti principali della Certificazione Professionale REQB per l’Ingegneria
dei Requisiti, Livello Foundation, sono riportati nella seguente Tabella 1.
Versione v2.1 - 2014
Pagina 6 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Tabella 1. Obiettivi del programma Livello Foundation, con i relativi benefici e punti principali
Obiettivi e Benefici
Ottenere una nuova qualifica
professionale fondamentale
Aumentare la soddisfazione dei
clienti
Minimizzare i costi di sviluppo e di
manutenzione
Vantaggi competitivi
Qualsiasi soluzione software, hardware o relativa a un servizio
è basata su requisiti degli stakeholder, in modo da soddisfare
specifiche esigenze di business. Per essere in grado di
rilasciare una soluzione che corrisponda alle necessità
richieste, è necessaria un’appropriata attività di Ingegneria
dei Requisiti. Gestire e sviluppare i requisiti secondo la
soluzione progettata è molto importante, ma occorre
prendere in considerazione la qualità per raggiungere un
successo completo e rilasciare la soluzione migliore. Tutti
questi aspetti sono coperti nel Livello Foundation.
Si raggiunge la soddisfazione del cliente quando la soluzione
scelta soddisfa le aspettative e le necessità del cliente.
Migliorare l’Ingegneria dei Requisiti minimizza le discrepanze
tra le aspettative e il prodotto risultante. Una maggiore
qualità del prodotto finale aumenta la fiducia del cliente.
Un’Ingegneria dei Requisiti appropriata minimizza i rischi di
progetto e di prodotto, permettendo di evitare costi per
rielaborazioni e rifacimenti, dovuti per esempio a discrepanze
tra le aspettative del cliente e la soluzione implementata.
Requisiti ben gestiti riducono anche i costi per azioni future
migliorative o correttive.
L’Ingegneria dei Requisiti aiuta a rilasciare prodotti o servizi
migliori, che incontrano tutte le necessità e le aspettative del
business, e che permettono di ottenere la fiducia e la fedeltà
del cliente. In questo modo aumenta il vantaggio competitivo.
Obiettivi e Punti Centrali
Requisiti
Processo di Ingegneria dei
Requisiti
Standard, leggi e normative
Ingegneria dei Requisiti nei
modelli di sviluppo e
manutenzione
Versione v2.1 - 2014
Comprendere i concetti base relativi ai requisiti, la loro
classificazione ed i livelli di astrazione; spiegare il significato
degli attributi dei requisiti ed il ruolo dei criteri di qualità.
Spiegare il processo di Ingegneria dei Requisiti, le relative
attività, gli attori e gli artefatti, i principi e le best practice più
importanti per lo sviluppo e la gestione dei requisiti relativi a
prodotti software, hardware e di servizi.
Elenco degli standard, delle leggi e delle normative più
importanti, con i relativi effetti sull’Ingegneria dei Requisiti.
Spiegare i principi per adattare il processo generico di
Ingegneria dei Requisiti a modelli di processo specifici
Pagina 7 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Strumenti e Tecniche
Esercitazione
Spiegare l’utilizzo ed i benefici di tecniche per l’elicitazione
(identificazione) dei requisiti, per la modellazione del
problema e della soluzione, per implementare e controllare la
Garanzia della Qualità.
Spiegare l’utilizzo ed i benefici di strumenti per supportare il
processo di Ingegneria dei Requisiti.
Scrivere buoni requisiti, controllare la qualità dei requisiti,
svolgere l’identificazione e analisi dei requisiti
Il Livello Foundation della Certificazione Professionale REQB per l’Ingegneria dei Requisiti è adatto
a tutte le persone coinvolte nello sviluppo di una soluzione di business/prodotto e della relativa
manutenzione. Includono Analisti di Sistema e di Business, gruppi di marketing, progettisti
hardware/software, progettisti GUI, Project Manager, rappresentanti del cliente, staff tecnico e di
manutenzione, rappresentanti della Garanzia della Qualità e degli audit relativi all’IT.
Lo scopo principale del programma Livello Foundation è di fornire una comune terminologia e
comprensione dei concetti chiave relativi al processo di Ingegneria dei Requisiti. La base di
conoscenza che viene fornita supporta le definizioni ed i concetti dell’Ingegneria dei Requisiti,
definisce il processo con i relativi artefatti. Il programma si basa su standard e best practice
generalmente accettati.
Obiettivi di Apprendimento
Gli Obiettivi di Apprendimento di questo Sillabo sono stati divisi in differenti livelli cognitivi di
conoscenza (K-livelli). Questo permette al candidato di riconoscere il “livello di conoscenza” in ogni
punto.
Per ogni sezione di questo Sillabo sono identificati i livelli cognitivi associati:
K1- Competenza/Conoscenza: Conoscenza di dettagli precisi, quali termini, definizioni, fatti, dati,
regole, principi, teorie, caratteristiche, criteri e procedure. Gli studenti sono in grado di ricordare,
riconoscere, richiamare ed esprimere conoscenza.
K2 – Comprensione: Gli studenti sono in grado di spiegare o riassumere fatti con le proprie parole,
fornendo esempi, comprendendo contesti, interpretando attività.
K3 – Applicare: Gli studenti sono in grado di applicare la loro conoscenza in nuove situazioni
specifiche, per esempio applicando regole, procedure o metodi.
Risultati di Business
Dopo aver completato il Livello Foundation della Certificazione Professionale REQB per
l’Ingegneria dei Requisiti, una persona può:
Versione v2.1 - 2014
Pagina 8 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”










BO01 Comunicare i concetti fondamentali dell’Ingegneria dei Requisiti, i requisiti ed il
loro ruolo all’interno del ciclo di vita del prodotto.
BO02 Avere consapevolezza del significato del processo di Ingegneria dei Requisiti e dei
relativi artefatti/rilasci.
BO03 Comunicare le principali attività e scopi del processo di Ingegneria dei Requisiti e
delle sue parti, Sviluppo dei Requisiti e Gestione dei Requisiti.
BO04 Trasmettere le competenze e le abilità principali che sono richieste a un Ingegnere
dei Requisiti.
BO05 Divulgare il significato dell’Ingegneria dei Requisiti per il successo di un progetto di
sviluppo e/o di manutenzione.
BO06 Comunicare il possibile utilizzo di diverse tecniche per l’elicitazione
(identificazione) dei requisiti.
BO07 Comunicare l’importanza della tracciabilità e dell’assegnazione delle priorità, e il
loro significato rispetto ai processi di Ingegneria dei Requisiti.
BO08 Comunicare l’uso della modellazione per creare una soluzione di business per uno
specifico problema di business.
BO09 Trasmettere l’importanza della Garanzia della Qualità e del Controllo di Qualità per
il processo di Ingegneria dei Requisiti.
BO10 Comunicare le differenze e le similitudini nel processo di Ingegneria dei Requisiti
tra i modelli relativi al processo di sviluppo/manutenzione.
Livello di Dettaglio
Il Sillabo per la Certificazione Professionale REQB per l’Ingegneria dei Requisiti, Livello Foundation,
è destinato a supportare formazione ed esami consistenti a livello internazionale, e per questo
comprende i seguenti componenti:




Gli obiettivi generali didattici: descrivono quale è lo scopo del programma di certificazione
REQB Livello Foundation.
Gli Obiettivi di Apprendimento per ogni area di conoscenza: descrivono i risultati cognitivi
che devono essere raggiunti dal corso sulla comprensione degli obiettivi e sulle qualifiche
che ogni partecipante deve raggiungere.
Una lista delle informazioni che devono essere spiegate: includono una descrizione e i
riferimenti a eventuale documentazione aggiuntiva, quale letteratura tecnica approvata,
norme e standard.
Una lista dei termini che i partecipanti devono essere in grado di richiamare e capire. I
singoli termini sono descritti in dettaglio nel documento REQB “Glossario Standard dei
Termini utilizzati nell’Ingegneria dei Requisiti”.
Il contenuto del Sillabo non è una descrizione della conoscenza completa dell’Ingegneria dei
Requisiti. Copre l’ambito e il livello di dettaglio relativo alla certificazione Livello Foundation.
Versione v2.1 - 2014
Pagina 9 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Organizzazione del Sillabo
Esistono sette capitoli principali.
Il titolo di ogni capitolo principale riporta l’argomento che sarà trattato e specifica la quantità
minima di tempo che un corso accreditato deve dedicare a quel capitolo.
Gli Obiettivi di Apprendimento che devono essere soddisfatti in ogni capitolo sono elencati
all’inizio del capitolo.
All’interno di ogni capitolo esiste un numero di sezioni. Ogni sezione specifica la quantità minima
di tempo che un corso accreditato deve dedicare a quella sezione. Le sotto-sezioni non specificano
il tempo associato perché compreso nel tempo della sezione relativa.
Per esempio:
1 Introduzione ai Requisiti
90 minuti
Obiettivi di Apprendimento per i Fondamenti dell’Ingegneria dei Requisiti
Gli obiettivi identificano quello che dovrai essere in grado di dimostrare a seguito del
completamento di ogni singolo modulo.
1.1 Perché i Requisiti sono necessari
LO-1.1.1
Ricordare la definizione di un Requisito (K1)
Il capitolo principale richiede che siano schedulati un minimo di 90 minuti per spiegare il
contenuto riportato nel capitolo.
All’interno di ogni capitolo, possono esistere diverse sezioni, ognuna con specifici Obiettivi di
Apprendimento. Il contenuto di ogni sezione deve permettere di raggiungere gli Obiettivi di
Apprendimento più importanti.
Versione v2.1 - 2014
Pagina 10 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
110 minuti
1 Introduzione ai Requisiti
Termini
Criteri di Qualità, Criticità, Gestione dei Requisiti, Grado di obbligatorietà, Ingegneria dei Requisiti,
Priorità, Problema di Business, Prodotto, Requisito, Requisito di Business/Cliente, Requisito di
Prodotto/Componente, Requisito di Soluzione/Sistema, Requisito di Processo, Requisito di
Prodotto, Requisito Funzionale, Requisito Non Funzionale, Sistema, Soluzione, Sviluppo dei
Requisiti, Validazione, Verifica, Vincolo, Vincolo di Business, Vincolo Tecnico
Obiettivi di Apprendimento per i Fondamenti dell’Ingegneria dei Requisiti
Gli obiettivi identificano quello che dovrai essere in grado di dimostrare a seguito del
completamento di ogni singolo modulo.
1.1 Il Concetto di Requisito
1.1.1 Il Concetto di Problema, Soluzione e Prodotto
LO-1.1.1
Spiegare i concetti di problema, soluzione e prodotto (K2)
1.1.2 Definizione e Classificazione dei Requisiti
LO-1.1.2
Spiegare il concetto di requisito e la relativa classificazione (requisiti di
prodotto e requisiti di processo/vincoli) (K2)
LO-1.1.3
Spiegare la differenza dei diversi livelli dei requisiti (requisiti di
Business/Cliente, requisiti di Soluzione/Sistema e requisiti di
Prodotto/Componente) ed il loro significato per l’Ingegneria dei Requisiti
(K2)
1.1.3 Attributi Comuni dei Requisiti
LO-1.1.4
Spiegare il concetto degli attributi comuni di un requisito (grado di
obbligatorietà, priorità e criticità) (K2)
1.1.4 Qualità dei Requisiti
LO-1.1.5
Comprendere i problemi comuni che riguardano i requisiti e spiegare
l’importanza della verifica, della validazione e dei criteri di qualità nel
migliorare la qualità dei requisiti (K2)
Versione v2.1 - 2014
Pagina 11 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
1.1.5 Ingegneria dei Requisiti, Gestione dei Requisiti e Sviluppo dei Requisiti
LO-1.1.6
Comprendere la necessità di considerare l’Ingegneria dei Requisiti per
processi, con i relativi impatti, per evitare errori nell’Ingegneria dei
Requisiti (K2)
1.2 Standard e norme
LO-1.2.1
Spiegare le possibili applicazioni ed i benefici degli standard applicabili per
l’Ingegneria dei Requisiti (K2)
Versione v2.1 - 2014
Pagina 12 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Il Concetto di Requisito
90 minuti
Per comprendere la disciplina dell’Ingegneria dei Requisiti, con i relativi input e output, è
importante disegnare il contesto in cui viene applicata ed introdurre i termini e le definizioni più
importanti.
La lista completa dei termini e delle definizioni è presente nel documento REQB “Glossario
Standard dei Termini utilizzati nell’Ingegneria dei Requisiti”.
Lo scopo di questo capitolo è fornire i concetti principali dell’Ingegneria dei Requisiti e come sono
correlati al requisito stesso.
1.1.1
Il Concetto di Problema, Soluzione e Prodotto
I problemi di business, le esigenze di business e/o gli obiettivi di business sono i principali input
dell’Ingegneria dei Requisiti. Un problema di business è la descrizione di quello che il cliente
desidera per realizzare o migliorare i propri processi di business. Il problema descrive o aiuta a
descrivere le esigenze di business di un cliente.
Uno dei principali obiettivi dell’Ingegneria dei Requisiti è di definire soluzioni di business ai
problemi/esigenze/obiettivi di business di un cliente. Una soluzione è la risposta alle esigenze di
un cliente, che sono normalmente espresse come requisiti del cliente e sono l’input all’Ingegneria
dei Requisiti. Una soluzione può essere un sistema o un suo componente, una funzionalità nuova o
modificata, una configurazione modificata, il miglioramento di un processo, ecc. In generale una
soluzione è un raffinamento di un requisito di livello più alto.
L’output del processo che realizza la soluzione è chiamato prodotto.
Per le società di formazione: spiegare il concetto di problema, soluzione e prodotto con un esempio
concreto di un progetto di sviluppo o di manutenzione.
1.1.2
Definizione e Classificazione dei Requisiti
In base allo standard IEEE 610, un requisito può essere definito come:
1. Una condizione o capacità richiesta da una figura interessata al progetto (stakeholder) per
risolvere un problema o raggiungere un obiettivo.
2. Una condizione o capacità che deve essere raggiunta o posseduta da un sistema, o da un
suo componente, per soddisfare un contratto, uno standard, una specifica, o altri
documenti formalmente definiti.
3. Una descrizione documentata di una condizione o capacità, come in (1) o (2).
Versione v2.1 - 2014
Pagina 13 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Uno degli scopi principali dei requisiti è di esprimere le necessità e le aspettative del cliente
relativamente alla soluzione pianificata. I requisiti sono anche un concetto base per le fasi
successive di un progetto, quali valutazione, pianificazione, esecuzione e monitoraggio, e spesso
costituiscono parte degli accordi definiti in un contratto negli accordi di servizio o negli ordini. I
requisiti non specificano solo quello che dovrà far parte di un sistema, ma stabiliscono i vincoli
sulla soluzione, lo scopo e la pianificazione del rilascio, e i servizi che devono essere implementati
contrattualmente.
In generale i requisiti possono essere classificati come requisiti di prodotto e vincoli (requisiti di
processo).
I requisiti di prodotto specificano caratteristiche, funzionalità, qualità e servizi richiesti per un dato
prodotto e possono essere Requisiti Funzionali e Requisiti Non Funzionali. I Requisiti Funzionali
descrivono la funzione (comportamento) del prodotto. I Requisiti Non Funzionali descrivono i
cosiddetti attributi di qualità del prodotto, e per questo sono spesso chiamati “obiettivi di qualità”.
La differenza tra i Requisiti Funzionali e Requisiti Non Funzionali può essere espressa dalle
seguenti affermazioni:


I Requisiti Funzionali specificano COSA la soluzione deve fare.
I Requisiti Non Funzionali specificano COME la soluzione deve eseguire le sue funzionalità.
I vincoli (requisiti di processo) rappresentano limitazioni sul processo di ingegnerizzazione,
sull’operazione di un sistema o sul ciclo di vita del processo. Esistono due tipi di vincoli: vincoli di
business e vincoli tecnici.


I vincoli di business definiscono limitazioni sulla flessibilità del progetto di implementare la
soluzione richiesta (per esempio, restrizioni sui costi, sui tempi e sulle risorse disponibili,
metodologie che devono essere seguite, competenze del gruppo di progetto, restrizioni
sull’organizzazione, regole di dominio, standard e normative).
I vincoli tecnici sono qualsiasi restrizione relativa all’architettura della soluzione (per
esempio, vincoli sulla piattaforma software e hardware, sulla tecnologia o sul linguaggio di
programmazione, sul software che deve essere utilizzato, sulla dimensione del database,
sull’utilizzo delle risorse, sulla dimensione e le tempistiche dei messaggi, sulla dimensione
software, sul numero e la dimensione dei file, dei record e dei dati).
Per le organizzazioni che implementano un prodotto, un requisito può essere esterno oppure
interno, a seconda che il requisito sia richiesto dal cliente oppure dall’organizzazione del prodotto
stessa. I requisiti provenienti da differenti sorgenti dovrebbero essere analizzati insieme.
I requisiti possono essere classificati secondo tipi differenti, in base alla correlazione con i diversi
aspetti del prodotto o del processo di sviluppo utilizzato. I requisiti possono essere definiti in base
ai livelli di astrazione, che rappresentano i differenti livelli di dettaglio di un requisito, a partire
dalle esigenze di business di alto livello fino ai requisiti di dettaglio relativi alla funzione software o
Versione v2.1 - 2014
Pagina 14 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
di sistema, oppure a elementi della progettazione della soluzione (p.e. prototipi delle schermate,
tastiera dei telefoni cellulari).
I comuni livelli di astrazione includono:



Requisiti di Business/Cliente
o Requisiti di alto livello che specificano cosa richiede il business ma NON come
implementarlo. Questi requisiti esprimono i desiderata, le esigenze e le
aspettative del cliente e sono spesso identificati come requisiti di business di alto
livello o requisiti del cliente.
Requisiti di soluzione/sistema
o Raffinamento dei requisiti di Business/Cliente. Descrivono la soluzione, cioè una
delle possibili alternative per soddisfare i requisiti del cliente. La soluzione può
considerare requisiti non-IT, relativi a modifiche di processo o cambiamenti di
ruolo/organizzativi. Questi requisiti esprimono i requisiti del cliente con termini
più tecnici, che possono essere utilizzati per le decisioni di progettazione.
Requisiti di prodotto/componente
o Funzioni e caratteristiche della soluzione. Una specifica completa di un
componente del prodotto, che include funzioni, prestazioni e qualità delle
funzionalità, ecc.. Questo livello di astrazione è spesso mancante perché viene
considerato parte della progettazione della soluzione.
Quando si opera con requisiti di livello differente, è importante definire e mantenere la
tracciabilità (far riferimento al paragrafo 4.3, Tracciabilità dei Requisiti). La tracciabilità è il
collegamento tra gli artefatti di progetto su livelli differenti, per esempio tra i requisiti di business
ed i requisiti di soluzione, oppure tra i requisiti ed i relativi casi di test.
Per le società di formazione: fornire esempi di requisito di tipo differente e di livelli di astrazione
diversi.
1.1.3
Attributi Comuni dei Requisiti
Gli attributi più importanti per un requisito di alto livello sono:



Grado di Obbligatorietà
Priorità
Criticità
Il Grado di Obbligatorietà identifica il livello di impegno che ci si assume per soddisfare il requisito.
Il grado di obbligatorietà è normalmente definito attraverso l’uso di parole chiave (Keyword)
inserite nella descrizione del requisito di alto livello [ISO/IEC/IEEE 29148:2011, prima IEEE 830]. Le
parole chiave possono includere: “shall, “should”, “would”, “could”. In alcuni casi viene usata la
parola chiave “must not” per esprimere aspetti che la soluzione non deve fare. Per i requisiti di
Versione v2.1 - 2014
Pagina 15 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
business definiti prima di un accordo, le parole chiave sono: “should”, “may”, “can”. Per i requisiti
di business della baseline definiti dopo l’accordo, le parole chiave che identificano il grado di
obbligo più stringente sono: “will” o “shall”.
Il grado di obbligatorietà può essere espresso utilizzando la notazione MoSCoW: “Must have”,
“Should have”, “Could have”, “Will not have this time but will have in future”.
Nel momento in cui il Fornitore ed il Cliente raggiungono un accordo, i requisiti vengono approvati
dal gruppo di progetto.
Poiché i requisiti possono modificarsi durante l’esecuzione del progetto, ottenere l’approvazione
per le modifiche sui requisiti dal gruppo di progetto assicura l’approvazione delle modifiche
necessarie ad aggiornare i piani di progetto, le attività e gli artefatti relativi.
Una delle principali implicazioni di un’approvazione dei requisiti è la responsabilità per i prodotti
finali. Possono esistere responsabilità legali relative alla qualità del prodotto. Le responsabilità
legali sono spesso relazionate a specifici requisiti che devono essere soddisfatti dal prodotto
rilasciato (per esempio: un requisito ambientale per un’antenna della rete UMTS, o per la
costruzione di un impianto nucleare). Le responsabilità possono anche essere correlate ai difetti
nel prodotto. L’approvazione assicura il rispetto dei requisiti legali.
Le responsabilità legali dovrebbero essere definite all’interno del contratto tra il Fornitore ed il
Cliente. Ad alcune aziende può anche essere richiesto di rispettare requisiti legali o contrattuali, o
standard industriali specifici.
La priorità è un attributo che esprime l’importanza e l’urgenza di un Requisito. In base a
[SWEBOK], in generale, maggiore è la priorità, fondamentale è implementare il Requisito per
raggiungere tutti gli obiettivi del prodotto. Normalmente la priorità del requisito viene classificata
tramite una scala prefissata di valori, come per esempio obbligatorio, altamente desiderabile,
desiderabile, oppure opzionale. Spesso la priorità deve essere bilanciata rispetto al costo di
sviluppo e implementazione.
La criticità di un requisito è il risultato della valutazione del rischio legato al danno che potrebbe
causare la sua non realizzazione. La criticità è espressa in livelli: maggiore è il rischio, più severe
sono le conseguenze in caso di errore funzionale.
In alcuni casi, gli attributi di un requisito possono essere espressi utilizzando il modello Kano, che si
focalizza a diversificare le caratteristiche del prodotto attraverso i seguenti tre tipi di attributi:


Attributi fondamentali (Basic) o di soglia (Threshold) - Definiscono le caratteristiche che il
prodotto deve possedere per soddisfare le esigenze del cliente.
Attributi prestazionali (Performance) – Definiscono una competenza, abilità, conoscenza o
caratteristica comportamentale associata al modo in cui sarà implementata la funzionalità,
a come il prodotto fornirà al cliente le sue capacità/funzioni. Questi attributi aumentano la
soddisfazione del cliente.
Versione v2.1 - 2014
Pagina 16 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”

Attributi di soddisfazione (Excitement) – Attributi non previsti dal cliente, chiamati anche
“esigenze non conosciute”, che devono essere identificati dal fornitore perché
permettono di dare un’impressione positiva del prodotto al cliente, e possono fornire
vantaggi significativi rispetto alla concorrenza.
Il modello Kano può essere utilizzato per esprimere sia la priorità sia l’approvazione dei requisiti.
In aggiunta agli attributi finora descritti, i requisiti possono essere categorizzati attraverso i
seguenti attributi [ISO/IEC/IEEE 29148:2011, prima IEEE 1233]:





Il modo in cui sono stati identificati
La fattibilità
Il rischio
La sorgente del requisito
Il tipo di requisito
Per le società di formazione: spiegare gli attributi comuni di un requisito e fornire alcuni esempi che
ne chiariscano il significato.
1.1.4
Qualità dei requisiti
L’Ingegneria dei Requisiti è uno dei più importanti fattori di successo di un progetto. I requisiti
sono la base delle attività successive di un progetto, ed è quindi molto importante assicurare che i
requisiti e gli altri artefatti del processo di Ingegneria dei Requisiti siano della migliore qualità
possibile. Le problematiche più comuni che si riscontrano quando si lavora con i requisiti sono:










Obiettivi di business non chiaramente specificati per i requisiti o per il progetto stesso
Problemi di comunicazione (spesso causati da barriere linguistiche o da differenti livelli di
conoscenza, che includono anche la mancanza di conoscenza del dominio di business).
Formulazioni vaghe (spesso causate da una definizione del requisito insufficiente o non
misurabile, o dalla mancanza di un glossario comune)
Volatilità dei Requisiti (spesso causata da obiettivi di business non chiari per il requisito o
per il progetto stesso)
Requisiti di “cattiva qualità” (sulla base dei criteri di qualità definiti di seguito)
Gold Plating (aggiungere funzionalità che non sono state realmente richieste)
Stakeholder non coinvolti in modo sufficiente
Stakeholder mancanti (spesso a causa di un processo di Ingegneria dei Requisiti non
definito in modo completo)
Pianificazione non accurata (spesso causata da obiettivi di business mancanti o non chiari
per i requisiti o per il progetto stesso)
Documenti di Specifica dei Requisiti o di Specifica della Soluzione mancanti o incompleti (a
causa di requisiti mancanti, incompleti o frammentati)
Versione v2.1 - 2014
Pagina 17 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Alcuni dei problemi sopra evidenziati posso essere risolti semplicemente applicando i criteri di
qualità per i requisiti. In base a [Wiegers], i comuni criteri di qualità per i requisiti stabiliscono che
ogni requisito deve essere:








Corretto – il requisito deve descrivere in modo accurato la funzionalità che deve essere
fornita, secondo quanto richiesto. Il punto di riferimento per la valutazione di tale
correttezza è la sorgente del requisito (per esempio, i clienti o un requisito di sistema di
livello più alto).
Fattibile – il requisito deve poter essere implementato, sulla base delle possibili limitazioni
del sistema e dell’ambiente, e/o delle capacità conosciute.
Necessario – il requisito dovrebbe documentare quello che realmente è richiesto e
necessario all’utente (o agli altri stakeholder), in modo da soddisfare un Requisito esterno,
un’interfaccia o uno standard specifico.
Con assegnata priorità – il requisito dovrebbe avere una priorità assegnata, che permetta
di identificarne la necessità e l’importanza per una particolare versione del prodotto.
Non ambiguo – l’interpretazione e la comprensione del Requisito dovrebbe essere
univoca, da parte di lettori differenti.
Verificabile - dovrebbe essere possibile verificare che l’implementazione del requisito è
corretta (Testabilità di un Requisito).
Singolare - il Requisito non deve essere composto da più Requisiti; questo implica una
granularità sufficiente a specificare un singolo requisito.
Indipendente dalla progettazione (implementazione) – il requisito dovrebbe descrivere
“COSA DEVE ESSERE FATTO” e non “COME FARLO”. Il contenuto di un requisito non
dovrebbe prescrivere o fare riferimento o implicare dettagli implementativi.
I criteri di qualità non si applicano solo al singolo requisito, ma possono essere utilizzati anche per
una Specifica dei Requisiti. I criteri di qualità per le Specifiche definiscono che una Specifica dei
Requisiti deve essere:




Completa - tutti i Requisiti e le informazioni necessarie dovrebbero essere trattati nella
Specifica dei Requisiti. La completezza è anche espressa come una caratteristica
“desiderata” per un singolo requisito e per il livello di dettaglio.
Consistente – i requisiti descritti nella Specifica non devono essere in conflitto con altri
requisiti di prodotto o di più alto livello (di business o di sistema).
Modificabile - la Specifica deve permettere di introdurre modifiche ai requisiti,
mantenendo traccia della storia delle modifiche relative ad ogni requisito.
Tracciabile - dovrebbe essere possibile collegare ogni requisito alla relativa
documentazione sorgente (per esempio uno use case, un Requisito di sistema di più alto
livello, o un’affermazione dell’utente) e ai relativi artefatti implementativi (per esempio,
elementi di progettazione, codice sorgente e casi di test).
Per le società di formazione: spiegare i criteri di qualità dei requisiti e fornire alcuni esempi di
requisiti che soddisfano o meno tali criteri.
Versione v2.1 - 2014
Pagina 18 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Le attività di Validazione e Verifica assicurano il richiesto livello di qualità per i requisiti e gli altri
artefatti del processo di Ingegneria dei Requisiti.
In accordo con il CMMI, le attività di Validazione dimostrano che un prodotto o un suo
componente esegue le attività come richiesto, quando posto nell’ambiente per cui è stato
sviluppato. Permettono quindi di capire “di aver costruito il prodotto CORRETTO”.
Spesso il cliente specifica i Requisiti in modo non chiaro e confuso. E’ compito della fase di
Validazione di aiutare a capire che cosa è necessario (utilizzando tecniche come: prototipi, scenari,
use case, ecc).
La Validazione è normalmente condotta con il supporto del cliente o degli stakeholder presso la
sede del cliente, e permette di confermare se i requisiti o le Specifiche dei Requisiti descrivono
accuratamente quello di cui il cliente ha necessità.
In accordo con il CMMI, la Verifica fornisce dei momenti di controllo (checkpoint) dove vengono
eseguite delle verifiche su specifici rilasci (deliverable) o su prodotti intermedi, che confermino di
aver coperto i Requisiti. Le attività di Verifica si focalizzano sulla conferma incrementale
dell’implementazione dei requisiti; permettono di avere una conferma che si sta costruendo il
prodotto giusto, in anticipo e durante l’esecuzione del progetto.
La Verifica è un processo che confronta un prodotto intermedio con le relative Specifiche.
Determina quindi se il prodotto è stato sviluppato correttamente e se sono state soddisfatte le
Specifiche definite durante le fasi precedenti.
Le tecniche più comuni utilizzate per la Verifica sono la review, l’analisi statica e il test dinamico.
Le tecniche più comuni utilizzate per la Validazione sono la review e il test dinamico.
La differenza tra Validazione e Verifica può essere espressa come segue:


1.1.5
Verifica - abbiamo creato il prodotto correttamente?
Validazione – abbiamo creato il prodotto corretto?
Ingegneria dei Requisiti, Gestione dei Requisiti e Sviluppo dei Requisiti
L’Ingegneria dei Requisiti (RE) può essere definita come parte della disciplina dell’Ingegneria dei
Sistemi, focalizzata a identificare, sviluppare e gestire i requisiti dei sistemi hardware e software
[SWEBOK, Sommerville]. In accordo al CMMI, l’Ingegneria dei Requisiti consiste nella Gestione dei
Requisiti e nello Sviluppo dei Requisiti.
La Gestione dei Requisiti ha lo scopo di gestire le baseline di un insieme concordato di requisiti
della soluzione e assicurare l’allineamento di questi requisiti con i piani di progetto e gli artefatti.
La Gestione dei Requisiti costituisce sia una base di lavoro per l’Ingegneria dei Requisiti sia
l’insieme di processi che supportano lo Sviluppo dei Requisiti. Ha anche il ruolo di stabilire e
fornire l’interfaccia verso gli altri processi manageriali e di sviluppo che si interfacciano con
Versione v2.1 - 2014
Pagina 19 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
l’Ingegneria dei Requisiti, quali il Project Management (Gestione del Progetto), il Configuration
Management, il Risk Management (Gestione del Rischio), il Change Management e il Quality
Assurance (Garanzia della Qualità, QA).
Lo Sviluppo dei Requisiti è un insieme di attività, tecniche e strumenti che permettono di
identificare, analizzare, documentare e validare i requisiti relativi ai differenti livelli di astrazione.
Include sia il processo di trasformazione delle esigenze in requisiti, sia lo sviluppo della soluzione
per questi requisiti (raffinamento dei requisiti di alto livello).
Un buon processo di Ingegneria dei Requisiti è uno dei maggiori fattori di successo di un progetto.
Requisiti ben definiti, analizzati, documentati e gestiti riducono i rischi di progetto, poiché
costituiscono una base chiara e comprensibile per la progettazione della soluzione.
Ad oggi, il significato di requisito “buono” o di processo di Ingegneria dei Requisiti non è
comunque ancora ben compreso, o viene semplicemente trascurato. I motivi per cui non viene
presa in giusta considerazione l’Ingegneria dei Requisiti possono essere i seguenti:




Forte pressione sulle tempistiche e sui costi
Forte orientamento esclusivamente verso risultati rapidi
Decisione di considerare solo Requisiti Funzionali
Mancanza di comprensione dell’importanza dell’Ingegneria dei Requisiti per il successo del
progetto
Nel caso in cui l’Ingegneria dei Requisiti non venga considerata con la dovuta attenzione, le
possibili conseguenze possono essere:




I Requisiti sono di bassa qualità
I Requisiti vengono modificati di frequente durante lo sviluppo del prodotto
I Requisiti non soddisfano tutti i Criteri di Accettazione e/o non forniscono valore al cliente
o agli altri stakeholder
Alcuni Requisiti o vincoli risultano mancanti
Versione v2.1 - 2014
Pagina 20 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Standard e normative
20 minuti
Nota: Non è richiesto conoscere i contenuti e i numeri identificativi di specifici standard. È comunque
importante conoscere quali norme sono rilevanti per l’Ingegneria dei Requisiti.
Esistono molti standard e normative di processo che sono utili per l’Ingegneria dei Requisiti.
Alcuni di questi forniscono modelli di processi relativi allo sviluppo della soluzione, altri forniscono
linee guida per scrivere differenti tipi di Specifica dei Requisiti o per classificare i requisiti.
Uno degli scopi principali degli standard è quello di avere un allineamento nazionale ed
internazionale dei prodotti e dei processi. Gli standard normalizzano i metodi di sviluppo ed i
relativi artefatti, forniscono una terminologia comune e facilitano la comunicazione nel business e
nella tecnologia.
Gli standard e le normative più importanti che vengono utilizzate nello schema REQB sono elencati
di seguito.
Standard:









ISO 9000. La famiglia ISO 9000 definisce i requisiti, i concetti ed i fondamenti per un
Sistema di Gestione della Qualità (QMS, Quality Management System)
ISO/IEC 25000 (prima ISO 9126). Definisce un modello di qualità con sei categorie
principali (Funzionalità, Affidabilità, Usabilità, Efficienza, Manutenibilità, Portabilità)
che possono essere una base per l’Identificazione (Elicitazione), la Specifica, la
Validazione o la Verifica dei Requisiti:
IEEE 610.12-1990. Glossario Standard IEEE della Terminologia dell’Ingegneria del
Software
IEEE 830-1998. Raccomandazione IEEE per le Specifiche dei Requisiti Software
(conosciuta anche come Pratica Raccomandata per SRS)
IEEE 1233-1998. Guida IEEE per lo Sviluppo delle Specifiche dei Requisiti di Sistema
(conosciuta anche come Guida per lo sviluppo di SyRS)
IEEE 1362-1998. Guida IEEE per Definizioni di Information Technology – Definizioni di
Sistema – Documento di Concepts of Operations (ConOps)
Nota: IEEE 839, IEEE 1233 e IEEE 1362 sono stati sostituiti con lo standard ISO/IEC/IEEE
29148:2011.
SWEBOK (ISO Technical Report 19759) - Guide to the SoftWare Engineering Body Of
Knowledge. Descrive in modo generale l’Ingegneria del Software, sulla base delle Aree
di Conoscenze finora attestate. Vengono definite 10 Aree di Conoscenza che
riassumono i concetti principali e includono una lista di riferimenti alle informazioni di
dettaglio. Una delle Aree è dedicata all’Ingegneria del Software.
SEBOK - Guide to the System Engineering Body Of Knowledge.
Versione v2.1 - 2014
Pagina 21 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Normative di Processo per lo sviluppo:


ISO 12207 - Standard per il Processo del Ciclo di Vita del Software
ISO 15288 - Processo del Ciclo di Vita di Sistema
Entrambe le Normative possono essere utilizzate per supportare l’organizzazione del processo di
sviluppo della soluzione.
Normative di Processo per la valutazione ed il miglioramento del processo:


ISO 15504 - Information Technology. Valutazione del processo, noto anche come SPICE
(Software Process Improvement and Capability Determination, SPICE)
CMMI. Capability Maturity Model Integrated.
Entrambe le Normative supportano miglioramenti di processo e possono essere utilizzati per
valutare e migliorare il processo considerato. Definiscono aree chiave per l’Ingegneria dei
Requisiti.
Per le società di formazione: spiegare perché questi standard sono importanti quando si definisce
un processo di Ingegneria dei Requisiti.
Versione v2.1 - 2014
Pagina 22 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
2 Contesto dell’Ingegneria dei Requisiti
40 minuti
Termini
Analisi del Business
Obiettivi di Apprendimento per i Fondamenti dell’Ingegneria dei Requisiti
Gli obiettivi identificano quello che dovrai essere in grado di dimostrare a seguito del
completamento di ogni singolo modulo.
2.1 Ingegneria dei Requisiti nel Contesto
LO-2.1.1
Spiegare il contesto dell’Ingegneria dei Requisiti e come questa sia parte
del ciclo di vita dello sviluppo della soluzione e della manutenzione (K2)
2.2 Processi Correlati
LO-2.2.1
Spiegare le relazioni e le interazioni tra l’Ingegneria dei Requisiti e le altre
discipline del processo di sviluppo (K2)
Versione v2.1 - 2014
Pagina 23 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
2.1 Ingegneria dei Requisiti nel Contesto
20 minuti
L’Ingegneria dei Requisiti non è eseguita in modo isolato, ma è correlata alle altre discipline e
dovrebbe essere incorporata nel processo globale di sviluppo della soluzione, come riportato in
Figura 1.
Figura 1. Contesto dell'Ingegneria dei Requisiti
Il punto di partenza per l’Ingegneria dei Requisiti è l’Analisi del Business (BA, Business Analysis).
Per poter proporre la migliore soluzione per uno specifico problema di business, è importante
definire il problema correttamente [IBAQB].
L’Analisi del Business è una disciplina che fornisce un insieme di attività, strumenti e metodi che
hanno lo scopo di stabilire quali sono le esigenze, gli obiettivi ed i problemi di business, di
determinare le soluzioni appropriate che soddisfano queste esigenze e risolvono specifici problemi
di business. Queste soluzioni di business possono includere sviluppi di sistemi software o
componenti software, estensioni di software esistenti, miglioramenti al processo di business,
modifiche organizzative, ecc. L’Analisi del Business definisce il problema di business che deve
essere risolto da una determinata soluzione; tale soluzione diventa l’input per la successiva fase di
Ingegneria dei Requisiti, dove gli obiettivi e le esigenze di business definiti durante l’Analisi di
Business vengono trasformati in requisiti per la soluzione. Quindi l’Ingegneria dei Requisiti può
essere vista come prosecuzione o come parte del processo di Analisi del Business. L’output
Versione v2.1 - 2014
Pagina 24 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
dell’Ingegneria dei Requisiti è la progettazione della soluzione, che verrà successivamente
implementata, verificata attraverso il test e alla fine rilasciata al cliente.
È raro che una soluzione implementata rimanga invariata nel tempo. In genere sistemi e soluzioni
subiscono modifiche e nel tempo vengono rilasciate nuove versioni, a causa dei cambiamenti di
mercato e di business, della concorrenza, dell’evoluzione delle tecnologie e di nuove opportunità
di business. Ecco perché è importante che l’Analisi del Business e l’Ingegneria dei Requisiti siano
svolte durante l’intero ciclo di vita della soluzione, comprese le attività di manutenzione. Dopo
aver rilasciato la soluzione, l’Analisi del Business ricerca nuove esigenze di business che portano
miglioramenti per allargare il mercato, per migliorare l’efficienza operativa, o per raggiungere
vantaggi competitivi. Quando risultano nuove esigenze di business, queste vengono sviluppate
dall’Ingegneria dei Requisiti per proporre soluzioni nuove e migliorative, o per estendere la
soluzione esistente con funzionalità nuove e migliori.
Per le società di formazione: spiegare il contesto dell’Ingegneria dei Requisiti attraverso esempi.
Fornire esempi di relazioni tra Ingegneria dei Requisiti e Analisi del Business (in termini di prodotti e
attività differenti).
Versione v2.1 - 2014
Pagina 25 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
2.2 Processi Correlati
20 minuti
L’Ingegneria dei Requisiti, in particolare la parte di Gestione dei Requisiti, opera in un contesto più
ampio e ha forti relazioni con i seguenti processi:







Analisi del Business – come riportato nel paragrafo precedente, l’Analisi del Business e
l’Ingegneria dei Requisiti sono strettamente correlati.
Project Management - Il Project Manager dovrebbe includere nel piano di gestione del
progetto le attività specifiche dei requisiti, allocare tempi e risorse richiesti, e assicurarsi
che siano correttamente svolte. Gli Ingegneri dei Requisiti possono dover definire un Piano
dei Requisiti che dettaglia le attività richieste per completare le Specifiche dei Requisiti.
Gestione del Rischio – Alcuni requisiti possono introdurre rischi di progetto o rischi di
prodotto, che dovrebbero essere gestiti attraverso questo processo.
Analisi e Progettazione – I requisiti sono un input obbligatorio per tali attività. Viene
richiesta la tracciabilità tra i requisiti e i documenti di analisi e progettazione.
Configuration Management e Change Management – I requisiti dovrebbero essere gestiti
secondo un processo di Configuration Management, attraverso l’uso di elementi di
configurazione.
Testing - Il test fornisce riscontri sulle discrepanze tra i requisiti definiti e concordati e
l’implementazione degli attributi funzionali e non funzionali del prodotto. Viene richiesta
la tracciabilità tra i requisiti, i test, e gli altri artefatti, per poter fornire una completa
visibilità sulla copertura dei test. In base agli elementi di test associati, uno specifico
requisito può assumere uno stato che evidenzia se è stato implementato.
Release Management – L’output dell’Ingegneria dei Requisiti è il punto di partenza di
questa fase. Per ogni soluzione o prodotto rilasciato, deve essere possibile identificare
l’elenco dei requisiti implementati in quel rilascio.
Utilizzando modelli di sviluppo differenti, o prodotti diversi, l’Ingegneria dei Requisiti può essere
correlata ad altri processi.
Per le società di formazione: Fornire esempi di relazioni tra l’Ingegneria dei Requisiti e le altre
discipline (in termini di prodotti e attività differenti).
Versione v2.1 - 2014
Pagina 26 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
3 Processo di Ingegneria dei Requisiti
80 minuti
Termini
Cliente, Fornitore, Ingegnere dei Requisiti, Processo Generico di Ingegneria dei Requisiti,
Responsabile dei Requisiti, Stakeholder, Sviluppatore dei Requisiti
Obiettivi di Apprendimento per i Fondamenti dell’Ingegneria dei Requisiti
Gli obiettivi identificano quello che dovrai essere in grado di dimostrare a seguito del
completamento di ogni singolo modulo.
3.2 Processo Generico di Ingegneria dei Requisiti
LO-3.2.1
Spiegare gli obiettivi comuni dell’Ingegneria dei Requisiti e le tipiche
attività del processo di Ingegneria dei Requisiti (K2)
3.3 Ruoli e Responsabilità
LO-3.3.1
Spiegare i ruoli dello Sviluppo dei Requisiti e della Gestione dei Requisiti
(K2)
LO-3.3.2
Richiamare i ruoli principali nell’Ingegneria dei Requisiti e spiegare il loro
effetto sul processo di Ingegneria dei Requisiti (K1)
LO-3.3.3
Richiamare le principali competenze richieste ad una persona coinvolta
nell’Ingegneria dei Requisiti (K1)
Versione v2.1 - 2014
Pagina 27 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
3.1 Introduzione al Processo di Ingegneria
dei Requisiti
40 minuti
La struttura del processo di Ingegneria dei Requisiti dipende da molti fattori, quali la cultura e la
maturità dell’organizzazione, il modello di sviluppo utilizzato, ecc.
REQB utilizza la seguente categorizzazione:



Processo Generico di Ingegneria dei Requisiti
Processo di Ingegneria dei Requisiti negli approcci e nei modelli di sviluppo e
manutenzione
Processo di Ingegneria dei Requisiti nei modelli di maturità
Il Processo Generico di Ingegneria dei Requisiti dovrebbe essere il punto di partenza per qualsiasi
organizzazione coinvolta nell’attività di sviluppo della soluzione, poiché fornisce i processi più
cruciali per la gestione dei requisiti. Questo processo può essere adattato alle specifiche necessità
di un’organizzazione, e al modello di sviluppo e di manutenzione che deve essere applicato. Il
risultato di questo adattamento definisce il Processo di Ingegneria dei Requisiti negli approcci e nei
modelli di sviluppo e manutenzione.
In aggiunta ai modelli dei processi di sviluppo, esistono i modelli di maturità, utilizzati soprattutto
per valutare l’attuale maturità di un’organizzazione ed introdurre miglioramenti per permettano di
incrementarne l’efficienza. Questa variante del Processo Generico di Ingegneria dei Requisiti è il
processo di Ingegneria dei Requisiti nei modelli di maturità, coperto dalla certificazione REQB
Livello Advanced.
Il Processo Generico di Ingegneria dei Requisiti dovrebbe essere adattato alle necessità
dell’organizzazione, in base al tipo di soluzioni che devono essere sviluppate, al dominio di
business, ai processi di business, alla cultura dell’organizzazione, al livello di competenza e
all’abilità del personale che ha in carico il processo di Ingegneria dei Requisiti.
Per le società di formazione: Spiegare l’approccio REQB al processo di Ingegneria dei Requisiti e
dimostrare la necessità di adattare il generico processo alle specifiche necessità.
Versione v2.1 - 2014
Pagina 28 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
3.2 Processo Generico di Ingegneria dei
Requisiti
20 minuti
L’Ingegneria dei Requisiti è una disciplina che include i processi necessari per l’identificazione, la
strutturazione e la gestione dei requisiti. Il Processo Generico di Ingegneria dei Requisiti include le
seguenti attività:







Identificazione (elicitazione) dei requisiti
Analisi dei requisiti
Specifica dei requisiti
Validazione e Verifica dei requisiti
Tracciabilità dei requisiti
Configuration Management e Change Management
Garanzia della Qualità
Il processo di Ingegneria dei Requisiti è un insieme strutturato delle attività sopra riportate, che
sono organizzate in uno dei due processi di Gestione dei Requisiti e Sviluppo dei Requisiti, in base
allo scopo e alla fase di sviluppo della soluzione. Una descrizione completa del processo dovrebbe
includere le correlazioni con le altre aree e discipline (per esempio, Analisi del Business o Testing),
gli input e output delle attività, le responsabilità per ogni specifica attività ed i relativi output, le
competenze richieste e gli strumenti a supporto delle attività (maggiori dettagli nel Capitolo 7,
Supporto degli Strumenti).
Le principali attività, gli input e output ai processi dell’Ingegneria dei Requisiti sono riportati in
Tabella 2.
Versione v2.1 - 2014
Pagina 29 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Tabella 2. Principali attività, gli input ed output ai processi dell’Ingegneria dei Requisiti
Processo
Input
Attività Principali
Output
Sviluppo dei Requisiti
Elicitazione
(identificazione)
dei Requisiti
Esigenze
business
di
Definizione
dell’ambito
iniziale
dei
Requisiti
Business
requisiti
dagli
Descrivere in modo dettagliato i
requisiti di alto livello
Requisiti
di
Business/Cliente
Limitazioni
Assunzioni
Escludere le funzionalità non
necessarie
Stakeholder
Analisi
Requisiti
Raccogliere i
stakeholder
di
Assunzioni
Trasformare i requisiti
Business/Cliente in requisiti
soluzione/sistema
successivamente in requisiti
Prodotto/Componente
Stakeholder
Risolvere conflitti tra requisiti
Asset
Organizzativi
Stabilire i limiti per la soluzione
Limitazioni
Tecniche
di
Modellazione
Sviluppare
modelli
soluzione di business
di
di
e
di
Requisiti approvati
Definizione
scopo
dello
Modello
soluzione
Business
della
di
della
Strumenti
Specifica
Requisiti
dei
Requisiti
Documentare i requisiti
Documenti
Specifica
Requisiti
Verificare la qualità dei requisiti
e dei documenti di Specifica dei
Requisiti
Requisiti validati
Limitazioni
di
dei
Assunzioni
Stakeholder
Asset
Organizzativi
Validazione
Verifica
Requisiti
e
dei
Requisiti
Documenti di
Specifica dei
Requisiti
Verificare
se
i
requisiti
soddisfano le esigenze degli
stakeholder
Documenti
di
Specifica
dei
Requisiti validati
Difetti
Punti
Aperti,
Problemi, Modifiche
Versione v2.1 - 2014
Pagina 30 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Processo
Input
Attività Principali
Output
Requisiti
Stabilire una struttura per la
tracciabilità
Matrice
Tracciabilità
Gestione dei Requisiti
Tracciabilità
Requisiti
dei
Strumenti
Stakeholder
Definire e mantenere
tracciabilità dei requisiti
la
Identificare e gestire
elementi di configurazione
gli
di
Asset
Organizzativi
Configuration
Management
Change
Management
Requisiti
e
Strumenti
Matrice
di
Tracciabilità
Piani
Progetto
Garanzia
della
Qualità (QA)
di
Richiedere, valutare la fattibilità,
pianificare, implementare e
valutare modifiche a un sistema,
ai documenti, o ad altri prodotti
del progetto
Requisiti
Baseline
della
Risultati dell’analisi
del rischio
Requisiti
e
documenti
di
Specifica
dei
Requisiti modificati
Change
Request
Eseguire l’analisi del rischio
Elaborare le modifiche e
assicurare la tracciabilità delle
modifiche
Piani di Progetto
Requisiti
Assicurare che i differenti
processi dell’Ingegneria dei
Requisiti ed i relativi prodotti
siano di buona qualità
Requisiti
Documenti di
Specifica dei
Requisiti
Modelli della
soluzione
Stakeholder
Applicare gli standard principali
Eseguire review e altre attività
di Garanzia della Qualità
Asset
Organizzativi
Modelli di soluzione
del Business
Difetti
Modifiche
Miglioramenti
Strumenti
Processi e Attività di
Ingegneria
dei
Requisiti definiti e
compresi
Matrice
di
Tracciabilità
Versione v2.1 - 2014
di
dei
Punti Aperti
Standard
Analisi
Rischio
Documenti
Specifica
Requisiti
del
Pagina 31 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
L’efficienza del processo di Ingegneria dei Requisiti non è uguale in tutte le organizzazioni o
progetti. Esistono alcuni fattori, interni o esterni, che possono influenzare negativamente il
processo o i prodotti dell’Ingegneria dei Requisiti.
Alcuni fattori sono all’interno dell’organizzazione del fornitore del prodotto:




Mancanza di conoscenza del dominio di business o dell’utente
Mancanza di conoscenza delle tecnologie richieste dal cliente
Metodologia/Approccio/Strumenti inefficaci dell’Ingegneria dei Requisiti
Insufficiente esperienza e competenza professionale del personale
Alcuni fattori sono all’esterno dell’organizzazione del fornitore del prodotto:




Mancanza di comunicazione, oppure approccio non efficace a comunicare i requisiti, le
esigenze o le aspettative
Obiettivi di business non chiari e/o soggetti a cambiamenti, da cui risultano requisiti
instabili
Conoscenza insufficiente del processo di sviluppo del prodotto
Coinvolgimento insufficiente degli utenti e/o stakeholder di business
L’Ingegneria dei Requisiti si occupa di diverse attività, in base al suo ruolo nel ciclo di vita dello
sviluppo o della manutenzione della soluzione, e in base ai vincoli e alle caratteristiche della
soluzione pianificata.
Il processo di Ingegneria dei Requisiti ed i relativi prodotti (come le Specifiche dei Requisiti o una
proposta della soluzione di Business) dovrebbero fornire maggior valore dal punto di vista del
cliente e degli stakeholder. Per poter garantire che la soluzione pianificata soddisfi al meglio le
esigenze e le aspettative del cliente, i requisiti dovrebbero essere sviluppati dal punto di vista del
cliente. Esempi di metodi di processo di Ingegneria dei Requisiti orientata al cliente sono:



Analisi e progettazione orientata al Cliente
Approccio prototipale
Uso di dimostrazioni per validare gli incrementi del sistema
Per le società di formazione: fornire un esempio di attività di Ingegneria dei Requisiti, con i relativi
input e output per uno specifico progetto/area di business.
Versione v2.1 - 2014
Pagina 32 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
3.3 Ruoli e Responsabilità
20 minuti
Un processo di Ingegneria dei Requisiti di successo richiede chiare definizioni di ruoli e
responsabilità.
In generale, i ruoli possono essere classificati come ruoli che impattano o sono impattati
dall’Ingegneria dei Requisiti e come ruoli interni all’Ingegneria dei Requisiti.
I ruoli più importanti che impattano o sono impattati dall’Ingegneria dei Requisiti sono il Cliente ed
il Fornitore.
Il Cliente è una persona, gruppo o organizzazione che richiede una soluzione che soddisfi le proprie
esigenze e aspettative di business.
Il Fornitore (o venditore) è una persona, gruppo o organizzazione che fornisce la soluzione,
basandosi sulle richieste del cliente.
Il Cliente formula le sue necessità e le traduce in esigenze ed aspettative iniziali di business, che
vengono normalmente fornite insieme alla richiesta di servizio/offerta.
Il Fornitore è responsabile di analizzare queste esigenze e ricavare da queste i requisiti. Il
principale obiettivo di un Fornitore è rilasciare soluzioni che soddisfino le esigenze del cliente.
I ruoli interni all’Ingegneria dei Requisiti sono il Responsabile (Manager) dei Requisiti e lo
Sviluppatore dei Requisiti. Entrambi possono essere identificati anche con il termine Ingegneri dei
Requisiti.
La grande varietà di attività dell’Ingegneria dei Requisiti identifica differenti titoli per definire
persone che svolgono compiti orientati all’Ingegneria dei Requisiti. Ogni organizzazione utilizza i
propri titoli, come Ingegnere dei Requisiti, Responsabile dei Requisiti, Sviluppatore dei Requisiti,
Analista di Business, Analista di Sistema, Architetto della Soluzione, Architetto di Sistema,
Progettista, ecc. Esistono varianti di questi ruoli che dipendono dalla cultura, dalle abitudini e dalle
tradizioni. Il problema è che spesso le responsabilità e le competenze necessarie per questi ruoli
sono raramente definiti in modo chiaro o comprensibile.
Per fornire una comprensione comune delle responsabilità e dei ruoli, REQB definisce i ruoli interni
di Responsabile dei Requisiti e Sviluppatore dei Requisiti, in base alla differenza delle attività svolte
nello Sviluppo e nella Gestione dei Requisiti.
Un Responsabile dei Requisiti è una persona responsabile delle attività di documentazione, analisi,
tracciabilità, assegnazione della priorità e coordinamento dell’approvazione dei requisiti;
successivamente si occupa di controllare le modifiche dei requisiti e comunicarle ai principali
stakeholder.
Versione v2.1 - 2014
Pagina 33 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Uno Sviluppatore dei Requisiti è una persona principalmente coinvolta nell’elicitazione
(identificazione), analisi, documentazione e assegnazione della priorità dei requisiti.
Queste due figure professionali interne all’Ingegneria dei Requisiti dovrebbero possedere le
seguenti competenze:









Competenza metodologica (cioè, conoscenza pratica del processo, dei metodi, delle
tecniche e degli strumenti di Ingegneria dei Requisiti)
Conoscenza delle best practice e degli standard più importanti relativi all’Ingegneria dei
Requisiti
Modo di pensare preciso, chiaro e analitico
Capacità di agire in modo strutturato
Capacità di moderazione e negoziazione
Esprimere sicurezza
Capacità di essere convincenti e di argomentare
Padronanza della lingua e abilità nel comunicare
Resistenza allo stress
Un altro ruolo associato all’Ingegneria dei Requisiti è lo stakeholder. Lo stakeholder è un gruppo,
un’organizzazione o un individuo che è impattato o ha interesse per il risultato di un progetto. Gli
stakeholder sono attivamente coinvolti nel progetto, o hanno interessi che possono influenzare il
risultato dell’esecuzione o completamento del progetto. Gli stakeholder possono essere persone,
entità legali o soggetti astratti.
Gli stakeholder spesso hanno conflitti di interesse tra loro, causando la definizione di requisiti
contraddittori. Il problema relativo al conflitto dei requisiti deve essere indirizzato in fase di Analisi
dei Requisiti.
Ci sono molte categorie di stakeholder, che includono:









Clienti
Utenti finali
Organizzazioni responsabili della manutenzione
Project Manager
Fornitori della soluzione
Ingegneri responsabili per lo sviluppo e la manutenzione del sistema
Clienti dell’organizzazione che utilizzeranno il sistema
Enti esterni (cioè controllori)
Esperti del dominio (cioè SME, Subject Matter Expert)
È necessario identificare tutti gli stakeholder per prendere in considerazione e comprendere tutti i
punti di vista sulla soluzione pianificata. La mancanza di stakeholder può portare ad omettere
requisiti o limitazioni importanti che possono impattare l’ambito o la scelta della soluzione.
Versione v2.1 - 2014
Pagina 34 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Per le società di formazione: descrizione del tipico stakeholder (per esempio Project Manager,
Scrum Master, Cliente, Ingegnere dei Requisiti), con i relativi punti di vista sul progetto e i principali
obiettivi
Versione v2.1 - 2014
Pagina 35 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
160 minuti
4 Gestione dei Requisiti
Termini
Analisi degli Impatti, Analisi del Rischio, Change Control Board, Change Management, Change
Request, Configuration Management, Controllo di Qualità, Elemento di Configurazione, Garanzia
della Qualità, Gestione del Rischio, Identificazione del Rischio, Metrica, Mitigazione del Rischio,
Modifica, Piano di Gestione del Rischio, Review, Rischio, Rischio di Prodotto, Rischio di Progetto,
Tracciabilità, Tracciabilità Orizzontale, Tracciabilità Verticale
Obiettivi di Apprendimento per i Fondamenti dell’Ingegneria dei Requisiti
Gli obiettivi identificano quello che dovrai essere in grado di dimostrare a seguito del
completamento di ogni singolo modulo.
4.2 Gestione di Progetto e Gestione del Rischio
LO-4.2.1
Spiegare perché è importante l’Ingegneria dei Requisiti nei progetti e
fornire esempi appropriati (K2)
LO-4.2.2
Ricordare i tipi di errori che possono verificarsi nell’Ingegneria dei Requisiti
(K2)
LO-4.2.3
Distinguere tra rischi di progetto e rischi di prodotto relativi ai Requisiti
(K2)
LO-4.2.4
Descrivere, attraverso esempi, come l’Analisi del Rischio e la Gestione dei
Rischio possono essere utilizzati per la Gestione dei Requisiti (includendo
la pianificazione dei Requisiti) (K2)
4.3 Tracciabilità dei Requisiti
LO-4.3.1
Comprendere lo scopo della tracciabilità (K2)
LO-4.3.2
Riconoscere i differenti tipi di tracciabilità (K1)
4.4 Configuration Management e Change Management
Versione v2.1 - 2014
Pagina 36 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
LO-4.4.1
Descrivere le caratteristiche del Configuration Management e del Change
Management, ed il ruolo di un Change Control Board (K2)
LO-4.4.2
Spiegare i termini: elemento di configurazione, difetto e Change Request
(K2)
4.5 Garanzia della Qualità
LO-4.5.1
Richiamare i fattori che influenzano la qualità dei processi e dei prodotti
dell’Ingegneria dei Requisiti (K1)
LO-4.5.2
Spiegare come i prodotti dell’Ingegneria dei Requisiti supportino il test (K2)
LO-4.5.3
Spiegare come le metriche possano essere utilizzate per valutare e
migliorare la qualità del processo di Ingegneria dei Requisiti e dei prodotti
correlati (K2)
Versione v2.1 - 2014
Pagina 37 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
4.1 Introduzione alla Gestione dei Requisiti
10 minuti
La Gestione dei Requisiti è principalmente un insieme di attività per la gestione ed il supporto, che
sono necessarie per assicurare l’esecuzione corretta di un processo di Sviluppo dei Requisiti
durante il ciclo di vita del prodotto. La Gestione dei Requisiti comprende anche le attività di
Configuration Management, Change Management e manutenzione della soluzione:



Tracciabilità dei Requisiti
Configuration Management e Change Management
Garanzia della Qualità
Versione v2.1 - 2014
Pagina 38 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
4.2 Gestione di Progetto e Gestione del
Rischio
40 minuti
Alcune delle principali ragioni per cui i progetti falliscono sono legate ai requisiti. Trascurare
l’Ingegneria dei Requisiti può portare a una definizione di requisiti imprecisa e contraddittoria, e
che non soddisfa i criteri e le esigenze degli stakeholder.
Un’Ingegneria dei Requisiti precisa e strutturata è parte necessaria di qualsiasi progetto.
Per minimizzare i rischi di progetto, l’Ingegneria dei Requisiti dovrebbe contribuire nelle seguenti
fasi:




Concezione del progetto – Supporto nell’identificazione dei clienti e degli stakeholder,
degli obiettivi e della Vision, delle esigenze e delle aspettative del cliente per la soluzione
del problema, e supporto nella definizione dei requisiti di alto livello
Negoziazione del contratto – Supporto nella valutazione dei requisiti del cliente, nella
definizione dell’ambito iniziale, nella valutazione delle risorse richieste per il progetto e dei
costi di sviluppo (cioè implementazione dei requisiti)
Definizione del Progetto – Include la definizione di ruoli, compiti, attività e processi
aggiuntivi (per esempio Change Management). Contribuisce anche alla progettazione
iniziale dell’architettura e al processo di test
Esecuzione del Progetto – Fornisce una base per lo sviluppo, la verifica e la validazione dei
requisiti (cioè il test). Dovrebbe anche monitorare le modifiche e richiedere la revisione
dei piani di progetto e l’adattamento dell’attuale scopo rispetto ai cambiamenti dei
requisiti
Un’Ingegneria dei Requisiti inefficace o superficiale aumenta i rischi di progetto permettendo che
gli errori si propaghino nelle fasi successive di sviluppo della soluzione. Quindi, quando vengono
pianificate le attività di Ingegneria dei Requisiti, dovrebbero essere tenute in considerazione best
practice, rischi ed errori comuni. I problemi comuni relativi all’Ingegneria dei Requisiti sono:






Soluzione con obiettivi e requisiti di business non chiari o mancanti
Modifiche frequenti dei requisiti spesso dovute a obiettivi di progetto non ben definiti e a
una non chiara definizione del dominio di business. Modifiche dei requisiti non sono
percepite come errori negli approcci Agile ed iterativi.
Responsabilità non chiare, sia da parte del cliente che del fornitore
Discordanza tra le aspettative degli stakeholder e gli artefatti di progetto
Insufficiente coinvolgimento degli stakeholder
Mancanza di tracciabilità, che porta spesso ad una stima imprecisa e incompleta degli
impatti della modifica dei requisiti (change impact analysis) sulle altre aree del prodotto
Versione v2.1 - 2014
Pagina 39 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”

Stima non precisa dei costi e degli impatti (dovuta spesso a requisiti non chiari) e
pianificazioni di progetto difficili da rispettare
La possibilità che si verifichi uno dei problemi riportati sopra può essere percepita come un rischio.
Per la gestione di questi rischi, o di altri similari, è necessario definire un processo di Gestione del
Rischio.
Una Gestione del Rischio efficiente è la chiave per diminuire i rischi di progetto e di prodotto.
Identificare, attraverso un’analisi appropriata, e pianificare una risposta adeguata ai rischi aiuta a
minimizzare la possibilità che un rischio si avveri con le relative conseguenze.
I rischi non sono isolati dai requisiti. In generale, il rischio può essere definito come la probabilità
che un evento o una situazione indesiderata si verifichi e crei conseguenze non desiderabili o
problemi potenziali. Il rischio viene espresso attraverso livelli, dove il livello di rischio è
determinato dalla probabilità che accada un evento avverso e dal relativo impatto (il danno
risultante dall’evento) [ISTQB]
Esistono due tipi principali di rischio: rischio di prodotto e rischio di progetto.
I rischi di progetto sono un insieme di rischi legati alla capacità del progetto di implementare i suoi
obiettivi, come:




Fattori organizzativi - Mancanza di competenze, formazione e di personale nel gruppo di
progetto; problemi politici; problemi con gli stakeholder nel comunicare le loro esigenze
ed aspettative relativamente alla soluzione pianificata; atteggiamenti o aspettative che
non sono proprie dell’Ingegneria dei Requisiti
Fattori tecnici - Problemi nella definizione dei requisiti corretti o delle soluzioni
architetturali/tecnologiche; superamento della soglia oltre la quale i requisiti non possono
essere soddisfatti, sulla base dei vincoli esistenti; bassa qualità dei documenti di
progettazione, delle Specifiche dei Requisiti e della Soluzione, del codice, dei dati di
configurazione e dei test
Fattori legati al fornitore - Componenti sviluppate da terze parti non rilasciate nei tempi
definiti o problemi contrattuali
Rischio di business legati alla bassa qualità – Rischio di perdita di clienti, se la soluzione
rilasciata viene ritenuta inaffidabile e inefficace
I Rischi di prodotto sono aree potenziali di insuccesso (eventi futuri avversi o pericolo) nel
software o nel sistema. Questi sono rischi relativi alla qualità del prodotto ed includono:



Rischio maggiore di failure (eventi indesiderati) del prodotto rilasciato - Sistema o
software non in grado di eseguire una funzione richiesta rispetto ai limiti specificati
Documentazione della soluzione (quali manuali utente, procedure di installazione) di bassa
qualità
La potenzialità che un software/hardware possa nuocere all’incolumità di un individuo o
alla sicurezza di un’azienda
Versione v2.1 - 2014
Pagina 40 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”



Prodotto con caratteristiche scarse (relativi agli attributi di funzionalità, affidabilità,
usabilità, efficienza)
Qualità e integrità dei dati scadente (come problemi relativi alla migrazione dati, alla
conversione e al trasporto dei dati, alla violazione degli standard sui dati)
Un prodotto che non svolge le funzionalità richieste e non soddisfa le esigenze degli
stakeholder
La Gestione del Rischio è il processo che permette di identificare i fattori potenziali che possono
avere un effetto negativo sull’esecuzione di un progetto, e di preparare le azioni appropriate per
gestire il rischio, se accade.
La Gestione del Rischio consiste nelle seguenti attività [ISTQB]:



Identificazione del rischio
Analisi del rischio (Valutazione)
Mitigazione (attenuazione) del rischio
Quando si identificano i rischi, è importante prendere in considerazione tutti gli stakeholder,
poiché diversi gruppi o individui possono identificare rischi differenti. Per esempio, uno Sponsor
del Business può supportare nell’identificazione dei rischi legati al valore fornito dalla soluzione,
mentre un Ingegnere dei Requisiti può identificare rischi legati alla mancanza di comunicazione
con i rappresentanti di business del cliente.
L’Analisi del Rischio include l’identificazione dei livelli di rischio, relativi alla probabilità che si
verifichi il rischio e al relativo impatto potenziale. Entrambi gli attributi possono essere espressi in
livelli, o più precisamente attraverso una stima numerica (p.e., la probabilità che un evento
avverso si verifichi può essere espressa in percentuale, l’impatto può essere espresso come
perdita finanziaria).
L’attività di Mitigazione del Rischio pianifica reazioni appropriate per attenuare i rischi identificati,
basandosi sui risultati ottenuti durante l’Analisi del Rischio. Le tecniche principali utilizzate per
mitigare il rischio possono essere divise in quattro categorie:




Evitare il rischio
Ridurre il rischio
Condividere il rischio
Contenere il rischio
In un processo di Gestione del Rischio, è importante definire e tenere aggiornato un piano di
Gestione del Rischio. Questo piano dovrebbe essere creato prima del Piano di Progetto ed essere
periodicamente aggiornato (p.e. al termine di ogni iterazione o al raggiungimento di una
milestone). Il piano di Gestione del Rischio dovrebbe fornire controlli di sicurezza efficaci per
gestire i rischi, e dovrebbe riportare una pianificazione dell’implementazione di questi controlli e la
lista delle persone responsabili per queste azioni.
Versione v2.1 - 2014
Pagina 41 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Il piano della Gestione del Rischio contiene:







Lista dei rischi (classificati per tipo)
Autore
Probabilità di occorrenza di ogni rischio
Severità dell’impatto di ogni rischio (includendo il costo, se applicabile)
Strategia di mitigazione di ogni rischio (includendo il gruppo/la persona responsabile delle
azioni di attenuazione da intraprendere)
Tracciabilità dei rischi nei relativi requisiti ed altri artefatti di progetto
Matrice di Valutazione del rischio
Per le società di formazione: fornire esempi di rischi relativi a requisiti ed esempi di azioni che
permettono di gestirli.
Versione v2.1 - 2014
Pagina 42 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
4.3 Tracciabilità dei Requisiti
40 minuti
I requisiti non sono stabili, ma continuano a svilupparsi durante il ciclo di vita del progetto. Le
ragioni di questo continuo sviluppo e proposte di cambiamento possono essere:



Nuove esigenze dell’utente (risultanti da nuove norme, modifiche nel business, nuovi
prodotti)
Prosecuzione delle attività (fase successiva del progetto, miglioramenti e ottimizzazioni di
funzionalità già implementate, approfondimento dei requisiti di più alto livello che sono
già stati definiti)
Nuove relazioni/interfacce all’interno del progetto (integrazioni con nuovi sistemi, nuovi
canali di accesso, come internet o canali mobili, …)
Durante il ciclo di vita di un requisito, in base alla fase di Analisi dei Requisiti e/o di
implementazione svolta, il requisito assume uno specifico stato. I diversi stati possono essere per
esempio i seguenti:







Nuovo (proposto)
Approvato
In conflitto
Implementato
Modificato
Cancellato
Rilasciato
Differenti approcci e organizzazioni possono utilizzare diversi cicli di vita di un requisito (e
differenti stati). In molti casi, i cicli di vita dei requisiti, delle Change Request e dei difetti possono
essere simili e gestiti con lo stesso strumento.
La tracciabilità fornisce un metodo per gestire lo sviluppo dei requisiti e dei prodotti relativi a quei
requisiti.
La tracciabilità fornisce una verifica che tutti i passi principali del processo di sviluppo siano stati
eseguiti. Dovrebbe essere implementata in modo bidirezionale per tutti i prodotti (per esempio:
dai requisiti ai prodotti della progettazione, e dai prodotti della progettazione ai requisiti). La
tracciabilità è anche la base per le fasi di Test, Verifica e Validazione.
Gli obiettivi della tracciabilità sono:



Analisi degli impatti
Analisi della copertura
Prova/verifica implementativa
Versione v2.1 - 2014
Pagina 43 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”


Uso del requisito (tracciare un requisito come prova che i requisiti siano stati utilizzati e
come sono stati utilizzati)
Riutilizzo del requisito
Per assicurare una buona tracciabilità, è importante etichettare i requisiti in modo univoco.
Esistono due tipi di tracciabilità:

Tracciabilità orizzontale
o

Presenta le dipendenze tra i differenti tipi di prodotti sullo stesso livello di
astrazione
Tracciabilità verticale
o
Presenta le dipendenze tra prodotti su livelli differenti di astrazione
Nel contesto dei requisiti, la tracciabilità orizzontale è normalmente utilizzata per correlare
differenti tipi di requisiti (p.e. tra un requisito funzionale software ed un requisito GUI che rende
disponibile all’utente tale funzionalità, tra due requisiti di business). La tracciabilità verticale è
spesso utilizzata per gestire la copertura dei requisiti sui differenti livelli di astrazione (p.e. tra un
requisito di business ed i relativi requisiti della soluzione).
Entrambi questi tipi di tracciabilità possono essere utilizzati per supportare l’analisi degli impatti.
In base allo standard ISO/IEC/IEEE 29148:2011 (prima IEEE 830), la tracciabilità in modelli
(template) statici può essere implementata utilizzando:




Riferimenti testuali ai requisiti negli identificatori di altri prodotti
Riferimenti testuali negli attributi
Hyperlink
Matrici
Per le società di formazione: spiegare il concetto di tracciabilità e fornire esempi della loro
applicazione.
Versione v2.1 - 2014
Pagina 44 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
4.4 Configuration Management e Change
Management
30 minuti
Per assicurare una appropriata Gestione dei Requisiti, occorre implementare un processo di
Configuration Management. In molto casi i requisiti non sono stabili e le modifiche successive
possono influenzare gli altri prodotti di progetto correlati.
Il Configuration Management ha lo scopo di stabilire e mantenere l’integrità dei prodotti
(componenti, dati e documentazione) e degli artefatti software, durante il ciclo di vita del prodotto
e del progetto.
È una disciplina che applica tecniche e strumenti tecnici ed amministrativi per identificare e
documentare le caratteristiche funzionali e fisiche di un elemento di configurazione, per
controllare le modifiche a queste caratteristiche, per memorizzare e preparare report sullo stato
dell’implementazione ed elaborazione delle modifiche, e per verificarne la conformità con i
requisiti specificati [IEEE 610]
Un elemento di configurazione è un artefatto, un documento o prodotto (hardware e/o software)
utilizzabile da un utente finale e che viene gestito come una singola entità nel processo di
Configuration Management [IEEE 610].
Nel campo dell’Ingegneria dei Requisiti, tipici elementi di configurazione possono essere:



Requisiti singoli
Specifiche dei Requisiti
Modelli visuali
Il Configuration Management assicura che tutti i prodotti generati dall’Ingegneria dei Requisiti
siano identificati, controllati attraverso il versioning, tracciati per le modifiche, messi in relazione
tra loro e con gli altri elementi del progetto (quali artefatti di sviluppo e di test), in modo tale che
la tracciabilità sia mantenuta aggiornata per tutto il processo di produzione.
Le procedure e gli strumenti (infrastruttura) per il Configuration Management dovrebbero essere
selezionati, documentati ed implementati in fase di pianificazione di progetto. Questo è dovuto al
fatto che elementi di configurazione dovrebbero essere definiti, gestiti e controllati già nelle prime
fasi di progetto.
Per le società di formazione: Fornire esempi di attività di Configuration Management per differenti
artefatti del processo di Ingegneria dei Requisiti.
Versione v2.1 - 2014
Pagina 45 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Un importante aspetto legato alla configurazione sono le modifiche. Modifiche ai requisiti possono
essere richieste in qualsiasi momento, durante la realizzazione del progetto e dopo il rilascio in
produzione del prodotto completo.
La sorgente di una modifica può essere:




Estensione o modifica di una funzionalità esistente
Richiesta di nuove funzionalità/requisiti
Difetti riscontrati nel prodotto/documentazione che portano alla necessità di una modifica
Modifiche dovute a fattori esterni (modifiche organizzative, cambiamenti di
regolamentazioni)
Richieste di modifica avvengono normalmente ed quindi importante pianificarle in termini di
processo e tempistiche. Le modifiche vengono gestite attraverso il processo di Change
Management.
È importante distinguere tra una richiesta di modifica e un difetto. Un difetto è una deviazione dal
comportamento atteso per un sistema. Una modifica è una richiesta di cambiamento o aggiunta di
una funzionalità, requisito o caratteristica.
Change Management è un processo per la richiesta di una modifica, per la valutazione della sua
fattibilità, per la pianificazione, l’implementazione e la previsione delle modifiche al
sistema/software, ai documenti o ad altri prodotti del progetto. Scopo del Change Management è
di supportare l’elaborazione delle modifiche e di assicurare la tracciabilità delle modifiche.
Il processo di Change Management include generalmente le seguenti attività:
1. Identificazione di una potenziale modifica
2. Richiesta di una nuova funzionalità o di una modifica di funzione (sottomettere una
Change Request)
3. Analisi della Change Request (normalmente eseguita da un Change Control Board, che
considera anche l’analisi degli impatti della modifica)
4. Valutazione della modifica (che include l’attività di valutazione dei rischi che sono stati
riscontrati, dei costi e della stima per poter riuscire a prendere una decisione sulla sua
implementazione)
5. Pianificazione della modifica (se la modifica è stata approvata per l’implementazione)
6. Implementazione della modifica
7. Revisione (review) e chiusura della modifica
8. Rilascio della modifica nell’ambiente di test e successivamente in produzione.
Una richiesta di modifica dovrebbe essere formalizzata attraverso una Change Request (CR) con un
formale documento di Change Request (Request For Change, RFC). Normalmente, tale documento
descrive il motivo della richiesta, la priorità e la soluzione proposta con ulteriori dettagli, come:


Nome della persona/dipartimento o altra entità che ha richiesto la modifica
Data in cui è stata sottomessa la richiesta
Versione v2.1 - 2014
Pagina 46 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”




Motivo della richiesta
Descrizione della soluzione richiesta
Data (desiderata) in cui è stata pianificata l’implementazione, se fattibile
Budget pianificato (o disponibile) per la modifica, se fattibile
Le Change Request vengono verificate e decise dai membri del Change Control Board (CCB), o
Configuration Control Board. L’introduzione del CCB fornisce un modo controllato di implementare
una modifica, o una proposta di modifica, su un prodotto o servizio.
Il Change Control Board (CCB) è un comitato che, basandosi sulle informazioni fornite (come i
rischi legati alla Change Request, i relativi impatti e l’effort richiesto per l’implementazione),
decide se la richiesta proposta dovrebbe essere implementata. Il CCB è costituito dagli stakeholder
di progetto o da loro rappresentanti. Nei modelli di sviluppo Agile, il ruolo del CCB è normalmente
svolto dal gruppo di sviluppo insieme al Product Owner e ai rappresentanti del cliente.
L’introduzione di un CCB supporta una procedura per la revisione (review), la valutazione e
l’implementazione di una modifica di un prodotto o di un servizio.
Il Change Control Board può essere composto dai seguenti ruoli:






Gestione del Progetto
Ingegneria dei Requisiti
Gestione dello Sviluppo
Garanzia della Qualità (Gestione della Qualità, Gestione del Test)
Gestione del Business
Rappresentanti del cliente e/o dell’utente finale
In base alla sua complessità ed impatto, una modifica può avere diversi impatti sul sistema. Piccole
modifiche possono richiedere cambiamenti minori, mentre modifiche complesse possono
cambiare radicalmente la logica del sistema. Qualsiasi cambiamento dovrebbe essere analizzato
con cura e attenzione, in modo da stabilire i rischi relativi e valutare il valore della modifica
richiesta rispetto ai rischi possibili che sono stati riscontrati.
Quando si decide se una modifica può essere o meno implementata, è importante analizzare
l’impatto della modifica sul progetto. Questo viene normalmente svolto attraverso l’Analisi degli
Impatti, che utilizza la tracciabilità per valutare quali artefatti occorrerà modificare o dovrebbero
almeno essere verificati quando si introduce tale specifica modifica.
Modifiche nei requisiti possono avere diversi impatti sul progetto, di cui i più comuni sono:


Modifica delle schedulazioni, del budget e delle risorse allocate
Impatti causati dalla modifica (che dipendono dalla fase di avanzamento del progetto):
o Aggiornamento dei prodotti di analisi e di progettazione (p.e.: Specifiche dei
Requisiti o della Soluzione)
o Aggiornamento della documentazione tecnica e utente
o Modifiche nella strategia di test, nei piani di test e nei test case
Versione v2.1 - 2014
Pagina 47 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
o
o
o
Aggiornamento delle pianificazioni/esigenze di formazione
Modifica dello scopo delle attività di programmazione (estensione/riduzione)
Modifica dello scopo per la preparazione e l’esecuzione dei test
Le modifiche implementate dovrebbero essere verificate prima di essere rilasciate negli ambienti
di test e successivamente in produzione.
Versione v2.1 - 2014
Pagina 48 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
4.5 Garanzia della Qualità
40 minuti
Nella definizione del processo di Gestione dei Requisiti, è necessario definire anche le attività di
Garanzia della Qualità (QA, Quality Assurance) che devono essere svolte, per assicurare che i
diversi processi e prodotti dell’Ingegneria dei Requisiti siano di buona qualità.
La Garanzia della Qualità viene definita come “tutte le attività sistematiche e pianificate in un
sistema di qualità, che è stato dimostrato essere necessarie per fornire la giusta confidenza che un
elemento soddisfi i requisiti di qualità” [ISO9000]. Questa definizione implica che tutte le azioni
svolte sono “sistematiche e pianificate” e forniscono “la giusta confidenza” che il livello di qualità
desiderato dovrà raggiungere. Queste azioni includono tecniche operative ed attività utilizzate per
soddisfare i requisiti di qualità.
Per raggiungere un determinato livello di qualità è necessario un Controllo di Qualità, che ha
l’obiettivo principale di verificare e controllare la qualità dei prodotti o servizi attraverso
l’applicazione di metodi operativi, in modo che soddisfino specifici standard di qualità. I metodi
operativi utilizzati nell’Ingegneria dei Requisiti includono attività di Project Management, Gestione
del Rischio, Change Management, Verifica e Validazione, review, Configuration Management e
Tracciabilità dei Requisiti.
Nel contesto dell’Ingegneria dei Requisiti, il Controllo di Qualità può anche focalizzarsi sulla verifica
che la documentazione dei requisiti prodotta soddisfi i criteri di qualità principali.
Quando si pianificano le attività di Garanzia della Qualità per un progetto, è importante
considerare alcuni fattori che possono influenzare la qualità del prodotto desiderata, quali:






Le aspettative o i criteri di qualità del cliente relative al processo di Garanzia della Qualità
(Quality Assurance)
Il tipo di prodotto che si sta sviluppando (p.e. la complessità o i destinatari del prodotto –
un prodotto pensato per un numero ridotto di destinatari potrebbe avere un livello di
qualità più basso rispetto a prodotti del mercato di massa)
L’ambiente in cui il prodotto è sviluppato (p.e. l’ambiente tecnico potrebbe limitare la
possibilità di raggiungere il livello degli attributi di qualità desiderato)
Il dominio (p.e. la complessità del dominio di business, del livello innovativo, la frequenza
delle modifiche nel business)
Fattori legali, di sicurezza e ambientali (p.e. normative che devono essere rispettate per
raggiungere un livello di qualità più alto)
Pressione nei tempi e nei costi che riducono la capacità di esecuzione dei Processi di
Ingegneria dei Requisiti.
Per assicurare il livello di qualità richiesto, dovrebbero essere pianificate ed eseguite attività di
verifica e validazione fin dall’inizio del progetto (far riferimento al paragrafo 5.5, Verifica e
Versione v2.1 - 2014
Pagina 49 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Validazione dei Requisiti). Gli strumenti e le tecniche riportate di seguito possono essere utilizzate
per la Garanzia ed il Controllo della Qualità dei requisiti:





Differenti tecniche di revisione (review)
Standard e modelli (template)
Tracciabilità
Prototipizzazioni
Verifica dell’osservanza dei criteri di qualità nei requisiti/Specifiche
La Garanzia della Qualità può essere supportata anche dalla testabilità dei requisiti. Requisiti
verificabili permettono di dimostrare la loro corretta implementazione, in accordo con le esigenze
degli stakeholder. La testabilità dei requisiti è supportata dai Criteri di Accettazione per un
progetto (far riferimento al paragrafo 5.5 “Verifica e Validazione dei Requisiti”).
La qualità delle Specifiche della Soluzione e dei Requisiti può essere migliorata includendo i
seguenti elementi:










Gli obiettivi del documento, lo scopo, le definizioni ed il glossario
Gli obiettivi del documento per i differenti livelli (p.e. La Specifica dei Requisiti di alto
livello ha obiettivi differenti dalla Specifica dettagliata dei Requisiti Funzionali)
Vincoli di progettazione e di implementazione
Priorità (o gradi di obbligatorietà) dei requisiti
Specificare in modo chiaro COSA dovrebbe fare il sistema, non COME dovrebbe farlo
Riferimenti a norme legislative, assunzioni, dipendenze e regole di business che devono
essere applicate
Dove possibile, utilizzo di diagrammi, chiari e auto esplicativi, invece di descrizioni testuali
astratte e complesse
Definizione chiara del catalogo utente e dello schema dei permessi (accessi e privilegi
utente)
Presentazione strutturata
Linguaggio semplice, chiaro, preciso e non ambiguo
Come specificato nel paragrafo 3.2 “Processo Generico di Ingegneria dei Requisiti”, i requisiti sono
la principale informazione in ingresso al processo di sviluppo e test del sistema. Requisiti ben
definiti riducono il rischio di fallimento del progetto, o ancora di più del prodotto, poiché
permettono di eseguire il test con accuratezza. La stabilità dei requisiti aumenta la probabilità di
rispettare le scadenze e le pianificazioni.
L’Ingegneria dei Requisiti è strettamente correlata al Test. Casi di test “buoni” (validi e corretti)
richiedono requisiti “buoni”, che possono essere testati. Il coinvolgimento dei tester è quindi
molto importante durante lo sviluppo della Specifica.
Versione v2.1 - 2014
Pagina 50 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
I prodotti generati dall’Ingegneria dei Requisiti supportano il test fornendo la cosiddetta base di
test, cioè la base per la progettazione ed implementazione dei test. I requisiti e le loro Specifiche
possono essere una base di test.
É importante ricordare che i requisiti dovrebbero essere validati attraverso test statici (review),
che possono coinvolgere i tester. Potrebbe essere richiesta l’approvazione del Test Manager, in
particolare quando si riscontra che i requisiti non sono verificabili. I tester aiutano a migliorare la
qualità dei requisiti evidenziando i relativi punti di debolezza ed i possibili difetti. I Tester
dovrebbero anche partecipare alla review dei requisiti per assicurare la loro testabilità.
Per assicurare e controllare la qualità di un progetto si utilizzano normalmente le metriche. La
metrica è una scala di misura ed è il metodo utilizzato per misurare [ISO 14598]. Le metriche
permettono di definire in modo quantificabile lo stato e la qualità del progetto. È importante
ricordare che i risultati della misura (numeri raccolti durante la misura) devono essere sempre
confrontati con i dati di riferimento (metrica di riferimento).
Le seguenti metriche possono essere applicate ai requisiti:



Costi di progetto
o Numero e complessità dei requisiti
Stabilità del progetto
o Numero di requisiti modificati
Numero dei difetti riscontrati nelle Specifiche dei Requisiti e della Soluzione
o Tipo di difetto
o Numero di difetti di tipo diverso (p.e. difetti di dati, logici, di consistenza)
In generale, è difficile misurare la Qualità dei Requisiti, poiché non esiste un modo semplice per
esprimerne la qualità. Normalmente la qualità viene misurata utilizzando delle checklist per
verificare la copertura degli criteri di qualità. Possono essere utilizzate domande che permettono
di valutare la Qualità dei Requisiti, quali:







È un requisito corretto?
È un requisito non ambiguo
È un requisito fattibile?
È un requisito tracciabile?
È un requisito identificabile?
È un requisito testabile?
È un requisito indipendente dalla progettazione?
La frequenza delle modifiche può anche essere considerata come una metrica per la qualità dei
requisiti (questa non è applicabile ai progetti Agile). Maggiore è la frequenza di modifiche
dell’insieme totale dei requisiti più il progetto è a rischio, poiché le modifiche possono essere
richieste per chiarire requisiti vaghi ed ambigui e per correggere descrizioni inconsistenti o
Versione v2.1 - 2014
Pagina 51 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
incomplete dei requisiti). La frequenza delle modifiche dovrebbe quindi essere misurata per
gestire i rischi di un progetto.
Per le società di formazione: Fornire esempi di metriche che misurano la qualità dei requisiti e del
processo di Ingegneria dei Requisiti.
Versione v2.1 - 2014
Pagina 52 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
330 minuti
5 Sviluppo dei Requisiti
Termini
Analisi degli Use Case Point, Analisi dei Function Point, Apprendimento, Assegnazione di priorità,
Auto-registrazione, BPMN, Brainstorming, Contratto, Criteri di Accettazione, Elicitazione
(Identificazione) dei Requisiti, Identificazione in base a documenti esistenti, Intervista, Livelli di
Formalizzazione, Metodo Delphi, Modello, Modello Concettuale, Modello dei Requisiti, Modello
della Soluzione, Obiettivo, Osservazione sul Campo, Planning Game/Planning Poker,
Prototipizzazione GUI, Questionario, Rappresentanti del Cliente, Riutilizzo, S.M.A.R.T., Specifica dei
Requisiti, Specifica della Soluzione, SysML, UML, Use Case, User Story, Vision, Workshop
Obiettivi di Apprendimento per i Fondamenti dell’Ingegneria dei Requisiti
Gli obiettivi identificano quello che dovrai essere in grado di dimostrare a seguito del
completamento di ogni singolo modulo.
5.2 Identificazione (Elicitazione) dei Requisiti
LO-5.2.1
Comprendere gli obiettivi dell’Identificazione dei Requisiti (K2)
LO-5.2.2
Spiegare quali sono le sorgenti dei requisiti e fornire alcuni esempi (K2)
LO-5.2.3
Comprendere il significato di una Vision di progetto per l’Ingegneria dei
Requisiti (K2)
LO-5.2.4
Comprendere il ruolo degli stakeholder per l’Identificazione dei Requisiti e
spiegare quali tecniche possono essere utilizzate per identificare tali
stakeholder (K2)
LO-5.2.5
Spiegare l’applicazione delle diverse tecniche per l’Identificazione dei
Requisiti e applicarle per uno specifico scenario (K3)
5.3 Analisi dei Requisiti
LO-5.3.1
Spiegare gli obiettivi e le principali attività dell’Analisi dei Requisiti (K2)
LO-5.3.2
Spiegare la differenza tra requisiti e soluzioni (K2)
Versione v2.1 - 2014
Pagina 53 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
LO-5.3.3
Richiamare le motivazioni per stimare i costi e l’effort e fornire esempi di
approcci di stima differente (K2)
LO-5.3.4
Applicare la procedura di assegnazione di priorità dei requisiti per uno
specifico scenario (K3)
LO-5.3.5
Spiegare l’obiettivo e gli effetti generati dall’approvazione dei requisiti (K2)
LO-5.3.6
Richiamare i differenti modelli utilizzati nell’Analisi dei Requisiti (K1)
LO-5.3.7
Comprendere l’applicativo ed essere in grado di creare i modelli di analisi
di base (analisi del contesto, decomposizione funzionale, modelli dei
processi di business) (K3)
LO-5.3.8
Spiegare le caratteristiche dei diagrammi UML principali (state transition
diagram, use case diagram, activity diagram, class diagram) e le loro
possibili applicazioni (K2)
5.4 Specifica dei Requisiti
LO-5.4.1
Comprendere e spiegare l’utilizzo degli use case e delle user story nello
sviluppo della Specifica dei Requisiti e della Specifica della Soluzione (K2)
LO-5.4.2
Comprendere e spiegare lo scopo, le caratteristiche, i contenuti e le
procedure tipiche per creare una Specifica della Soluzione (K2)
LO-5.4.3
Descrivere le caratteristiche dei differenti livelli di formalizzazione e
spiegare quando uno specifico livello può essere utilizzato (K2)
5.5 Validazione e Verifica dei Requisiti
LO-5.5.1
Riassumere le tecniche di Validazione e Verifica per evitare errori nei
requisiti (K2)
LO-5.5.2
Comprendere l’uso dei Criteri di Accettazione (K2)
Versione v2.1 - 2014
Pagina 54 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
5.1 Introduzione allo Sviluppo dei Requisiti
10 minuti
Come definito nei precedenti capitoli, il processo di Sviluppo dei Requisiti comprende le seguenti
attività:




Identificazione (Elicitazione) dei Requisiti
Analisi dei Requisiti
Specifica dei Requisiti
Validazione e Verifica dei Requisiti
Queste attività non dovrebbero essere considerate come fasi isolate senza alcuna connessione tra
di loro. Molto spesso esiste una forte pressione del mercato ad utilizzare cicli di sviluppo più brevi,
che aumentano il rischio di frequenti modifiche, aggiornamenti o revisioni della soluzione che si
sta implementando. Quindi, è quasi impossibile implementare il processo di Sviluppo dei Requisiti
come un processo lineare, dove i requisiti vengono raccolti dagli stakeholder, analizzati,
documentati attraverso le Specifiche e forniti al gruppo di sviluppo, che creerà il modello della
soluzione e validerà i requisiti. Nella pratica, i requisiti vengono tipicamente iterati verso un livello
di qualità ed un dettaglio sufficienti a prendere decisioni sulla relativa progettazione ed
implementazione. Nella maggior parte dei casi, i requisiti si modificano nel tempo, e questo
richiede lo svolgimento di attività adatte a mitigare gli effetti di queste modifiche.
Versione v2.1 - 2014
Pagina 55 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
5.2 Identificazione (Elicitazione) dei
Requisiti
120 minuti
Il primo passo nel processo di Sviluppo dei Requisiti è normalmente l’Identificazione o Elicitazione
dei Requisiti, il cui scopo principale è quello di raccogliere i requisiti da tutti i possibili stakeholder,
che non sono solo gli utenti e gli sponsor, ma anche il gruppo di progetto, il mercato e le altre
possibili sorgenti. In generale, gli obiettivi principali dell’identificazione dei Requisiti sono:




Identificare tutte le funzioni desiderate, le caratteristiche, le limitazioni e le aspettative
“Orientare” i requisiti secondo la Vision del progetto
Dettagliare i requisiti di alto livello e descrivere in modo chiaro le funzioni ed i servizi
Escludere le funzioni e le caratteristiche che il cliente non desidera
Le sorgenti dei requisiti includono:



Documenti
Sistemi in uso
Stakeholder
Queste sorgenti possono influenzare la scelta della tecnica di Identificazione.
L’Identificazione dei Requisiti non è solo la raccolta delle esigenze degli stakeholder attraverso
domande; molto spesso queste informazioni devono essere interpretate, analizzate, modellate e
validate prima che possa essere definito un insieme completo di requisiti per una soluzione. La
scelta delle tecniche e degli strumenti di elicitazione è qualche volta guidata dalla scelta dei
diagrammi per la modellazione o dall’approccio all’analisi. Infatti, molte tecniche di modellazione
richiedono l’uso di un particolare tipo di tecnica di elicitazione.
Il primo passo nell’Identificazione dei Requisiti è trovare quale problema deve essere risolto.
Questo significa identificare gli stakeholder e stabilire (o comprendere, se già precedentemente
identificati) gli obiettivi di business di alto livello. Poiché sono gli stakeholder che forniscono i
requisiti e le limitazioni, è importante identificarli tutti. Gli obiettivi di business permettono di
mantenere la Vision di quello che verrà implementato, e quindi i requisiti raccolti dovrebbero
permettere di raggiungere gli obiettivi di business. Allineare i requisiti agli obiettivi di business
aiuta anche a controllare lo scopo della soluzione.
I requisiti iniziali vengono forniti dal cliente, uno degli stakeholder chiave del progetto, poiché
occorre soddisfare le sue esigenze.
Il Cliente deve essere sempre coinvolto. L’obiettivo è di capire il Cliente e sviluppare una
comprensione reciproca dei propri bisogni. Il contraente (Fornitore) dovrebbe quindi porsi egli
stesso nella posizione del Cliente.
Versione v2.1 - 2014
Pagina 56 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Una delle sorgenti più importanti dei requisiti è un contratto tra il Fornitore ed il Cliente. L’accordo
(contratto) dovrebbe formalmente specificare e descrivere quello che vuole il Cliente. Deve essere
sempre assicurato che l’interesse del Cliente sia preso come punto centrale del lavoro (questo
significa che il fornitore non dovrebbe forzare la soluzione che preferisce, ma dovrebbe analizzare
le necessità del cliente e proporre una soluzione che soddisfa al meglio tali esigenze).
Il contratto deve essere coerente con le risorse disponibili per implementare la soluzione e
dovrebbe basarsi su: stime, scadenze, costi e piani di progetto. L’Ingegneria dei Requisiti fornisce
informazioni di input per tali stime.
Il contratto dovrebbe includere:






Una breve descrizione della soluzione pianificata
La lista dei requisiti con priorità assegnata
I criteri di accettazione per ogni requisito
La lista dei prodotti che devono essere rilasciati (documentazione, codice, software
eseguibile, servizi, processi)
Schedulazione delle scadenze per lo sviluppo e il rilascio del prodotto
Altre esigenze e aspettative, come una preferenza della tecnologia da utilizzare, i requisiti
per le risorse, ecc.
Un’altra importante sorgente delle necessità principali del cliente è la Vision di progetto.
La Vision dovrebbe essere impostata ogni volta che si parte con un nuovo progetto, poiché è
cruciale aver chiaro dove si vuole arrivare. Una Vision dovrebbe definire gli obiettivi di alto livello.
E’ cruciale avere una chiara definizione delle Vision di progetto poiché permette di verificare se il
progetto ha apportato il valore richiesto o meno.
Una Vision è realizzata attraverso gli obiettivi; gli obiettivi dovrebbero essere soddisfatti per uno
specifico progetto, visti dalla prospettiva del business, e dovrebbero essere S.M.A.R.T.
Il metodo S.M.A.R.T. permette di misurare il raggiungimento degli obiettivi al termine del
progetto: gli obiettivi dovrebbero essere [G.T. Doran]:





Specific – Specifici e precisi
Measurable – Misurabili (quantitativi)
Attainable - Fattibili
Relevant - Pertinenti
Timely - Tempestivi
Durante l’identificazione dei requisiti, occorre verificare che i requisiti soddisfino sia la Vision di
Progetto sia gli obiettivi S.M.A.R.T. che sono stati definiti.
I seguenti processi possono essere di supporto nella definizione della Vision e degli obiettivi:
1. Identificare le sorgenti dei requisiti
2. Analizzare la situazione attuale (valutazione oggettiva)
Versione v2.1 - 2014
Pagina 57 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
3. Valutare la situazione attuale (aggiunta di fattori soggettivi)
4. Deduzione della Vision di Progetto e degli obiettivi (basata su calcoli costi/benefici)
Per poter identificare tutte le esigenze ed i requisiti, occorre identificare tutti gli stakeholder lato
Cliente e lato Fornitore. Ogni stakeholder, o gruppo di stakeholder, può fornire nuovi requisiti ed
influenzare la fase di progettazione della soluzione pianificata. Se non vengono identificati tutti gli
stakeholder, esiste il rischio che alcuni requisiti importanti o alcune limitazioni rimangano
sconosciute e non vengano considerate in fase di progettazione. Il mancato coinvolgimento di
specifici stakeholder può generare il rischio che siano necessarie modifiche complesse in fasi
avanzate del progetto o dopo il rilascio in produzione del sistema.
Gli stakeholder dovrebbero essere descritti in termini di: nome, funzione, disponibilità, dominio,
obiettivi ed interessi.
Alcuni stakeholder possono creare gruppi di interesse (per esempio tutti gli stakeholder di
business); tali gruppi dovrebbero collaborare insieme perché in questo modo la gestione dei
requisiti viene svolta in modo più efficiente.
La procedura di identificazione e valutazione degli stakeholder coinvolge le seguenti attività:







Identificazione degli stakeholder (attraverso l’analisi dei processi di business, la definizione
dei possessori di processo e di prodotto, l’analisi della struttura organizzativa e del
mercato)
Raggruppamento degli stakeholder in gruppi e selezione dei rappresentanti degli specifici
gruppi (se possibile)
Identificazione delle relazioni tra stakeholder
Identificazione dei conflitti potenziali
Analisi dei conflitti, delle sorgenti che ne sono causa, e identificazione delle opportunità
win-win, in cui entrambe le parti coinvolte siano vincitrici
Identificazione degli stakeholder che minimizzino il rischio, per coinvolgerli maggiormente
nelle attività di progetto
Identificazione delle prospettive degli stakeholder
Quando sono stati identificati tutti gli stakeholder, gli obiettivi di business e la Vision di Progetto, è
possibile iniziare le attività di Identificazione dei Requisiti di dettaglio.
Le più comuni tecniche di Elicitazione (identificazione) dei Requisiti sono:







Questionari
Interviste
Auto-registrazione
Richiesta informazioni dai Rappresentanti del Cliente presenti nel luogo di lavoro
Identificazione sulla base di documenti esistenti
Riutilizzo (Riutilizzo di specifiche di particolari progetti esistenti)
Brainstorming
Versione v2.1 - 2014
Pagina 58 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”




Osservazioni sul campo
Apprendimento
Workshop
Use Case
Tali tecniche sono dettagliate nella seguente Tabella 3. Tecniche per l’Identificazione dei Requisiti.
Tabella 3. Tecniche per l’Identificazione dei Requisiti
Tecnica
Descrizione
Applicazioni
Svantaggi
Questionario
Un questionario può essere
composto da domande aperte o
chiuse. Una domanda aperta
richiede che debba essere
formulata una propria risposta.
In caso di domanda chiusa, deve
essere scelta una risposta tra un
numero di possibili opzioni
proposte, che sono
mutuamente esclusive.
Confermare o dettagliare
requisiti che sono stati
identificati
precedentemente.
Organizzare il contenuto
dei requisiti.
Selezionare opzioni per I
requisiti e le relative
soluzioni.
Non applicabile
quando occorre
raccogliere conoscenze
implicite.
In caso di risposta
chiusa, non permette
di ottenere le
motivazioni della scelta
fatta.
Possono già indicare
una direttiva, che
impedisce di
identificare le reali
esigenze dell’utente.
Versione v2.1 - 2014
Pagina 59 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Tecnica
Intervista
Autoregistrazione
Descrizione
Applicazioni
Svantaggi
Tecnica conversazionale dove
l’intervistatore pone delle
domande all’intervistato per
ottenere informazioni su uno
specifico argomento. Questa
tecnica è molto interattiva e
permette di modificare l’ordine
con cui si pongono le domande
precedentemente preparate,
sulla base delle risposte date
dall’intervistato e della
situazione contingente.
Ottenere informazioni su
un argomento specifico.
Chiarire requisiti.
Richiede tempo
Per comprendere
procedure o processi
complessi, specialmente
quando l’Ingegnere dei
Requisiti non può
osservare l’utente che
svolge le sue attività.
Vengono trascurate
attività
“automatizzate”.
Buone interviste sono più
difficili da condurre a causa del
comportamento che si tiene
durante una normale
conversazione (come
completare le frasi al posto
dell’intervistato), che può
portare a introdurre
interpretazioni nei dati forniti
con le risposte.
L’intervistatore dovrebbe porre
domande aperte per ottenere
informazioni, e domande chiuse
per confermare di aver capito
(di aver compreso i requisiti
richiesti) e confermare o
scartare specifiche opzioni.
In questa tecnica, lo stakeholder
(per esempio, un utente finale)
documenta le attività che ha
eseguito per poter completare
uno specifico compito.
Oltre a documentare le attività
attuali (AS IS), vengono
descritte anche eventuali
modifiche, desiderata ed
esigenze (TO BE).
Spesso questa tecnica è
associata a dimostrazioni o
review di documenti.
Versione v2.1 - 2014
Pagina 60 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
Difficile e non
completa riproduzione
dei risultati (difficoltà
ad ottenere le stesse
risposte quando viene
ripetuta un’intervista).
Fortemente
dipendente dalla
motivazione e
dall’esperienza
dell’utente.
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Identificazione dei Requisiti sulla base di documenti esistenti
Rappresentanti del Cliente presenti nel
luogo di lavoro
Tecnica
Descrizione
Applicazioni
Svantaggi
Questo approccio è uno dei
metodi più efficienti per
l’identificazione (e validazione)
dei requisiti, poiché permette al
rappresentante di monitorare
sistematicamente l’andamento
delle attività, verificare la
correttezza della progettazione,
fornire un rapido riscontro ed
eventuali informazioni
aggiuntive, quando necessario.
Avere rappresentanti del Cliente
sul luogo di lavoro è uno dei
principi base nella metodologia
Agile.
Questa tecnica può essere
utilizzata quando è già
disponibile della
documentazione per
identificare i requisiti interni a
un’organizzazione. Tale
documentazione può
comprendere: modelli e mappe
dei processi, descrizioni dei
processi, grafici organizzativi,
Specifiche di prodotto,
procedure (cioè procedure
operative), standard e
istruzioni, modelli (template) di
documentazione, ecc.
Raggruppare e gestire
Requisiti negli approcci
Agile.
Fornire requisiti orientati
all’utente che possono
essere facilmente
approvati
Costi alti per il Cliente
Raccogliere requisiti per
una soluzione che coprirà
i processi di business
esistenti
Non applicabile
quando all’interno di
un’organizzazione sono
al più disponibili
documenti di base o
addirittura non esiste
documentazione.
Costi di adattamento
Non applicabile
quando la
documentazione non è
manutenuta
correttamente (non
viene mantenuta
aggiornata)
I requisiti identificati sono la
base per la successiva fase di
Analisi dei Requisiti e richiedono
di essere dettagliati ed estesi
con altri requisiti ad essi
correlati e relazionati.
Versione v2.1 - 2014
Pagina 61 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Tecnica
Descrizione
Applicazioni
Svantaggi
Riutilizzo
(Riutilizzo di
specifiche di
particolari
progetti
esistenti)
Riutilizzare le specifiche dei
requisiti di un progetto simile
può essere fatto quando
un’organizzazione ha già
completato uno o più progetti
che sono simili al progetto in
corso. Le Specifiche dei Requisiti
preparate per progetti
precedenti possono essere
utilizzate in un altro progetto
per diminuire la durata delle
fasi di Analisi e di preparazione
della documentazione, e quindi
dovrebbe permettere di
anticipare la fase
implementativa.
Per progetti con
l’obiettivo di fornire
prodotti con parti custom
per specifici clienti.
Diminuire le attività di
Ingegneria dei Requisiti in
progetti che sviluppano
soluzioni simili
Costi alti per il primo
progetto
Raccogliere requisiti
accurati osservando gli
utenti al lavoro.
Utile quando gli
stakeholder hanno
difficoltà ad esprimere le
loro esigenze.
Aiuta a migliorare i
processi di business o i
sistemi esistenti
Possono non essere
prese in
considerazione le
eccezioni.
Osservazioni
sul campo
Nella maggior parte dei casi,
solo alcune parti di Specifiche
esistenti possono essere
riutilizzate in un nuovo
progetto. La documentazione
dovrebbe essere sempre
verificata, per essere in accordo
con le attuali esigenze e
requisiti, in modo da poter
eseguire gli appropriati
adeguamenti.
L’osservazione sul campo
permette di esaminare come
vengono svolte le attività e i
processi degli utenti, per
identificarne i requisiti di
sistema. Condurre una
osservazione sul campo significa
osservare gli utenti mentre
lavorano e documentare i
processi, le attività ed i risultati.
In alcuni casi, l’osservazione
viene estesa con interviste agli
utenti per conoscere il loro
lavoro e il modo in cui vengono
svolte le attività.
Versione v2.1 - 2014
Pagina 62 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
Requisiti troppo
dettagliati richiedono
una fase di Change
Management più
dispendiosa, in termini
di tempo e di risorse
Non applicabile in
alcune situazioni (per
esempio, per motivi
legali o di sicurezza)
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Apprendimento
Tecnica
Use case
Descrizione
Applicazioni
Svantaggi
Lo scopo dell’apprendimento è
di raccogliere i requisiti da parte
di un cliente, specialmente nel
caso in cui i processi e le attività
eseguite dai dipendenti del
cliente non sono facili da
descrivere con altre tecniche,
quali interviste, oppure il cliente
ha problemi nell’articolare i
requisiti.
Comprendere processi di
business complessi per
essere in grado di
proporre la migliore
soluzione.
Aiutare i dipendenti del
cliente a superare la
difficoltà di pensare in
modo astratto ed
esprimere a parole le loro
attività.
Costi e tempi richiesti
molto alti.
Raccogliere ed esprimere
i requisiti dal punto di
vista dell’utente.
Chiarire ed organizzare la
funzionalità richiesta
dalla soluzione
Non applicabile in caso
di soluzioni relative
principalmente a
requisiti non funzionali
L’apprendimento è un processo
di comprensione del lavoro
svolto dal cliente stesso, che
conosce bene COME svolgere
uno specifico lavoro e può
insegnarlo all’Ingegnere dei
Requisiti, come un insegnante
verso uno studente.
Gli Use Case permettono
all’Ingegnere dei Requisiti di
esplicitare la funzionalità che
implementa la soluzione, vista
dalla prospettiva degli Attori.
Un attore può essere un utente
finale o un sistema esterno.
Non applicabile in
ambienti pericolosi.
Gli Use Case Diagram
specificano i confini della
soluzione e le correlazioni con i
sistemi esterni e gli attori.
Versione v2.1 - 2014
Pagina 63 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Tecnica
Workshop
Descrizione
Applicazioni
Svantaggi
Un workshop è un tipo di
riunione focalizzata su uno
specifico argomento
(precedentemente definito e
proposto ai partecipanti),
coinvolgendo normalmente gli
stakeholder che rappresentano
diverse aree e/o domini
applicativi per un breve ed
intenso periodo.
Identificare requisiti in
modo da poter stabilire lo
scopo della soluzione;
scoprire requisiti
«nascosti» (requisiti che
non sono stati
direttamente richiesti
oppure neanche
compresi dagli
stakeholder, ma sono
necessari per soddisfare
le loro necessità oppure
per permettere la
realizzazione dei requisiti
di alto livello); sviluppare
e dettagliare i requisiti in
un’area recentemente
identificata; definire una
priorità dei requisiti o
raggiungere il consenso
dei requisiti in fase di
accordo (firma del
contratto); revisionare i
risultati di una specifica
attività o processo e
risolvere problematiche
che possono evidenziarsi;
identificare e risolvere
potenziali conflitti tra i
requisiti di differenti
stakeholder.
Difficoltà nel caso in
cui i gruppi interessati
siano distribuiti
geograficamente.
I workshop coinvolgono
persone che hanno differenti
punti di vista rispetto ad uno
specifico problema, in modo
che possano aiutare a definire e
descrivere requisiti da diverse
prospettive.
I workshop sono una delle
pratiche fondamentali nella
metodologia Agile, poiché
coinvolgono tutti i principali
stakeholder nello sviluppo del
Product Backlog.
Workshop preparati e svolti in
modo appropriato aiutano a
mitigare eventuali difficoltà,
quali predisporre collegamenti
remoti per gestire la
distribuzione geografica,
pianificare sessioni di sottogruppi per mitigare mancanze di
consensi, ecc.
Versione v2.1 - 2014
Pagina 64 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
Avere disponibilità di
tutte le persone che
devono partecipare al
workshop.
Il consenso non è detto
che venga facilmente
raggiunto e la
discussione può
bloccarsi per
problematiche
(minori), allungando il
processo e
demotivando i
partecipanti.
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Brainstorming
Tecnica
Descrizione
Applicazioni
Svantaggi
Brainstorming è una tecnica
comunemente utilizzata per
identificare requisiti relativi ad
aree di un’organizzazione o di
funzionalità progettate per un
sistema, che sono nuove o poco
conosciute.
Risolvere conflitti tra
requisiti; definire diverse
opzioni di una soluzione;
risolvere problemi di
business (per esempio,
bassa efficienza di un
processo).
Difficoltà in caso di
partecipanti non
motivati.
Difficoltà di
applicazione in gruppi
distribuiti.
Permette di raccogliere molte
idee da differenti stakeholder in
breve tempo ed in modo
economico.
Durante la sessione di
brainstorming, i partecipanti
sottopongono idee e concetti
relative ad uno specifico
problema.
Per le società di formazione: Fornire esempi di applicazione di almeno tre differenti tecniche di
Elicitazione (identificazione) dei Requisiti.
Per raggiungere risultati efficaci ed evitare mancanze di requisiti, vengono normalmente
combinate più tecniche di identificazione dei requisiti, tra quelle riportate sopra.
Come riportato nei paragrafi precedenti, i Requisiti Funzionali specificano le funzionalità di sistema
che sono percepite dall’utente finale. I Requisiti Funzionali descrivono anche i trigger del processo
come le azioni dell’utente, oppure i dati di input/output che causano l’inizio del processo di
business.
Quando si identificano i requisiti, è importante non porsi domande solo sulle funzioni ma anche
sugli attributi di qualità. I Requisiti Non Funzionali descrivono gli attributi di qualità dell’intero
sistema o di specifiche componenti/funzioni. Questi possono limitare la soluzione, per esempio
attraverso specifici parametri sull’efficienza. I Requisiti Non Funzionali sono difficili da descrivere,
quindi spesso vengono espressi in modo vago oppure non sono documentati. Questo crea
difficoltà nel testarli. Particolare attenzione dovrebbe quindi essere data ai Requisiti Non
Funzionali, in tutte le fasi del processo di Ingegneria dei Requisiti, per essere sicuri che siano
espressi in modo chiaro e che siano misurabili.
I Requisiti Non Funzionali possono descrivere differenti aspetti prestazionali della soluzione. In
base allo standard ISO/IEC 25000 (precedentemente ISO 9126), i Requisiti Non Funzionali possono
essere di diverso tipo, relativi a:
Versione v2.1 - 2014
Pagina 65 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”





Affidabilità
Usabilità
Efficienza
Manutenibilità
Portabilità
I Requisiti Non Funzionali sono particolarmente importanti perché specificano criteri che possono
essere utilizzati per valutare l’operazione di un sistema; aiutano quindi a stabilire la soddisfazione
dell’utente nell’utilizzo del prodotto. I Requisiti Funzionali devono fornire funzioni, i Requisiti Non
Funzionali determinano come le funzioni possono essere utilizzate facilmente ed in modo efficace.
Per le società di formazione: fornire esempi di Requisiti Funzionali e Requisiti Non Funzionali in
base a ISO/IEC 25000.
I requisiti, una volta che sono stati definiti, dovrebbero essere appropriatamente documentati per
permettere di avere una buona tracciabilità e per svolgere l’Analisi dei Requisiti.
I Requisiti devono essere definiti in modo chiaro ed accurato. Dovrebbero essere misurabili, per
poterne assicurare la testabilità, e la loro implementazione deve poter essere appropriatamente
verificata. E’ importante ricordare che il linguaggio comune ha forti limitazioni e svantaggi e può
creare descrizioni di requisiti non chiari ed ambigui. Perciò standard e modelli (template)
appropriati dovrebbero essere utilizzati quando possibile. Gli standard forniscono una
comprensione comune e delle “best practice” per scrivere la specifica, quando i modelli limitano il
linguaggio che può essere utilizzato.
In aggiunta agli standard e ai modelli, i vocabolari sono un importante strumento per facilitare la
comunicazione tra differenti stakeholder e per introdurre alcuni controlli alle ambiguità del
linguaggio naturale.
La descrizione di un requisito deve soddisfare differenti criteri (fare riferimento al par. 1.1.4
“Qualità dei requisiti”).
In base al livello di astrazione, i requisiti possono essere descritti con un maggiore o minore livello
di dettaglio. In alcuni modelli di sviluppo, i requisiti di business possono essere descritti attraverso
Use case di alto livello (per esempio, Rational Unified Process) o user story (approcci Agile). In
generale, la struttura tipica della descrizione di un requisito di business dovrebbe rispondere alle
seguenti domande e coprire i seguenti aspetti:




Dell’utente (CHI?): chi dovrebbe soddisfare questo requisito?
Del risultato: quale risultato stanno cercando di raggiungere gli stakeholder?
Dell’oggetto: a quale oggetto è indirizzato il requisito?
Della qualità: quale attributo misurabile deve essere definito?
Versione v2.1 - 2014
Pagina 66 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Per esempio, la seguente descrizione di un requisito: «L’agente commerciale deve avere
informazioni su un nuovo prodotto almeno un giorno prima del lancio del prodotto» copre i
quattro aspetti elencati sopra nel seguente modo:




CHI: l’agente commerciale
QUALE RISULTATO: deve avere informazioni
QUALE OGGETTO: un nuovo prodotto
COME: un giorno prima del lancio del prodotto
I Requisiti più di dettaglio (requisiti di Soluzione/Sistema) possono essere descritti sotto forma di
Use case di sistema, spesso arricchiti con scenari o, in caso di approcci Agile, con user story. In
generale, i requisiti di Soluzione/Sistema dovrebbero coprire i seguenti aspetti:




Sui processi impattati: a quale processo di business fa riferimento il requisito? Questo
aspetto normalmente si focalizza sulla funzionalità e determina gli input e gli output.
Sulle attività della soluzione: come viene attivata la funzionalità? É un’attività di sistema
indipendente oppure esiste un’interazione con l’utente o un’interfaccia con altri
sistemi/processi?
Sui vincoli legali: quali sono i gradi di obbligatorietà legali del requisito? Vengono spesso
utilizzate parole chiave (keyword) per descriverli (should, must, ecc.)
Sui vincoli logici e temporali: esistono condizioni al contorno applicabili al requisito?
Per le società di formazione: fornire esempi di descrizioni di Requisiti di Business e di Requisiti di
Soluzione/Sistema.
I requisiti identificati ed analizzati sono normalmente documentati sotto forma di Specifica (fare
riferimento al par 5.4, ”Specifica dei Requisiti”).
Versione v2.1 - 2014
Pagina 67 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
5.3 Analisi dei Requisiti
120 minuti
Il passo successivo all’Identificazione dei Requisiti è l’Analisi dei Requisiti. Scopo principale
dell’analisi è quello di creare una soluzione di business per l’implementazione dei requisiti. Creare
una soluzione di business significa considerare le esigenze del cliente, elaborarle in requisiti della
Soluzione/Sistema e dettagliarli fino ai requisiti di Componente/Prodotto. L’Analisi dei Requisiti
include anche l’identificazione e risoluzione dei conflitti tra requisiti appartenenti allo stesso
livello, oppure tra requisiti di livello differente, e l’identificazione dei confini della soluzione e delle
relative interazioni con l’ambiente.
La procedura di alto livello dell’Analisi dei Requisiti è iterativa e consiste dei seguenti passi:
1.
2.
3.
4.
Analisi delle esigenze
Descrizione della soluzione
Stima dei costi e assegnazione della priorità
Approvazione dei requisiti
1. Analisi dei Requisiti
Il primo passo (analisi delle esigenze) si occupa di analizzare le necessità degli stakeholder per
poter essere in grado di proporre una soluzione che soddisfi tali esigenze. In questa fase l’Analisi
dei Requisiti spesso include le attività di verifica e validazione, per essere sicuri che i requisiti siano
stati compresi ed approvati dagli stakeholder. Vengono anche svolte le importanti attività di
verifica della chiarezza e della consistenza dei requisiti, e di risoluzione di qualsiasi conflitto tra i
requisiti.
2. Descrizione della Soluzione
Durante il secondo passo (descrizione della soluzione), la soluzione viene normalmente descritta
attraverso l’uso di modelli. In generale esistono tre livelli principali di modello: Modello dei
requisiti, Modello della soluzione e Modello concettuale. I modelli sono implementati attraverso
appropriati metodi di analisi.
3. Stima dei costi e assegnazione della priorità
Durante il terzo passo (stima dei costi e assegnazione della priorità) viene valutata la stima dei
tempi e dei costi, e viene assegnata la priorità ai requisiti.
La prima attività importante del terzo passo è la valutazione della stima. La stima collega
l’Ingegneria dei Requisiti al Project Management. Nelle prime fasi di progetto la stima dei costi si
basa sui requisiti di alto livello e viene utilizzata per valutare il costo del progetto. Durante
l’implementazione della soluzione, quando i requisiti evolvono, le stime iniziali dei costi vengono
utilizzate per controllare l’avanzamento di progetto e fare una stima delle eventuali modifiche dei
requisiti.
Le stime sono in generale focalizzate sui:


Costi
Tempi
Versione v2.1 - 2014
Pagina 68 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”

Requisiti
Il costo di un progetto dipende da diversi fattori:









Tipo di progetto
Maturità del processo
Metodi, strumenti e approcci di progettazione e test
Tecnologia utilizzata
Complessità della soluzione pianificata
Obiettivi di qualità (per esempio, livello desiderato della qualità del prodotto)
Qualifiche del team
Distribuzione del team
Esperienze
L’accuratezza della stima dipende dall’avanzamento e dalla maturità del progetto.
In generale, la stima dei costi viene svolta utilizzando procedure basate su conclusioni per analogia
e procedure algoritmiche. Entrambe le procedure di stima sono basate sui dati storici e sui valori
strutturali.
La stima basata su conclusioni per analogia può essere definita, basandosi sui risultati del
confronto con progetti già conclusi e simili al progetto corrente, senza tener conto di formule
matematiche ma basandosi sull’esperienza. Con questa tecnica il progetto attuale è confrontato
con progetti passati. Il confronto può includere:





Il numero e la complessità dei requisiti
La stabilità del business
L’ambito della soluzione
La tecnologia utilizzata
Caratteristiche del gruppo di lavoro (esperienza, abilità)
Procedure basate su conclusioni per analogia sono:


Planning Poker (o Planning Game)
Metodo Delphi
Un esempio di procedura per analogia può essere riscontrata nei progetti Agile, specialmente
quelli gestiti con un approccio Scrum, dove esiste un metodo di stima chiamato Planning Game (o
Playing Poker). Il metodo permette di ottenere il consenso di gruppo. L‘abilità del team di sviluppo
è misurata attraverso il valore del Burn Down Rate e migliorata attraverso sessioni Retrospettive
(o Lessons Learned) condotte al termine di ogni iterazione (Sprint), dove le stime vengono
comparate al tempo reale utilizzato. Questo permette di migliorare la capacità del team di
eseguire delle stime.
Il Metodo Delphi è un altro esempio di procedura per analogia. E’ una tecnica di comunicazione
strutturata usata per svolgere previsioni interattive. Coinvolge un gruppo di esperti in valutazioni
successive [Linstone 75]. Ad ogni giro di valutazione delle stime, gli esperti rispondono a
questionari in modo anonimo. Al termine di ogni giro, viene svolta una riunione per considerare
Versione v2.1 - 2014
Pagina 69 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
tutte le previsioni anonime date e valutare le ragioni di tali giudizi. Quindi, gli esperti rivalutano la
loro risposta data nel giro precedente, tenendo conto delle risposte degli altri membri del gruppo.
E’ credibile che durante il processo, l’intervallo di valori nelle risposte diminuirà in modo tale da far
convergere il gruppo verso la risposta “corretta”.
Il processo viene interrotto quando è soddisfatto un criterio di uscita predefinito. La media dei
valori del giro finale determina la stima.
La stima dei costi basata su procedure algoritmiche può essere definita calcolando i costi sulla
base di specifici parametri. I parametri possono descrivere il prodotto (volume, durata), le
condizioni al contorno (efficienza), ecc.
Possono essere utilizzati i seguenti metodi:


Analisi dei Function Point (FPA)
Analisi degli Use Case Point (UCP)
L’analisi dei Function Point richiede il conteggio dei cosiddetti Function Point della soluzione
pianificata. Un Function Point (FP) è un’unità di misura che esprime la quantità di funzionalità di
business fornita ad un utente da un sistema informativo. Il costo di un singolo Function Point è
calcolato sulla base di progetti passati. Le singole funzionalità di business identificate sono pesate
in base a tre livelli di complessità; il numero di punti assegnati per ogni livello differisce in base al
tipo di Function Point.
L’Analisi degli Use Case Point è molto simile all’Analisi dei Function Point, ma richiede un’analisi di
altri elementi quali il numero e la complessità degli use case (casi d’uso) e degli attori nella
soluzione pianificata.
Un’altra importante attività svolta durante l’Analisi dei Requisiti è l’assegnazione della priorità.
L’assegnazione della priorità permette di definire l’importanza di un requisito e della relativa
implementazione. Questo consente di identificare e completare per primi i requisiti più cruciali.
L’assegnazione della priorità supporta lo sviluppo incrementale, poiché i requisiti possono essere
raggruppati per priorità e i requisiti con la priorità più alta possono essere pianificati nelle prime
iterazioni.
La procedura che definisce le priorità dei requisiti comprende le seguenti attività:
1. Raggruppamento dei Requisiti: include l’identificazione dei requisiti che hanno influenza o
dipendenza l’uno con l’altro (per esempio: requisiti che creano una funzionalità
complessa).
2. Analisi dei Requisiti: analisi dei requisiti raggruppati, eseguita da tutti gli stakeholder
interessati, per accordarsi sul livello di importanza e stabilire le priorità dei requisiti.
L’analisi degli impatti è spesso utilizzata per supportare l’analisi dei requisiti.
3. Creazione del piano di progetto dei requisiti: definizione di un piano, dove i requisiti con
priorità più alta devono essere sviluppati prima (sviluppo incrementale) e assegnazione
delle responsabilità per l’implementazione del requisito
Versione v2.1 - 2014
Pagina 70 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
4. Pianificazione dei test di sistema degli incrementi: progettazione dei casi di test, per
validare ogni incremento della soluzione in base alle priorità date ai requisiti per
l’incremento considerato.
Un approccio usato per l’assegnazione della priorità è raggruppare i requisiti in categorie di
priorità. Normalmente viene utilizzata una scala a tre livelli (esempio: alta, media, bassa). Poiché
tali scale sono soggettive e imprecise, tutti i principali stakeholder devono accordarsi sul significato
di ogni livello nella scala delle priorità che utilizzano. La definizione di priorità dovrebbe essere
chiara e definita come attributo chiave di ogni requisito.
Per le società di formazione: spiegare la procedura di assegnazione della priorità dei requisiti con
alcuni esempi. Spiegare il significato dell’assegnazione della priorità dei requisiti per la
pianificazione di una release/iterazione.
4. Approvazione dei Requisiti
L’accordo sui requisiti, spesso chiamata Approvazione dei requisiti o firma, è il quarto passo
dell’Analisi dei Requisiti. È un accordo formale che il contenuto e l’ambito dei requisiti siano
accurati e completi. È molto importante assicurare che i requisiti siano stati approvati nelle
differenti fasi dello sviluppo della soluzione, poiché un accordo formale è la base per le attività
successive. I requisiti di alto livello (requisiti di Business/Cliente) dovrebbero essere concordati
prima dell’inizio del progetto. I requisiti dettagliati (Requisiti di Soluzione/Sistema e Requisiti di
Componente/Prodotto) dovrebbero essere concordati e firmati prima di passare alla fase
implementativa. Ottenere l’approvazione dei requisiti è tipicamente l’attività finale della fase di
progetto di Analisi e Specifica dei Requisiti.
L’approvazione dei requisiti coinvolge generalmente gli stakeholder chiave di progetto, che
includono:





I Project Manager
Il rappresentante di business del cliente
Gli Analisti di Sistema e di Business
Gli Ingegneri dei Requisiti
I rappresentanti dei gruppi per la Garanzia della Qualità, per il test e lo sviluppo
Uno degli scopi dell’approvazione dei requisiti è quello di assicurare che i requisiti siano stabili, e
che ogni modifica successiva sia gestita tramite Change Request formali. Quindi, un accordo
formale riduce il rischio di introdurre nuovi requisiti nelle fasi successive (durante o dopo
l’implementazione).
Un’approvazione formale può anche minimizzare il rischio di incomprensioni tra il cliente ed il
fornitore sullo scopo del progetto, poiché tutti i requisiti o le Specifiche dei Requisiti/della
Soluzione dovrebbero essere attentamente revisionati prima dell’accordo.
L’accordo sui requisiti risulta completato quando tutti i principali stakeholder di progetto hanno
firmato (approvato) il documento dei requisiti.
Versione v2.1 - 2014
Pagina 71 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Il completamento dell’approvazione dei requisiti dovrebbe essere comunicato al gruppo di
progetto e normalmente è una milestone di progetto.
5.3.1 Modellazione della Soluzione
La modellazione della soluzione è spesso parte dell’Analisi e Specifica dei Requisiti poiché
permette di sviluppare modelli relativi a problematiche del mondo reale che possono essere
risolte con una soluzione di business specifica. La Modellazione della Soluzione può anche essere
eseguita durante l’Identificazione dei Requisiti, poiché alcune tecniche di identificazione utilizzano
differenti approcci o notazioni di modellazione (p.e. Identificazione dei Requisiti utilizzando gli use
case UML). L’obiettivo principale della Modellazione della Soluzione è di scegliere e sviluppare
diagrammi appropriati per la definizione di un modello, che descriva la soluzione di business da
differenti punti di vista. Questi modelli non dovrebbero soltanto rappresentare correttamente la
soluzione di business, ma dovrebbero essere comprensibili sia dai rappresentanti del cliente sia dai
rappresentanti del fornitore.
La Modellazione della Soluzione può utilizzare diversi tipi di modelli, ma in generale esistono tre
livelli principali di modelli:



Modello dei requisiti: descrive l’area del problema ed è generalmente progettato nelle fasi
iniziali del progetto. Questo modello viene utilizzato principalmente per l’Analisi dei
Requisiti e la stima dei costi e dei tempi, e fornisce una base per il Modello della soluzione
Modello della soluzione: descrive l’area della soluzione da differenti punti di vista e
determina l’idea dell’implementazione dei Requisiti Funzionali e Non Funzionali. Il modello
della soluzione di business fornisce una base per la progettazione della soluzione
Modello concettuale, chiamato anche Modello del dominio: rappresenta i concetti (entità)
e le relative relazioni tra di essi. Scopo del modello concettuale è di chiarire ed esprimere il
significato dei termini e dei concetti utilizzati dagli esperti di dominio per indirizzare il
problema di business, e stabilire le corrette relazioni tra concetti differenti.
In base al punto di vista che deve essere rappresentato, esiste la possibilità di usare modelli
differenti per i tre livelli. I punti di vista che sono applicabili alla modellazione del dominio del
problema o della soluzione sono:





Vista dell’utente (modellata dagli use case)
Vista logica (modellata dai Requisiti Funzionali)
Vista del processo (modellata da modelli di comunicazione o di interazione, oppure da
Requisiti Non Funzionali che specificano l’efficacia dei processi di business)
Vista implementativa (modellata da componenti della soluzione)
Vista fisica dell’installazione (modellata da modelli di integrazione e dall’architettura della
soluzione)
Diversi livelli di modellazione e differenti viste della soluzione possono essere descritti da diversi
tipi di diagrammi. Per riuscire ad ottenere una visione completa della soluzione, viene
Versione v2.1 - 2014
Pagina 72 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
normalmente utilizzata una combinazione di viste differenti. Questo si ottiene utilizzando diversi
diagrammi che descrivono il modello della soluzione da specifici punti di vista. Alcuni esempi di
modelli di analisi sono descritti nella Tabella 4.
Metodo di Analisi
Analisi del contesto
Modello di Analisi
Context Model
Deployment Di agram (UML)
Decomposizione funzionale
Requirement Diagram (SysML)
State Machine Diagram (UML)
Use Case Diagram (UML)
Activity Diagram (UML)
Communication Diagram (UML)
Business Process Model (BPMN)
Modello Entità-Relazioni (ERM)
Class Diagram (UML)
Analisi Logica
Analisi decisionale
Analisi degli Use Case
Analisi del flusso di processo
Analisi dei Dati
Tabella 4. Esempi di Modelli e Metodi di Analisi
Per le società di formazione: spiegare i benefici e le applicazioni dei modelli di analisi (che utilizzano
i context diagram, la decomposizione funzionale, i modelli di processi di business) e fornire alcuni
esempi del loro utilizzo.
Uno dei metodi più utilizzati per modellare le soluzioni software è Unified Modeling Language
(UML), che fornisce diversi tipi di diagrammi per descrivere diverse viste della soluzione. UML è
una notazione unificata per l’analisi e la progettazione di sistemi. Fornisce differenti tipi di
diagrammi suddivisi in Structure Diagram (diagrammi strutturali) e Behavior Diagram (diagrammi
comportamentali): uno Structure Diagram descrive gli elementi strutturali che costituiscono un
sistema o una funzione; un Behavior Diagram descrive le funzioni comportamentali di un sistema o
di un processo di business.
Versione v2.1 - 2014
Pagina 73 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Tabella 5. Diagrammi UML e loro applicazioni
Diagramma (UML 2.4.1)
Behavior Diagram
Activity Diagram
Use Case Diagram
State Machine Diagram
Timing Diagram
Sequence Diagram
Communication Diagram
Interaction Overview
Diagram
Structure Diagram
Class Diagram
Object Diagram
Package Diagram
Component Diagram
Deployment Diagram
Composite Structure
Diagram
Profile Diagram
Versione v2.1 - 2014
Applicazioni
Modellizza i comportamenti di un sistema ed il modo in cui questi sono
correlati all’intero flusso di attività.
Utilizzato generalmente per modellare procedure, flussi di processo e
flussi di lavoro (workflow).
Cattura gli Use Case e le relazioni tra gli Attori ed il Sistema.
Descrive i Requisiti Funzionali del sistema, il modo in cui gli operatori
esterni interagiscono ai margini (confini) del sistema, e le risposte del
sistema.
Mostra come un elemento può muoversi da uno stato all’altro,
classificando il comportamento in base ai trigger di transizione e ai
punti di controllo vincolanti.
Definisce il comportamento degli oggetti all’interno di una scala dei
tempi.
Fornisce una rappresentazione visuale dei cambiamenti di stato degli
oggetti e delle loro interazioni nel tempo.
Rappresentazione strutturata del comportamento come una serie di
passi sequenziali nel tempo.
Modellizza il flusso di lavoro (workflow), lo scambio di messaggi e
come gli elementi cooperano nel tempo per raggiungere un risultato.
Rappresenta le interazioni tra gli elementi durante l’esecuzione,
visualizzando le relazioni tra gli oggetti.
Modellizza la cooperazione con gli altri Interaction Diagram per
illustrare un flusso di controllo utile per l’obiettivo considerato.
Cattura la struttura logica del sistema, le classi e gli oggetti che
compongono il modello, e descrive COSA ESISTE e quali attributi e
comportamenti possiede.
Può essere utilizzato per modellare i dati.
Rappresenta le istanze di Classi e le loro relazioni in un certo istante.
Rappresenta l’organizzazione degli elementi del modello in package
(struttura) e le dipendenze tra loro.
Può essere utilizzato per organizzare i requisiti in base al loro
tipo/livello di astrazione.
Modellizza le parti di software che creano un sistema, come la loro
organizzazione e le dipendenze.
Descrive l’architettura del sistema in esecuzione.
Visualizza le collaborazioni interne di classi, interfacce e componenti (e
loro proprietà) che descrivono una funzionalità.
Permette di adattare il meta modello UML alle differenti piattaforme
(come J2EE, .NET) o ai diversi domini (come i sistemi real-time, la
modellazione dei processi di business).
Pagina 74 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Per modellare soluzioni più complesse, specialmente nell’Ingegneria dei Sistemi, può essere
utilizzata un’altra notazione di modellazione unificata, SysML (System Modeling Language). SysML
permette di modellare un ampio insieme di sistemi, includendo hardware, software, informazioni,
processi, organico del personale e servizi offerti. SysML riutilizza sette diagrammi UML e fornisce
due nuovi diagrammi per un totale di nove diagrammi: il Requirement Diagram, che modellizza i
Requisiti Funzionali, prestazionali e d’interfaccia, e il Parametric Diagram, che definisce i vincoli
quantitativi e prestazionali.
Per modellare flussi dei processi di business e la comunicazione tra i diversi attori di business, può
essere utilizzata un’altra notazione, come BPMN (Business Process Modelling Notation). BPMN
viene utilizzata nelle fasi iniziali dell’Analisi dei Requisiti oppure durante l’analisi dei processi di
business svolta all’interno dell’organizzazione del cliente.
Per modellare gli aspetti relativi all’Interfaccia Utente della soluzione pianificata (soprattutto nel
caso di soluzioni software), può essere utilizzata la modellazione GUI attraverso l’uso di prototipi
GUI (prototipizzazione GUI). I prototipi forniscono un modo di progettare e verificare elementi
dell’Interfaccia Utente. È utile soprattutto quando i requisiti non sono chiari oppure esistono
diverse soluzioni implementative; in questo caso i prototipi aiutano nello studio di fattibilità delle
diverse soluzioni e permettono agli stakeholder di scegliere la migliore opzione implementativa.
Esistono differenti tipi di prototipi [IBUQ]:



Prototipo verticale: implementazione di un numero ridotto, ma dettagliato, di singole
funzionalità.
Prototipo orizzontale: implementazione della maggior parte delle funzionalità, senza tener
conto degli aspetti non funzionali (principalmente utilizzato per il test dell’Interfaccia
Utente)
Prototipo di scenario: tutte le funzioni vengono simulate per l’esecuzione di una specifica
attività, implementando una combinazione di prototipo orizzontale e prototipo verticale.
In base allo scopo per cui vengono utilizzati, esistono differenti varianze dei prototipi [IBUQ]:



Prototipi di bassa fedeltà (low fidelity o lo-fi): hanno poca somiglianza con il prodotto
finale e permettono di verificare i benefici della soluzione
Prototipi di alta fedeltà (high fidelity o hi-fi): hanno forte somiglianza con il prodotto finale
e permettono di verificare i dettagli e l’esattezza delle funzioni
Prototipi ibridi: sono prototipi di bassa-alta fedeltà (lo-hi-fi) che utilizzano HTML o
PowerPoint® per eseguire simulazioni interattive.
Per le società di formazione: spiegare i benefici e le applicazioni dei diagrammi UML di base
(activity diagram, use case diagram, state machine diagram e class diagram) e fornire alcuni
esempi del loro utilizzo.
Versione v2.1 - 2014
Pagina 75 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
5.4 Specifica dei Requisiti
60 minuti
Lo Sviluppo dei Requisiti non è solo un processo di identificazione e analisi dei requisiti. È anche un
processo che facilita una comunicazione efficace delle informazioni relative a questi requisiti tra
differenti stakeholder. Il processo in cui i requisiti vengono documentati è di fondamentale
importanza perché porta a garantire che i requisiti vengano letti, analizzati, modificati e validati.
L’attività di documentazione dei requisiti viene chiamata Specifica dei Requisiti.
Una Specifica è un insieme esplicito di requisiti che devono essere soddisfatti da un componente,
prodotto o servizio; può essere considerato come un tipo di contratto che descrive il
comportamento e le funzionalità della soluzione. La Specifica serve per tracciare e gestire i
requisiti. Nella Specifica, i requisiti sono specificati in modo strutturato e sono modellati
separatamente (i requisiti sono modellati “indipendentemente”, poiché i requisiti di alto livello
sono decomposti fino ad un livello in cui ogni singolo requisito costituisce un’entità
“indipendente” che può essere successivamente implementata e tracciata). La Specifica è un
documento su cui si basa l’accordo formale dei requisiti che saranno implementati nel sistema (in
un componente, o in altre forme della soluzione) pianificato. La Specifica può quindi essere
considerata un risultato parziale o finale dell’Analisi dei Requisiti.
Il termine “Specifica” può essere utilizzato nel contesto dei requisiti (Specifica dei Requisiti) o della
soluzione (Specifica della Soluzione).
La Specifica dei Requisiti descrive l’area di interesse del problema (un’area di interesse può essere
per esempio una proposta di soluzione di un problema di business, di una nuova funzionalità, di
una esigenza, di un obiettivo, ecc.…) e contiene almeno le seguenti informazioni:


I requisiti di business, con i relativi criteri di accettazione
Le limitazioni e le assunzioni.
La creazione della Specifica dei Requisiti del cliente dovrebbe essere compito del cliente, anche se,
in alcuni casi, il fornitore può dare un supporto nella sua preparazione.
Una Specifica dei Requisiti non deve essere un documento formale di “Specifica”; potrebbe essere
per esempio uno Sprint Backlog o un insieme di requisiti memorizzati e gestiti in uno strumento di
Gestione dei Requisiti.
La creazione di altri tipi di Specifiche (quali la Specifica dei Requisiti di Sistema, la Specifica dei
Requisiti Software, la Specifica dei requisiti legali, ambientali, di sicurezza, ….) sono attività in
carico ad altri ruoli.
La Specifica della Soluzione descrive la soluzione da differenti punti di vista. Esistono diversi tipi di
Specifiche della Soluzione: Specifica Funzionale, Specifica dei Requisiti di Sistema e Specifica dei
Requisiti Software.
Versione v2.1 - 2014
Pagina 76 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Per esempio, una Specifica Funzionale è un documento che descrive in modo chiaro i requisiti
tecnici per la soluzione. La Specifica Funzionale fornisce la base per ulteriori sviluppi e verifiche del
prodotto, quindi deve fornire informazioni precise e dettagliate su tutti gli aspetti funzionali del
software che deve essere implementato. La Specifica Funzionale non descrive come saranno
implementate le funzioni del prodotto software richieste e non stabilisce il tipo di tecnologia che
verrà utilizzata. Si focalizza sulle funzionalità e sulle interazioni tra l’utente ed il prodotto.
Le Specifiche dei Requisiti e della Soluzione possono essere entrambe scritte sotto forma di use
case (use case di business oppure use case di sistema, in base allo scopo e ai destinatari della
Specifica).
Un altro tipo di Specifica è una user story. Le user story sono utilizzate nelle metodologie di
sviluppo Agile e permettono una veloce gestione dei requisiti dell’utente/cliente. L’intento di una
user story è quello di essere in grado di rispondere più velocemente e con meno sforzo alle
richieste di modifica dei requisiti.
Una user story descrive la funzionalità che sarà utile (darà valore) per l’utente. È composta da tre
aspetti [Cohn]:



Una parte descrittiva della storia, utilizzata per la pianificazione e come promemoria.
Viene espresso sotto forma di frase:
“COME un [ruolo dell’utente finale] DESIDERO CHE [desiderata] IN MODO TALE DA [il
razionale]”
Conversazioni sulla storia, utilizzate per arricchirla di dettagli
Verifiche e dettagli del documento, utilizzati per determinare quando la storia è
completata.
Le User Story sono spesso utilizzate insieme alle Personas (cioè caratteri archetipi) che
rappresentano uno specifico tipo di ruolo dell’utente finale.
L’attività di Specifica può essere supportata da standard che forniscono delle best practice o delle
linee guida su come scrivere uno specifico documento e sui relativi contenuti. Gli standard che
possono essere utilizzati nella creazione di una Specifica sono:



IEEE 830 (Software Requirements Specification, Raccomandazione per le Specifiche dei
Requisiti Software, oppure SRS)
IEEE 1233 (Guida per lo Sviluppo delle Specifiche dei Requisiti di Sistema, oppure SyRS)
IEEE 1362 (Guida per Information Technology – Definizioni di Sistema, oppure Concept of
Operations ConOps)
In generale, la Specifica serve come attività di formalizzazione dei risultati dell’Analisi dei Requisiti.
Le attività di identificazione, analisi e specifica permettono di raggiungere un accordo sui requisiti
(far riferimento al paragrafo 5.3 “Analisi dei Requisiti”).
La procedura per creare una Specifica della Soluzione include generalmente le seguenti attività:
Versione v2.1 - 2014
Pagina 77 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
1. Definizione della Vision e degli obiettivi
 Identificare l’obiettivo della soluzione (o di una area specifica della soluzione) che
verrà documentata nella Specifica della Soluzione
2. Identificazione degli stakeholder
 Individuare chi utilizzerà il prodotto
 Individuare chi è responsabile per le aree specifiche della soluzione e chi può
supportare o impattare nella creazione della Specifica della Soluzione
3. Definizione dei Requisiti
 Identificare i requisiti di alto livello (di business) che dovrebbero essere coperti
dalla Specifica
 Determinare le priorità dei requisiti
4. Specifica dei Requisiti strutturata
 Stabilire le dipendenze e le correlazioni tra i requisiti
 Determinare come possono essere organizzati i requisiti
5. Descrizione dell’ambiente del sistema
 Descrivere il contesto della soluzione
6. Definizione della soluzione
 Definire la soluzione e lo scopo, identificando gli aspetti correlati che sono al di
fuori dello scopo, ma che lo influenzano, come p.e. le interfacce ai sistemi esterni
7. Analisi dei Requisiti
 Analizzare in dettaglio i requisiti (decomposizione dei requisiti di business nei
requisiti di più basso livello, quali i requisiti di soluzione/sistema o di
funzione/componente)
 Determinare e risolvere gli eventuali conflitti tra i requisiti
 Mappare i requisiti di business nei requisiti di soluzione/sistema e creare una
struttura dei requisiti, per una loro tracciabilità
8. Modellazione del problema di business
 Modellare il problema di business che verrà risolto dalla soluzione attraverso
modelli di business (includendo la modellazione o l’aggiornamento dei processi di
business esistenti, se possibile), utilizzando le notazioni dei processi di business
(p.e. BPMN)
 Individuare come viene costruita la soluzione nella esistente infrastruttura di
business?
9. Modellazione della soluzione
 Modellare la soluzione (includendo caratteristiche del software, dell’hardware, dei
servizi, dei processi, in base al tipo di Specifica della Soluzione)
 Modellare la notazione per rappresentare la soluzione da diversi punti di vista
(p.e. UML, SysML)
La Procedura sopra descritta coinvolge gli stakeholder che stanno supportando l’attività di
Specifica nelle differenti aree interessate e formalizza il risultato del processo di Analisi dei
Versione v2.1 - 2014
Pagina 78 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Requisiti. I singoli passi della procedura potrebbero essere svolti in parallelo, iterativamente o
addirittura possono essere saltati; questo dipende dall’informazione già disponibile e
dall’approccio di Ingegneria dei Requisiti selezionato (p.e. nelle metodologie Agile, la procedura
per la Specifica della Soluzione non è così formale perché si basa su una descrizione più snella dei
requisiti e della soluzione). L’output della procedura, la Specifica della Soluzione, è il punto di
partenza per la progettazione del software, hardware e database. Descrive le funzionalità del
sistema (Specifiche Funzionali e Non Funzionali), le prestazioni, i vincoli operativi e sull’interfaccia
utente.
La documentazione di prodotto, che include le Specifiche dei Requisiti e della Soluzione, può
essere creata utilizzando tre differenti livelli di formalizzazione:



Non formale
Semi formale
Formale
Un approccio non formale nella scrittura delle Specifiche utilizza il linguaggio comune per definire
il documento, senza alcuna notazione formale. Questo approccio può essere utilizzato quando i
lettori non hanno esperienza con linguaggi di Specifica tecnici e più formali, e potrebbero avere
difficoltà nella comprensione del contenuto del documento. La principale debolezza di questo
approccio è dovuta al fatto che può creare ambiguità e rendere possibili incomprensioni e
sbagliate interpretazioni. In aggiunta, una Specifica non formale non è una buona base per le
successive fasi di implementazione ed test poiché non è abbastanza chiara e precisa.
Una Specifica semi formale include alcune notazioni formali ed è ben strutturata. Normalmente
tali Specifiche sono basate su un modello (template) ben specificato, spesso derivato da standard
di riferimento. Specifiche semi formali possono esprimere requisiti sotto forma di modelli ed
utilizzare un linguaggio comune formalizzato. Una delle più comuni notazioni utilizzate per la
documentazione semi formale è UML.
Una Specifica formale è una descrizione matematica e/o algoritmica di una soluzione, che può
essere utilizzata per sviluppare un’implementazione. Una Specifica formale descrive CHE COSA il
sistema dovrebbe fare, non come il sistema dovrebbe farlo. Poiché è basata su formule
matematiche o su uno specifico linguaggio (p.e. VDM Specification Language, VDM-SL) ed è molto
più difficile da comprendere, questo approccio è usato molto raramente e richiede conoscenze
specifiche.
Versione v2.1 - 2014
Pagina 79 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
5.5 Verifica e Validazione dei Requisiti
20 minuti
Poiché i requisiti sono la base per lo sviluppo di un sistema, qualsiasi errore o mancanza sui
requisiti si propaga sugli altri processi di sviluppo nel progetto. E’ importante notare che i difetti
causati da Requisiti di scarsa qualità richiedono un costo più alto per correggerli nelle fasi avanzate
del progetto, rispetto ad altri tipi di difetti. In aggiunta, più tardi i difetti vengono riscontrati,
maggiori saranno i costi per risolverli.
Quindi, la Verifica (stiamo producendo il prodotto correttamente?) e la Validazione (stiamo
producendo il prodotto giusto?) dei requisiti sono attività necessarie, che dovrebbero essere
svolte in modo continuo e sistematico durante lo sviluppo della soluzione, in modo da assicurare
lo sviluppo di un prodotto che rispetti i criteri di qualità e soddisfi le esigenze degli stakeholder. Le
best practice richiedono di pianificare ed eseguire la Validazione e Verifica dei requisiti già fin dalle
prime fasi dello sviluppo della soluzione, idealmente durante l’Identificazione dei Requisiti. Le
tecniche utilizzate per la Validazione e la Verifica includono differenti tipi di review, la
prototipizzazione o la presentazione delle soluzioni o dei requisiti proposti agli stakeholder, con
l’obiettivo di raccogliere feedback.
Queste attività dovrebbero anche assicurare che i requisiti e/o le Specifiche dei Requisiti/della
Soluzione rispettino gli standard aziendali (template o modelli), siano documentati e quindi
verificati rispetto ai criteri di qualità (far riferimento al capitolo 1.1.4 “Qualità dei requisiti”). È
anche importante validare i modelli sviluppati durante le attività di Analisi e Specifica dei Requisiti.
Poiché i requisiti sono la base per lo sviluppo ed il test della soluzione, la loro qualità è cruciale per
il successo del progetto. Requisiti chiari, completi, consistenti e verificabili riducono il rischio di
fallimento del prodotto (e ancora di più del progetto), poiché permettono un’attività di test
accurata. È quindi raccomandato coinvolgere i tester nella review dei requisiti, poiché possono
significativamente aiutare a migliorare la qualità dei requisiti e delle Specifiche dei Requisiti/della
Soluzione attraverso l’identificazione dei possibili difetti e punti deboli.
La testabilità dei requisiti è supportata dai Criteri di Accettazione. I Criteri di Accettazione
descrivono criteri che devono essere soddisfatti per approvare la soluzione e dovrebbero essere
concordati da entrambe le parti – il fornitore e il cliente - prima di iniziare il progetto. Le best
practice richiedono di definire Criteri di Accettazione come parte della documentazione di
contratto. Ogni requisito di alto livello deve avere almeno un criterio di accettazione; ogni criterio
deve essere misurabile e i mezzi per misurare i criteri devono essere realistici e concordati. Tali
Criteri sono spesso la base per il Test di Accettazione e il Piano di Qualità del progetto.
Per le società di formazione: fornire esempi di Criteri di Accettazione per requisiti.
Versione v2.1 - 2014
Pagina 80 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
6 Ingegneria dei Requisiti nei Modelli
140 minuti
Termini
Modello Agile, Modello Incrementale, Modello Iterativo, Modello Sequenziale, Ciclo di Vita del
Prodotto, CMMI, Modello di Maturità, Modello di Processo, Product Backlog, Product Owner,
Rational Unified Process, SPICE
Obiettivi di Apprendimento per i Fondamenti dell’Ingegneria dei Requisiti
Gli obiettivi identificano quello che dovrai essere in grado di dimostrare a seguito del
completamento di ogni singolo modulo.
6.1 Modelli di Sviluppo e Manutenzione e Relativi Approcci
LO-6.1.1
Riassumere le caratteristiche principali di un modello di ciclo di vita del
prodotto (K2)
LO-6.1.2
Riconoscere le similitudini e le differenze nel processo di Ingegneria dei
Requisiti tra i modelli più comuni utilizzati per descrivere lo sviluppo del
prodotto o il processo di manutenzione (K2)
6.2 Modelli di Maturità
LO-6.2.1
Comprendere come l’Ingegneria dei Requisiti sia parte dei comuni Modelli
di Maturità (K2)
Versione v2.1 - 2014
Pagina 81 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
6.1 Modelli di Sviluppo e Manutenzione e
relativi Approcci
110 minuti
La struttura del processo di Ingegneria dei Requisiti dipende spesso dal modello di sviluppo
utilizzato. Il processo generico di Ingegneria dei Requisiti dovrebbe essere adattato per rispettare
le esigenze specifiche e l’ambiente di sviluppo.
Scopo di questo capitolo è fornire alcuni esempi di come vengono svolte le attività di Ingegneria
dei Requisiti in alcuni tipi standard di modelli di sviluppo.
I Modelli di Processo sono descrizioni di processi di sviluppo indipendenti dal metodo. Un modello
di processo software prende in considerazione ruoli, attività, fasi e documenti e definisce un
formato standard per la pianificazione, l’organizzazione e l’esecuzione di un progetto.
Un generico Ciclo di Vita del Prodotto (PLC, Product Life Cycle) definisce le varie fasi dello sviluppo
del prodotto. Le fasi principali sono: pianificazione, sviluppo, manutenzione e fine dell’utilizzo (end
of life). La fase di sviluppo è generalmente suddivisa in diverse fasi, spesso eseguite iterativamente
(far riferimento alla Tabella 2. Principali attività, gli input ed output ai processi dell’Ingegneria dei
RequisitiFigura 2).
Figura 2. Generico Ciclo di Vita del Prodotto (PLC)
Versione v2.1 - 2014
Pagina 82 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Questo generico Ciclo di Vita del prodotto è la base per modelli di sviluppo differenti.
In generale, i modelli di sviluppo possono essere classificati in approcci tradizionali e approcci
Agile.
Gli approcci tradizionali possono essere modelli sequenziali, modelli iterativi e modelli
incrementali (spesso questi ultimi due modelli vengono combinati insieme).
Il modello di sviluppo più semplice, il modello a cascata (o Waterfall) è un modello sequenziale e
può essere visto come una rappresentazione lineare del processo generico di Ingegneria dei
Requisiti, che si basa sull’assunzione che tutti i requisiti possono essere raccolti, definiti e analizzati
nella fase iniziale del ciclo di vita, e non saranno successivamente soggetti a modifiche. La
debolezza principale di questo modello è la poca adattabilità ai cambiamenti. Questa debolezza ha
portato ad eliminare l’applicazione di tale modello da molti progetti moderni, dove i requisiti si
modificano nel tempo a causa dei cambiamenti del business, della tecnologia o del mercato.
Il modello originale a cascata è stato successivamente esteso in un generico modello a V (VModel). Il miglioramento principale di questo modello sequenziale è la distinzione tra livelli di
sviluppo e livelli di test, dove ogni livello di sviluppo ha associato uno specifico livello di test. Il
modello può essere visto come una decomposizione dei requisiti attraverso diversi livelli di
dettaglio, dove ogni livello ha un livello di test associato.
Questo modello è molto efficace durante le fasi di Sviluppo di Ingegneria dei Requisiti, fornendo
una buona base per la Gestione dei Requisiti attraverso la tracciabilità e le attività di Change
Management. Lo Sviluppo dei Requisiti in un V-Model può comunque essere difficoltoso, poiché è
quasi impossibile assicurare che tutti i requisiti importanti saranno identificati nelle prime fasi del
progetto. Molto spesso l’ambito iniziale del prodotto aumenta durante le fasi successive del
progetto, a causa di nuovi requisiti provenienti da differenti stakeholder e da sistemi/ambienti
circostanti. Questo richiede un’attività intensa di rielaborazione e di Change Management.
Il V-Model può essere considerato uno dei modelli migliori sia per lo Sviluppo dei Requisiti sia per
la Gestione dei Requisiti, quando le aree applicative individuate sono ben definite e stabili.
Per le società di formazione: rappresentazione grafica del V-Model generale e descrizione del
processo di Ingegneria dei Requisiti nel V-Model generico.
In caso di soluzioni più complesse o instabili, è raccomandato l’uso di modelli iterativi o
incrementali. L’approccio iterativo/incrementale si basa sul fatto che i requisiti sono spesso difficili
da specificare, soprattutto nei sistemi commerciali. Tecniche per lo sviluppo iterativo e
incrementale considerano fondamentale la cooperazione e la collaborazione tra sviluppatori e
utenti/clienti. I requisiti sono spesso definiti soltanto in termini di obiettivi di business, che
vengono elaborati durante le iterazioni successive.
Versione v2.1 - 2014
Pagina 83 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Lo sviluppo incrementale considera un insieme di requisiti suddiviso in sottoinsiemi più piccoli,
dove ogni sottoinsieme viene sviluppato attraverso incrementi o passi. L’idea su cui si basa è che
ogni parte possa essere implementata e, nel caso migliore, rilasciata in modo completo, riducendo
il time-to-market. Permette inoltre di avere un riscontro immediato degli incrementi rilasciati da
parte del cliente, che può aiutare a migliorare la realizzazione dei successivi incrementi. In questo
modo vengono ridotti i rischi (soprattutto se confrontata con una strategia di un “unico rilascio”)
poiché, anche se il progetto viene chiuso prima del suo completamento, gli stakeholder possono
avere dei benefici dagli incrementi che sono già stati completati.
L’approccio iterativo è particolarmente utile nei grandi progetti con un ampio numero di requisiti.
L’idea principale dell’approccio iterativo è quella di sviluppare una soluzione in parti più piccole
attraverso cicli ripetuti (ognuno dei quali può essere visto come un mini ciclo di vita). L’obiettivo di
tale approccio è di riuscire a controllare maggiormente il progetto, monitorando e indirizzando in
modo sistematico il rischio. Un esempio di modello iterativo è RUP©, Rational Unified Process, un
modello di processo sviluppato da IBM Rational.
RUP è un modello per lo sviluppo di prodotti software in un contesto object-oriented. Un progetto
è organizzato in quattro fasi principali: Concezione (inception), Elaborazione (elaboration),
Costruzione (construction), Transizione (transition). Ogni fase è definita dal modello RUP
attraverso obiettivi e prodotti. RUP è un modello iterativo, dove i contenuti dell’iterazione
vengono selezionati sulla base dei rischi degli elementi che devono essere implementati. Il numero
di iterazioni in una specifica fase può essere differente e viene adattata in base alle necessità
specifiche del progetto o del prodotto. L’attività di Ingegneria dei Requisiti è generalmente
coperta dalle discipline Requisiti e Analisi e Progettazione definite dal modello RUP.
Per le società di formazione: approfondire RUP© con la presentazione grafica e uno studio
approfondito della disciplina dei requisiti.
Tutti i modelli di processo descritti sopra appartengono ai cosiddetti approcci tradizionali, che in
generale non supportano le modifiche frequenti ai requisiti in modo efficace, pur essendo la
principale sfida che normalmente devono superare. Come soluzione a questo problema, sono stati
implementati i cosiddetti modelli Agile. Gli approcci Agile sono basati sul Manifesto Agile, che
presenta un insieme di principi e valori utilizzati negli ambienti Agile. I principi Agile più importanti
sottostanti al Manifesto Agile sono [Manifesto Agile]:




La massima priorità è soddisfare il cliente attraverso rilasci di software di valore, fin da
subito e in maniera continua
I cambiamenti nei requisiti sono accolti positivamente, anche negli stadi avanzati dello
sviluppo
Il Software funzionante viene consegnato frequentemente (con cadenza variabile da due
settimane a un paio di mesi, preferendo periodi brevi)
La semplicità, cioè l’arte di massimizzare la quantità di lavoro non svolto, è essenziale
Versione v2.1 - 2014
Pagina 84 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”

Le riflessioni del gruppo vengono svolte regolarmente per valutare come diventare più
efficaci, a partire dal quale il proprio comportamento viene regolato e adattato di
conseguenza.
Le implicazioni di questi principi sull’Ingegneria dei Requisiti sono molto significativi. Negli
ambienti Agile, i requisiti vengono spesso comunicati e tracciati attraverso diversi tipi di
meccanismi, come lista delle attività da fare (Product Backlog), modelli dimostrativi visuali (mockup), storie proposte dai clienti (user story) o cartelle di storie (story card). L’approvazione dei
requisiti viene raggiunta collettivamente dal Team di sviluppo oppure da un responsabile del team
con potere di approvazione. La tracciabilità e la consistenza tra i requisiti e i prodotti potrebbero
essere indirizzate sia attraverso i meccanismi già descritti (Product Backlog, user story, …) sia
durante le fasi iniziali o finali dell’iterazione, attraverso momenti di retrospezione (“retrospective”,
“lessons learned”) o dimostrazioni (“demo day”). Il processo di Gestione dei Requisiti non è quindi
così formale come nei modelli di sviluppo/manutenzione tradizionali.
Il processo di Sviluppo dei Requisiti è strettamente correlato alla definizione di una specifica
descrizione e all’analisi di user story o scenari. Nel modello Agile, molte delle attività normalmente
eseguite durante lo Sviluppo dei Requisiti non vengono descritte, perché ci si aspetta che vengano
eseguite dal gruppo di sviluppo Agile, sotto la responsabilità del Product Owner.
Negli ambienti Agile, le esigenze e le idee del cliente vengono iterativamente identificate,
elaborate, analizzate e validate. I requisiti possono essere raccolti in backlog e documentati
(specificati) sotto forma di user story, scenari o use case. La scelta dei requisiti in un’iterazione è
guidata dalla valutazione del rischio e dalle priorità associate, che sono riportate nel Product
Backlog. Il livello di dettaglio della documentazione dei requisiti (e degli altri prodotti) viene
definito in base alla necessità di coordinamento e di controllo (tra membri del gruppo, tra gruppi,
e per le successive iterazioni) e al valore del rischio di perdita della conoscenza acquisita sul
prodotto. Quando il cliente fa parte del gruppo di lavoro, può esistere ancora l’esigenza di
mantenere separate la documentazione di prodotto da quella del cliente, per permettere di
esplorare più soluzioni. Non appena una soluzione emerge, vengono identificate le responsabilità
per i requisiti derivanti da tale soluzione, allocandole appropriatamente nel gruppo.
Esempi di approcci Agile sono Extreme Programming e Scrum.
Extreme Programming è una metodologia di sviluppo software sviluppata da Kent Beck e altri, con
lo scopo di rispondere all’esigenza di poter modificare i requisiti del cliente, quando richiesto.
Supporta frequenti rilasci software verso il cliente in cicli di sviluppi brevi (time box), che
permettono di migliorare la produttività e forniscono punti di controllo (checkpoint), dove nuovi
requisiti possono essere presi in considerazione.
Alcune caratteristiche di Extreme Programming includono:


Evitare di pianificare funzionalità finché non sono realmente necessarie
Aspettarsi modifiche dei requisiti da parte del cliente poiché con il trascorrere del tempo,
il problema viene meglio compreso
Versione v2.1 - 2014
Pagina 85 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”


Rendere possibile la comunicazione frequente con il cliente e tra i programmatori
Rinunciare alla fase di determinazione del requisito (non esiste una “fase” separata di
gestione e sviluppo dei requisiti prima dell’implementazione; lo sviluppo, il raffinamento e
la discussione del requisito fanno parte della fase di implementazione/programmazione
del software)
Scrum è una metodologia Agile che contiene un insieme di regole e ruoli predefiniti.
Una delle principali caratteristiche dello Scrum è dividere la fase di sviluppo in iterazioni della
durata da due a quattro settimane, chiamate Sprint, in cui il Gruppo crea il cosiddetto “incremento
di prodotto potenzialmente utilizzabile”.
I progetti Scrum permettono di gestire i requisiti attraverso delle liste “backlog”. Esistono due tipi
di backlog:


Product Backlog: lista di alto livello mantenuta aggiornata durante tutto il progetto, che
aggrega tutti i requisiti sotto forma di descrizioni sommarie di tutte le funzioni,
prioritizzate secondo un valore di business. E’ l'elenco principale di tutte le funzionalità
desiderate che potenzialmente faranno parte del prodotto. Il Product Backlog è di
proprietà del Product Owner.
Sprint Backlog: lista delle attività che devono essere indirizzate dal Team di sviluppo
durante il successivo Sprint. Le funzionalità vengono suddivise in attività che, come best
practice, dovrebbero avere una durata da quattro a sedici ore lavorative. Lo Sprint Backlog
è di proprietà del Team di sviluppo.
Il principale impatto dello Scrum sull’Ingegneria dei Requisiti è che le Specifiche dei Requisiti non
vengono completate e approvate prima dell’inizio dell’implementazione.
Il Product Owner ed il Team raggiungono un accordo sulle funzionalità del Product Backlog che
faranno parte dello Sprint successivo, sulla base della priorità di business e dello sforzo richiesto. I
requisiti utente vengono formulati dal Product Owner come «user story», che contengono
informazioni su un requisito relative a “CHI; COSA; PERCHE’” e non a “COME”. All’inizio dello
Sprint, le funzionalità scelte vengono suddivise in attività dello Sprint Backlog e vengono quindi
sviluppate.
Il coinvolgimento dei Product Owner, p.e. per presentare le funzioni software richieste, può
aiutare a chiarire i requisiti al Team e ai Product Owner stessi.
Per le società di formazione: fornire esempi di user story e dei corrispondenti elementi del Product e
Sprint Backlog.
Versione v2.1 - 2014
Pagina 86 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
6.2 Modelli di Maturità
30 minuti
Il processo di Ingegneria dei Requisiti può essere migliorato come qualsiasi altro processo definito
come parte dello sviluppo o della manutenzione di un prodotto/soluzione. I miglioramenti
possono essere applicati ad ogni singola attività dell’Ingegneria dei Requisiti. Per esempio,
l’Identificazione dei Requisiti può essere migliorata per raccogliere i requisiti del cliente in modo
più efficace. L’organizzazione può quindi introdurre l’uso di tecniche che assicurano che i requisiti
siano definiti più velocemente, siano completi e siano approvati dalla maggior parte degli
stakeholder. Queste tecniche includono interviste, brainstorming, scenari, prototipi, utilizzo di
archetipi (Personas).
L’impiego di Modelli di Maturità è un metodo generale per migliorare il processo di Ingegneria dei
Requisiti. Questi modelli richiedono di valutare l’attuale livello di maturità del processo e di
identificare le aree di miglioramento. I Modelli di Maturità utilizzano spesso Livelli di Maturità, che
aiutano nell’identificazione e nella comprensione della maturità dei processi di un’organizzazione
(Valutazione del Processo), e aiutano nel miglioramento di un’organizzazione (Miglioramento del
Processo).
Esempi di Modelli di Maturità che possono essere applicati all’Ingegneria dei Requisiti sono
ISO/IEC 15504 (SPICE – Software Process Improvement and Capability Determination) e Capability
Maturity Model Integrated (CMMI). Entrambi i modelli definiscono cinque livelli di maturità per
specifici processi o aree, e permettono di confrontarne la maturità in differenti organizzazioni.
ISO/IEC 15504 (SPICE – Software Process Improvement and Capability Determination) è un insieme
di standard tecnici per il processo di sviluppo software e le relative funzioni di gestione del
business. SPICE può essere utilizzato per misurare il miglioramento del processo e/o di
determinarne la capacità (p.e. valutazione delle capacità di processo del fornitore). SPICE definisce
cinque livelli di maturità per i seguenti processi: Cliente-Fornitore, Ingegneria, Supporto, Gestione
e Organizzazione. I cinque livelli sono:
1
2
3
4
5
Processo eseguito
Processo gestito
Processo stabilito
Processo predicibile
Processo di ottimizzazione
Nel modello SPICE, esistono le seguenti Aree Chiave di Processo relative all’Ingegneria dei
Requisiti:



ACQ1 Preparazione all’acquisizione BP1-3
ENG1 Identificazione dei Requisiti BP1-6
ENG2 Analisi dei Requisiti di Sistema BP1-6
Versione v2.1 - 2014
Pagina 87 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”

ENG4 Analisi dei Requisiti Software BP1-6
Il modello Capability Maturity Model Integrated (CMMI) definisce cinque livelli di maturità per lo
sviluppo, i servizi e l’acquisizione:
1
2
3
4
5
Iniziale
Gestito
Definito
Quantitativamente Gestito
Ottimizzazione (Miglioramento continuo)
Nel modello CMMI, esistono le seguenti Aree Chiave di Processo relative all’Ingegneria dei
Requisiti:


REQM Gestione dei Requisiti
RD Sviluppo dei Requisiti
Lo stesso processo di Ingegneria dei Requisiti può essere utilizzato per migliorare il processo di
sviluppo, perché velocizza i tempi delle attività implementative: elimina gli sprechi di tempo
necessari a chiarire e specificare i requisiti, riduce il numero di difetti causati da errori nella
Specifica dei Requisiti e/o da incomprensioni e ambiguità dovuti a documentazione di bassa
qualità. Un buon processo di Ingegneria dei Requisiti aumenta la qualità del test, fornendo
requisiti ben descritti, precisi e verificabili; inoltre rende più semplice e affidabile il test di
accettazione che si basa generalmente sui requisiti.
Per le società di formazione: descrivere i requisiti tipici per il processo di Ingegneria dei Requisiti nei
Modelli di Maturità dei processi.
Versione v2.1 - 2014
Pagina 88 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
30 minuti
7 Supporto degli Strumenti
Termini
Categorie di Strumenti, Progetto Pilota, Proof of Concept, Strumento di Change Management,
Strumento di Defect Management, Strumento di Gestione dei Requisiti, Strumento per
l’Identificazione (Elicitazione) dei Requisiti, Strumento di Modellazione, Strumento di Project
Management, Strumento di Prototipizzazione
Obiettivi di Apprendimento per i Fondamenti dell’Ingegneria dei Requisiti
Gli obiettivi identificano quello che dovrai essere in grado di dimostrare a seguito del
completamento di ogni singolo modulo.
7.1 Vantaggi degli Strumenti
LO-7.1.1
Spiegare i vantaggi nell’utilizzo di strumenti per supportare le differenti
attività nell’Ingegneria dei Requisiti (K2)
7.2 Categorie di Strumenti
LO-7.2.1
Comprendere lo scopo e l’utilizzo delle differenti categorie di strumenti
che supportano l’Ingegneria dei Requisiti (K2)
7.3 Selezionare gli Strumenti
LO-7.3.1
Spiegare i fattori importanti che devono essere considerati quando si
seleziona uno strumento per l’Ingegneria dei Requisiti (K2)
LO-7.3.2
Spiegare il processo di introduzione di uno strumento in un’organizzazione
(K2)
Versione v2.1 - 2014
Pagina 89 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
7.1 Vantaggi degli Strumenti
10 minuti
Esistono diversi strumenti che supportano specifiche attività di Ingegneria dei Requisiti.
Una comune applicazione degli strumenti è quella per la memorizzazione e l’amministrazione dei
requisiti. Molti strumenti di Gestione dei Requisiti forniscono un repository comune per la
memorizzazione dei requisiti, permettendo di organizzare i requisiti e mantenerne la tracciabilità.
Documenti complessi e in aggiornamento possono essere quindi mantenuti consistenti e
aggiornati. Altri strumenti possono automatizzare alcune attività meccaniche e possono fornire
differenti tipi di statistiche e di reportistica. Gli strumenti di modellazione utilizzano specifiche
notazioni di modellazione dei requisiti, come UML e BPMN, e spesso includono la generazione
della documentazione dei requisiti (creazione delle Specifiche dei Requisiti) a partire dai modelli.
In generale, gli strumenti possono supportare le seguenti attività nell’Ingegneria dei Requisiti:






Identificazione e memorizzazione dei requisiti
Definizione e mantenimento della tracciabilità dei requisiti
Modellazione dei requisiti e della soluzione (include la prototipizzazione e la modellazione
del business)
Documentazione dei requisiti (creazione delle Specifiche dei Requisiti)
Creazione della Reportistica
Configuration Management e Change Management
Alcuni dei vantaggi dovuti all’utilizzo di strumenti sono:






Garantire che tutti i requisiti siano memorizzati in un unico posto e siano accessibili da
tutti gli stakeholder coinvolti
Supportare la tracciabilità dei requisiti (p.e. la tracciabilità nei casi di test), che può essere
utilizzata per verificare la copertura dei requisiti principali
Gestire le modifiche dei requisiti in modo semplice, considerando anche il controllo di
configurazione
Migliorare la qualità delle Specifiche dei Requisiti, forzando l’uso di specifici modelli dei
documenti e delle notazioni di modellazione
Risparmio di tempo con l’automatismo di alcune attività (come la generazione di
Specifiche complete)
Fornire informazioni per prendere decisioni (p.e., metriche che indicano il numero di
requisiti implementati)
Versione v2.1 - 2014
Pagina 90 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
7.2 Categorie di Strumenti
10 minuti
Gli strumenti che supportano le attività dell’Ingegneria dei Requisiti possono essere classificati
come segue:







Strumenti di Gestione dei Requisiti
Strumenti per l’Elicitazione (identificazione) dei Requisiti
Strumenti di Modellazione dei Requisiti
Strumenti di Prototipizzazione
Strumenti di Defect Management
Strumenti di Configuration Management e Change Management
Strumenti di Project Management
Molti strumenti supportano più di un’attività, p.e. gli strumenti di modellazione supportano la
possibilità di avere un unico repository dove memorizzare i requisiti, con funzioni di Configuration
Management e Change Management, supportano differenti notazione di modellazione,
permettono di generare documentazione e statistiche.
Per le società di formazione: presentare un esempio di strumento che supporti almeno due attività
di Ingegneria dei Requisiti e fornire alcuni esempi pratici.
Versione v2.1 - 2014
Pagina 91 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
7.3 Selezionare gli Strumenti
10 minuti
La selezione di uno strumento deve avvenire prima che il prodotto venga sviluppato, per evitare
che si verifichino problemi dovuti al cambiamento di uno strumento in piena fase progettuale.
Il costo per l’acquisto di uno strumento è variabile. Gli strumenti commerciali possono essere
molto costosi, mentre gli strumenti open source sono gratis. La scelta di uno strumento deve
essere fatta con molta cura. Prima di selezionare uno strumento, dovrebbe essere condotta
un’analisi, che consideri i seguenti punti:







Valutazione della maturità organizzativa, i punti di forza e di debolezza, ed identificazione
delle opportunità di miglioramento per un processo di Ingegneria dei Requisiti supportato
da strumenti
Valutazione basata sui requisiti relativi alle funzionalità richieste dallo strumento
Svolgere un proof-of-concept (POC), che permetta di utilizzare lo strumento durante la
fase valutativa. L’obiettivo è stabilire se lo strumento operi in modo efficace con il
processo di Ingegneria dei Requisiti considerato, valutare la sua integrazione all’interno
dell’infrastruttura attuale, e identificare quali potenziali modifiche sono necessarie
sull’infrastruttura esistente
Stima di un ROI (Return of Investment) basata su un concreto business case, che includa
l’analisi dei costi di uno strumento utilizzato per un singolo progetto rispetto al suo utilizzo
in molti/tutti i progetti
Valutazione dell’integrazione dello strumento di Ingegneria dei Requisiti con altri
strumenti necessari (come lo strumento di Defect Management o di Project Management)
Valutazione della necessità che lo strumento di Ingegneria dei Requisiti scambi
informazioni con altri strumenti usati dall’organizzazione del cliente (in alcuni casi il cliente
conduce la propria Analisi dei Requisiti; in questo caso i dati relativi al risultato dovrebbero
essere migrati nell’ambiente del fornitore per svolgere le successive attività di progetto).
Valutazione della facilità d’uso e di apprendimento (costo potenziale della fase di
formazione), della disponibilità di un help online, di manuali, di tutorial, o di altro
supporto.
L’introduzione dello strumento selezionato all’interno dell’organizzazione dovrebbe partire con un
progetto pilota, che ha i seguenti obiettivi:



Comprendere in modo più dettagliato lo strumento
Valutare come lo strumento si adatta ai processi e alle pratiche esistenti, e determinare
cosa sarebbe necessario modificare
Definire le modalità standard di utilizzo, gestione, memorizzazione e manutenzione dello
strumento e degli asset dell’Ingegneria dei Requisiti
Versione v2.1 - 2014
Pagina 92 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
I progetti pilota diminuiscono il rischio nell’introduzione di strumenti, infatti un’analisi dello
strumento non appropriata o affrettata può portare ad alti costi:





Costo nell’acquisto di uno strumento che non soddisfa i requisiti degli stakeholder e non
raggiunge lo scopo prefissato
Costo nell’acquisto di uno strumento caro, che può essere utilizzato solo per un progetto
oppure costo nell’acquisto di uno strumento caro, quando esistono strumenti open source
con funzionalità similari
Costo della formazione in caso di acquisto di uno strumento per cui non esiste un
sufficiente sistema di apprendimento (specialmente nel caso lo strumento sia richiesto per
funzionalità di base)
Costo per estendere lo strumento acquistato con funzionalità aggiuntive non supportate
(mentre esistevano altri strumenti con tali funzionalità)
Costo di integrazione dello strumento con altri strumenti utilizzati dall’organizzazione
I fattori di successo per l’introduzione di uno strumento sono:





Introduzione incrementale dello strumento nell’organizzazione
Adattamento e miglioramento dei processi per un appropriato utilizzo dello strumento
Erogare formazione per i nuovi utenti, che includa la definizione di linee guida per l’utilizzo
dello strumento
Raccogliere informazioni e riscontri riguardo l’utilizzo dello strumento (includendo
metriche e lessons learned)
Monitoraggio sull’utilizzo dello strumento e sui relativi benefici.
Versione v2.1 - 2014
Pagina 93 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
8 Letteratura
Standard
IEEE 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology
IEEE 830-1998 IEEE Recommended Practice for Software Requirements Specifications
IEEE 1233-1998 IEEE Guide for Developing System Requirements Specifications
IEEE 1362-1998 IEEE Guide for Information Technology-System Definition – Concept of Operations
(ConOps) Document
IEEE 830, IEEE 1233 and IEEE 1362 are replaced by ISO/IEC/IEEE 29148:2011
ISO 9000 Quality management
ISO 12207 Systems and software engineering — Software life cycle processes
ISO 15288 System Life Cycle Processes
ISO 15504 Information technology — Process assessment, also known as SPICE (Software Process
Improvement and Capability Determination),
ISO 31000 Risk Management - Principles and Guidelines on Implementation
ISO/EIC 25000 (previously ISO/IEC 9126 Software engineering — Product quality)
ISO/IEC 14598-1:1999 Information technology -- Software product evaluation
SWEBOK - The Guide to the Software Engineering Body of Knowledge:
http://www.computer.org/portal/web/swebok/home
SEBOK – Systems Engineering Body of Knowledge: http://www.sebokwiki.org/
Libri e Pubblicazioni
Cockburn, A.: Writing Effective Use Cases. Amsterdam 2000
Cohn M.: Estimating With Use Case Points, Fall 2005 issue of Methods & Tools
Cotterell, M. and Hughes, B.: Software Project Management, International Thomson Publishing 1995
Davis, A. M.: Just Enough Requirements Management. Where Software Development Meets
Marketing, Dorset House, 2005, ISBN 0932633641
DeMarco, T.: Controlling Software Projects: Management, Measurement and Estimates. Prentice Hall
1986
Doran, G. T.: There's a S.M.A.R.T. way to write management's goals and objectives. Management
Review, Volume 70, Issue 11, 1981, (AMA FORUM), pp. 35-36.
Evans, E. J.: Domain-Driven Design: Tackling Complexity in the Heart of Software. Amsterdam 2003
Graham, D. et al: Foundations of Software Testing. London 2007
Gilb, T.; Graham, D.: Software Inspection. Reading, MA 1993
Gilb, T.: What's Wrong with Requirements Specification. See: www.gilb.com
Hull, E. et. al: Requirements Engineering. Oxford 2005
IBAQB: Certified Business Analyst, Foundation Level Syllabus, version 2011
IBUQ: Certified Professional for Usability Engineering, Foundation Level Syllabus, version 2011
ISTQB: ISTQB Glossary of Testing Terms 2.2
ISTQB: Certified Tester, Foundation Level Syllabus, version 2011
Jacobson, I.et al.: Object-Oriented Software Engineering. A Use Case Driven Approach. AddisonWesley 1993
Lauesen, S.: Software Requirements: Styles and Techniques. London 2002
Versione v2.1 - 2014
Pagina 94 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Pfleeger, S.L. and J.M. Atlee: Software Engineering: Theory and Practice. Upper Saddle River, New
Jersey, USA, Prentice Hall 2006.
Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK ®
Guide). PMI 2004
Robertson, S.; Robertson, J.: Mastering the Requirements Process, Harlow 1999
Rupp, C.: Requirements-Engineering und Management. Professionelle, Iterative Anforderungsanalyse
in der Praxis. Munich 2007
Sharp H., Finkelstein A. and Galal G.: Stakeholder Identification in the Requirements Engineering
Process, 1999
Sommerville, I.: Requirements Engineering. West Sussex 2004
Sommerville, I.: Software Engineering 8. Harlow 2007
Sommerville, I.; Sawyer, P.: Requirements Engineering: A Good Practice Guide. Chichester 1997
Sommerville, I.; Kotonya, G.: Requirements Engineering: Processes and Techniques. Chichester 1998
Thayer, R. H.; Dorfman, M.: Software Requirements Engineering, 2nd edition. Los Alamitos, CA 1997
Wiegers, K.E.: First Things First: Prioritizing Requirements. Software Development, September 1999
Wiegers, K. E.: Software Requirements. Redmond 2005
Young, R. R.: Effective Requirements Practices. Addison-Wesley 2001
Versione v2.1 - 2014
Pagina 95 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
9 Indice
Analisi degli Impatti; 36; 47
Analisi degli Use Case Point; 53; 70
Analisi dei Function Point; 53; 70
Analisi del Business; 23; 24; 25; 26; 29
Analisi del Rischio; 31; 36; 41
Apprendimento; 5; 6; 8; 9; 10; 11; 23; 27; 36;
53; 59; 63; 81; 89
Assegnazione di priorità; 53
Auto-registrazione; 53; 58; 60
BPMN; 53; 73; 75; 78; 90
Brainstorming; 53; 58; 65
Categorie di Strumenti; 4; 89; 91
Change Control Board; 36; 37; 46; 47
Change Management; 4; 20; 26; 29; 36; 37;
38; 39; 45; 46; 49; 62; 83; 89; 90; 91
Change Request; 31; 36; 37; 43; 46; 47; 71
Cliente; 11; 15; 16; 27; 30; 32; 33; 35; 53; 56;
57; 58; 61; 71; 87
CMMI; 19; 22; 81; 88
Configuration Management; 4; 20; 26; 29; 31;
36; 37; 38; 45; 49; 90; 91
Contratto; 53
Controllo di Qualità; 9; 36; 49
Criteri di Accettazione; 20; 50; 53; 54; 80
Criteri di Qualità; 11
Criticità; 11; 15
Elemento di Configurazione; 36
Elicitazione (Identificazione) dei Requisiti; 53
Fornitore; 6; 16; 27; 33; 56; 57; 58; 87
Garanzia della Qualità; 4; 8; 9; 20; 29; 31; 36;
38; 47; 49; 50; 71
Gestione dei Requisiti; 4; 9; 11; 12; 19; 26; 27;
29; 33; 36; 38; 45; 49; 76; 83; 85; 88; 89; 90;
91
Gestione del Rischio; 4; 20; 26; 36; 39; 40; 41;
42; 49
Grado di obbligatorietà; 11
GUI; 8; 44; 53; 75
Identificazione del Rischio; 36
Identificazione in base a documenti esistenti;
53
IEEE 1233; 17; 21; 94
IEEE 1362; 21; 94
IEEE 610; 13; 21; 45; 94
Versione v2.1 - 2014
IEEE 830; 15; 21; 44; 94
Ingegnere dei Requisiti; 5; 9; 27; 33; 35; 41;
60; 63
Ingegneria dei Requisiti; 3; 4; 5; 6; 7; 8; 9; 11;
12; 13; 17; 19; 20; 21; 22; 23; 24; 25; 26; 27;
28; 29; 30; 31; 32; 33; 34; 36; 37; 39; 40; 45;
47; 49; 50; 51; 52; 53; 57; 62; 65; 68; 79; 81;
82; 83; 84; 85; 86; 87; 88; 89; 90; 91; 92
Intervista; 53; 60
ISO 12207; 22; 94
ISO 15288; 22; 94
ISO 15504; 22; 94
ISO 9000; 21; 94
ISO 9126; 21; 65
ISO/IEC 25000; 21; 65; 66
Livelli di Formalizzazione; 53
Metodo Delphi; 53; 69
Metrica; 36
Mitigazione del Rischio; 36; 41
Modello; 30; 53; 68; 72; 73
Modello Agile; 81
Modello Concettuale; 53
Modello dei Requisiti; 53
Modello di Processo; 81
Modello Incrementale; 81
Modello Iterativo; 81
Modello Sequenziale; 81
Modifica; 36; 47; 48
Obiettivo; 53
Osservazione sul Campo; 53
Piano di Gestione del Rischio; 36
Planning Poker; 53; 69
Priorità; 11; 15; 50
Problema di Business; 11
Prodotto; 4; 11; 13; 30; 36; 41; 68; 71; 81; 82
Product Backlog; 64; 81; 85; 86
Product Owner; 47; 81; 85; 86
Progetto Pilota; 89
Proof of Concept; 89
Prototipizzazione; 53; 89; 91
Questionario; 53; 59
Rational Unified Process; 66; 81; 84
Requisiti Funzionali; 14; 20; 50; 65; 66; 72; 74;
75
Pagina 96 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014
REQB® Certified Professional for
Requirements Engineering
“Livello Foundation”
Requisiti Non Funzionali; 14; 65; 66; 72
Requisito; 4; 10; 11; 16; 18
Requisito di Business/Cliente; 11
Requisito di Processo; 11
Requisito di Prodotto; 11
Requisito di Prodotto/Componente; 11
Requisito di Soluzione/Sistema; 11
Requisito Funzionale; 11
Requisito Non Funzionale; 11
Responsabile dei Requisiti; 27; 33
Review; 36; 94
Rischio; 36; 40; 41
Rischio di Progetto; 36
Riutilizzo; 44; 53; 58; 62
S.M.A.R.T.; 53; 57; 94
SEBOK; 21; 94
Sistema; 8; 11; 21; 22; 33; 40; 67; 68; 71; 74;
76; 77
Soluzione; 4; 11; 13; 17; 33; 39; 40; 47; 50; 51;
53; 54; 67; 68; 71; 72; 76; 77; 78; 79; 80
Specifica dei Requisiti; 4; 17; 18; 21; 30; 31;
50; 53; 54; 55; 71; 72; 76; 78; 80; 88
Specifica della Soluzione; 53; 79
SPICE; 22; 81; 87; 94
Stakeholder; 17; 27; 30; 31; 56; 95
Strumento di Defect Management; 89
Versione v2.1 - 2014
Strumento di Modellazione; 89
Strumento di Project Management; 89
Strumento per l’Identificazione (Elicitazione)
dei Requisiti; 89
Sviluppatore dei Requisiti; 27; 33; 34
Sviluppo dei Requisiti; 4; 9; 11; 12; 19; 20; 27;
29; 30; 38; 55; 56; 76; 83; 85; 88
SWEBOK; 16; 19; 21; 94
SysML; 53; 73; 75; 78
Tracciabilità; 4; 15; 29; 31; 36; 38; 42; 43; 44;
49; 50
Tracciabilità Orizzontale; 36
Tracciabilità Verticale; 36
UML; 53; 54; 72; 73; 74; 75; 78; 79; 90
Use Case; 53; 59; 63; 70; 73; 74; 94
User Story; 53; 77
Validazione; 4; 11; 19; 21; 29; 30; 43; 49; 50;
54; 55; 80
Verifica; 4; 11; 19; 21; 29; 30; 43; 49; 50; 54;
55; 80
Vincolo; 11
Vincolo di Business; 11
Vincolo Tecnico; 11
Vision; 39; 53; 56; 57; 58; 78
Workshop; 53; 59; 64
Pagina 97 di 97
© Requirements Engineering Qualifications Board / Italian – Software Testing Qualification Board
1 Dic 2014