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
© Copyright 2025 ExpyDoc
