Riassunto: Requirement Engineering Fundamentals

Riassunto per scopo di studio del libro “Requirement Engineering Fundamentals“, che ho letto per cultura personale durante il lockdown di Natale. Già che ci sono, ho pensato di fare la certificazione CPRE Foundation, che da quest’anno è disponibile in due versioni (2.2 e 3). Sebbene il materiale di studio sia per la versione 2.2, ho deciso di fare la versione 3. Per colmare i pochi gap tra le due versioni, mi sono avvalso dell’handbook gratuito.

Introduzione

Il termine requisito è definito come una caratteristica che un sistema deve esibire per soddisfare l’esigenza di uno stakeholder.

Con il termine “Requirement Engineering” si intende il processo tramite il quale i requisiti sono gestiti. Le attività principali sono l’elicitazione (o scoperta) dei requisiti, la documentazione degli stessi, la negoziazione e la loro gestione durante il ciclo di vita del progetto.

Secondo la metodologia di gestione dei progetti utilizzata, il requirement engineering puo’ avvenire ad inizio progetto (nei progetti waterfall) o con continuità (nei progetti agili).

L’importanza del requirement engineering è confermata da diversi studi che mostrano come la sua mancanza sia tra le cause di fallimento dei progetti. In assenza di una gestione dei requisiti, si creano errori di interpretazione o omissioni dovute a assunzioni implicite, spesso dovute a differenza di background o conoscenza che rendono difficoltosa la comunicazione tra gli stakeholder e chi deve creare il sistema.

Il requirement engineer deve fare da mediatore tra gli stakeholder e il team di sviluppo. Per questo deve essere dotato di diverse qualità: skill analitici, empatia, capacità di mediazione, di moderazione, di comunicazione, autostima e doti di persuasione.

I requisiti si possono essere categorizzati in funzionali, definiti come manifestazioni dei comportamenti esterni forniti dalle funzioni di un sistema, e requisiti di qualità o non funzionali, che descrivono le caratteristiche che un sistema deve avere. Da ultimo ci sono i vincoli, ovvero i requisiti non negoziabili.

I requisiti di qualità sono categorizzati in diversi modi. Il modello ISO/IEC 25010:2011 li categorizza in requisiti di performances, sicurezza, availability, facilità d’uso, manutenibilità e interoperabilità. E’ responsabilità del requirement engineer l’elicitazione dei requisiti non funzionali, che, pur essendo legati a quelli funzionali (una certa funzionalità deve avere ad esempio certe performaces), devono essere tenuti da essi separati.

System & context boundaries

Una delle prime attività per il requirement engineer è la definizione del perimetro del sistema, linea immaginaria che separa “ciò che é entro il perimetro” da ciò che non lo è.

Gli elementi dentro al perimetro, sono i processi, persone, sistemi, processi, elementi regolatori che sono in qualche modo oggetto della trasformazione. Non identificare adeguatamente l’ambito conduce inevitabilmente a risultati subottimali, se non catastrofici: pensate ad esempio agli impatti che l’aver trascurato aspetti normativi o operazionali può avere sull’esito di un progetto.

Quanto sta al di fuori del perimetro del sistema, può analogamente avere o non avere un influsso sul sistema stesso. Gli elementi esterni al sistema che lo influenzano costituiscono il system context. Tutto ciò che non ha un influsso sul sistema è per definizione al di fuori del system context.

I confini tra sistema, contesto e tra contesto e fuori contesto non sono scolpiti nella roccia e tipicamente non sono noti ad inizio progetto. E’ compito del requirement engineer identificarli e formalizzarli, tracciandone le variazioni.

Il sistema comunica con il suo contesto attraverso interfacce, termine da non intendersi in senso strettamente tecnico. Un modo di modellizzare le interfacce è costituito dal vederle come sinks, ovvero destinazioni dell’output del sistema, o sources, ovvero sorgenti di input per il sistema. Sistemi esistenti, hardware, processi di business, gruppi di persone, possono essere tutti considerati sinks o sources.

Use case diagrams e data flow diagram possono essere usati per documentare il system context.

Elicitazione dei requisiti

Le principali fonti di requisiti sono gli stakeholder, la documentazione e i sistemi esistenti.

Non tutti gli stakeholder sono noti o ovvii ad inizio di un progetto. L’uso di checklist può contribuire a non dimenticarne. Uno stakeholder dimenticato può comportare la perdita di requisiti importanti. Può essere utile tenere una lista degli stakeholder con le informazioni più importanti: nome, funzione, obiettivi e interesse verso il progetto.

Gli stakeholder devono venire aggiornati e coinvolti in modo da renderli partecipi anzichè vittime passive del progetto. Idealmente, ogni stakeholder deve sottoscrivere un contratto, formale o informale di collaborazione col progetto.

Non tutti i requisiti nascono uguali. Il modello di Kano li categorizza in tre classi, secondo il loro effetto sulla soddisfazione finale. I requisiti definiti dissatisfiers sono quelle qualità o funzioni senza i quali lo stakeholder è scontento del sistema. Il fatto che ci siano é dato per scontato, la loro presenza non è di per se motivo di soddisfazione. Sono in un certo senso conoscenza subconscia.

I satisfiers sono i requirement richiesti al sistema. La loro assenza porta alla non accettazione del sistema. Sono conoscenza conscia.

I delighters sono i requisiti che “fanno la differenza”. lo stakeholder non sa di volerli, ma quando ci sono fanno effetto wow.

La categorizzazione non è statica. Tipicamente i delighters diventano satisfiers e poi dissatisfiers. L’utente “alza l’asticella” dell’aspettativa.

Far saltar fuori i requisiti è compito del requirement engineer, che mette in campo diverse tecniche di elicitazione. Come scegliere la tecnica giusta? I driver principali sono il tipo di requisito (come da kano model), il tempo e budget disponibile, l’esperienza del requirement engineer, il livello di dettaglio necessario e i fattori di rischio.

Le survey techniques sono adeguate a far emergere la conoscenza esplicita. Tra esse abbiamo le interviste, che possono dare ottimi risultati ma sono time consuming. Ci sono inoltre i questionari, che hanno il vantaggio di poter raggiungere un vasto audience in modo economico ma richiedono perizia per essere impostati in modo efficace. Inoltre il feedback sul questionario stesso è lento.

Le creativity techniques sono usate per requisiti innovativi o per delineare una visione di alto livello. Non sono adatte a delineare requisiti di dettaglio. Tra esse abbiamo il brainstorming e il brainstorming paradox (dove si evidenziano autocome indesiderati anziché desiderati). Il cambio di prospettiva, in cui i partecipanti a turno indossano un diverso “cappello”, è particolarmente utile quando ci sono stakeholder particolarmente arroccati sulle loro posizioni. Le tecniche basate su analogia tracciano un parallelo tra il problema oggetto di analisi e un dominio noto ai partecipanti, ad esempio nel mondo naturale. Questo dominio viene usato come fonte di ispirazione per le soluzioni, che sono poi traslate sul dominio iniziale. La tecnica può essere applicata in modo esplicito (i partecipanti conoscono sia il dominio di partenza che quello usato come analogia) che implicito (i partecipanti conoscono solo il dominio usato come analogia).

Le tecniche documentali (document centric) usano principalmente sistemi esistenti o esperienze pregresse. Tra esse abbiamo la system archeology (il libro la chiama così, ma si tratta di reverse engineering) e il perspective based reading, in cui la documentazione viene letta con un focus specifico. Da ultimo abbiamo il riuso… usare documentazione dei requisiti esistenti.

Le tecniche di osservazione possono essere usate quando gli stakeholder non hanno il tempo o non sono in grado di esprimere i requisiti. Il requirement engineer, essendo esterno ai processi osservati, é nella posizione migliore per evidenziare possibilità di miglioramento. Inoltre, l’osservare l’operatività permette al requirement engineer di familiarizzare con il dominio e il suo linguaggio. Tra le tecniche abbiamo l’osservazione sul campo (field observation) e l’apprenticing, in cui il requirement engineer non si limita a guardare i processi, ma deve svolgere un vero e proprio apprendistato.

Altre tecniche a supporto sono il mind mapping, i workshop, le CRC cards, gli use cases e i prototipi.

Documentare i requisiti: regole generali

Le ragioni per documentare i requisiti sono tanto ovvie quanto importanti. I requisiti costituiscono la base per lo sviluppo del sistema, possono avere valore legale, aiutano a districarsi nella complessità di sistemi vasti e devono essere consultabili da tutti.

La documentazione dei requisiti copre i tre aspetti dei requisiti stessi: dati, funzionalità e comportamento atteso.

E’ possibile ricorrere al linguaggio naturale, che ha il vantaggio della versatilità e dell’universalità, ma lo svantaggio dell’ambiguità e della sequenzialità (puo’ essere difficile individuare il contenuto rilevante in un lungo testo in linguaggio naturale). Alternativamente si possono usare modelli concettuali specifici per i vari domini. La soluzione migliore è spesso data da un mix delle due modalità.

La struttura del documento di requisiti deve essere comprensibile per aiutare la lettura. L’uso di standard migliora ulteriormente la fruibilità dei contenuti. In particolare, ci sono 3 standard di largo uso: il RUP, l’ISO/IEC/IEEE 29148:2011 e il V model.

Come minimo, un documento di requisiti deve contenere:

• un’introduzione che spieghi scopo del documento, scopo del sistema, la lista degli stakeholder, definizioni e acronimi, referenze esterne un’overview del documento.
• una overview generale che spieghi l’environment del sistema, una descrizione dell’architettura, le funzionalità principali, l’indicazione degli utilizzatori attesi del sistema, i vincoli e le assunzioni.
• la sezione dei requisiti (ovvio, no?)
• eventuali appendici.

Il documento di requisiti é il punto di partenza per lo sviluppo del sistema. Esso serve per la pianificazione dei work packages e delle milestone, per il disegno del sistema, per l’implementazione, per il testing, per il change management, per le operations e per gli aspetti contrattuali.

Non basta che il documento di requisiti esista, deve anche rispettare alcuni criteri di qualità, in particolare, esso deve essere:

• consistente e non ambiguo: questo richiede che i singoli requirement lo siano e che non ci siano contraddizioni tra i vari requisiti. I singoli requisiti devono essere univocamente identificabili.
• ben strutturato: una struttura chiara e accessibile assicura che un lettore possa selettivamente accedere i contenuti per lui rilevanti.
• modificabile: come insegna l’agile, l’unica certezza é che requisiti cambieranno. Morale: versionate il vostro documento di requisiti e aggiungete un bel change log.
• completo: deve contenere tutti i requisiti e i singoli requisiti devono essere completi.
• tracciabile: deve essere tracciata la correlazione tra il documento di requisiti e altri documenti.

Come detto sopra, un documento di requisiti é di buona qualità solo se i singoli requisiti lo sono. Un requisito é di buona qualità se é stato condiviso con gli stakeholder; non ambiguo, cioè interpretabile in uno e un solo modo; necessario; consistente, ovvero non deve contraddire altri requisiti; verificabile, ovvero deve essere possibile valutare se la soluzione lo soddisfa; fattibile, altrimenti non ha senso per definizione; tracciabile, cioè deve essere possibile risalire alla sua origine e le sue relazioni con altri artefatti (ad esempio i test cases che ne verificano il soddisfacimento); completo, cioè non deve mancare di parti (esempio classico, una condizione in cui non viene specificato il comportamento del sistema nel caso in cui la condizione non sia soddisfatta… un if senza else); comprensibile, altrimenti come si puo’ realizzarlo? La comprensibilità è aumentata usando frasi brevi, usando verbi al modo attivo.

La presenza di un glossario aiuta grandemente la comprensione. Il glossario deve contenere l’indicazione di sinonimi, omonimie, acronimi, abbreviazioni, concetti chiave e termini tecnici. Il glossario deve essere mantenuto e l’uso corretto dei termini deve essere verificato.

Documentare i requisiti usando il linguaggio naturale

Il linguaggio naturale il vantaggio dell’universalità, della versatilità e dell’immediatezza. Ci sono però alcuni effetti psicologici da tenere in considerazione per scrivere requisiti di qualità col linguaggio naturale o quando si parla con i subject matter expert:

• nominalizzazione: è il fenomeno per cui un termine semplice viene usato per descrivere un processo complesso. In questo caso la soluzione consiste nel riconoscere e specificare completamente il processo sottostante.
• sostantivi senza indice di riferimento: termine tecnico dei linguisti che indica il fenomeno per cui si usa un termine troppo generico o il contesto non é specificato a sufficienza. Ad esempio: “mostrare i dati sul display”. Quali dati? su quale display?
• quantificatori universali: sempre, mai, tutti… ma è davvero sempre o ci sono eccezioni?
• condizioni non completamente specificate: gli if senza else.
• Verbi non completamente specificati: i verbi reggono dei complementi. Se i complementi non sono specificati, si crea ambiguità o incompletezza. Ad esempio: “trasferire i dati”. Da dove? a dove?

L’uso di template aiuta la creazione di requisiti di qualità, ma puo’ essere considerato troppo rigido. Esistono template per azioni automatiche, funzioni utente e interazioni con altri sistemi come mostrato nello schema sotto (preso dal libro):

Documentazione basata su modelli

Un modello è una rappresentazione della realtà, ma anche una sua riduzione pragmatica e (semplificazione) finalizzata ad un obiettivo specifico. Ogni modello ha una sua sintassi e una sua semantica.

Ricorrendo ai modelli per la documentazione dei requisiti, si categorizzano i modelli e i requisiti in tre categorie: goals, use cases e requisiti di sistema.

Con goal si intende un obiettivo. I goal possono essere in contrasto tra loro. I diagrammi ad albero and/or sono un modo per specificare i goal.

Gli use cases descrivono scenari d’uso del sistema. L’uml definisce gli use case diagram, che mostrano ad alto livello gli use cases, gli attori coinvolti e le dipendenze tra use cases. Ad ogni use case è poi associata una use case specification, che descrive in dettaglio lo use case stesso.

I modelli per la documentazione dei requisiti di sistema si raggruppano secondo la prospettiva che supportano:

• dati: diagrammi E-R e class diagram UML
• funzionalità: data flow diagrams, activity diagram UML
• comportamento: macchine a stati e state diagrams UML

Le tre prospettive sono collegate, come tre proiezioni su assi diversi di uno stesso solido geometrico.

Validazione e negoziazione dei requisiti

La validazione dei requisiti ha l’obiettivo di valutare la qualità degli stessi. Requisiti errati, incompleti o ambigui portano a errori e costi nella fase successiva di realizzazione.

La negoziazione dei requisiti ha l’obiettivo di risolvere diatribe che possono nascere tra gli stakeholder che hanno espresso requisiti in contrapposizione. Nel ricomporre i conflitti c’é il rischio di scontentare alcuni stakeholder, ma anche la possibilità di trovare soluzioni creative che permettano di avere un risultato migliore.

Tre sono gli aspetti che il processo di validazione deve considerare: contenuto, documentazione e agreement.

Per quanto riguarda il contenuto, occorre verificare che i requisiti di qualità già espressi precedentemente siano rispettati. Inoltre occorre verificare l’assenza di soluzioni premature, che possono mascherare il requisiti vero e proprio.

Per quanto riguarda la documentazione, occorre verificare che le linee guida siano rispettate, che i documenti siano comprensibili, non ambigui. Il mancato rispetto crea problemi in fase realizzativa, aumenta il rischio di malintesi, può portare a incompletezza o a sottovalutare requirement.

Per quanto riguarda l’agreement, occorre verificare che l’accettazione da parte degli stakeholder sia avvenuta in modo corretto, compresa la ri-accettazione dopo eventuali cambiamenti e la risoluzione di eventuali conflitti.

I principi base della validazione dei requisiti sono 6:

Il primo principio dice di coinvolgere gli stakeholder corretti. In generale chi valida i requisiti dovrebbe essere “super partes”: non é quindi una buona idea che la validazione sia fatta da chi scrive i requisiti. Si possono anche usare auditors esterni, con un certo aumento di costi.

Il secondo principio afferma l’opportunità di separare l’identificazione degli errori dalla correzione, in modo che il processo di ricerca degli errori possa essere fatto con concentrazione e le risultanze double checked prima della correzione.

Il terzo principio dice di effettuare la validazione secondo diversi punti di vista, ad esempio da persone con background e competenze diverse, in modo da avere una visione più completa.

Il quarto principio dice di cambiare tipo di documentazione. Ad esempio, si puo’ risolvere l’ambiguità in un testo in linguaggio naturale affiancando ad esso un formalismo basato sui modelli.

Il quinto principio suggerisce la costruzione di artefatti di sviluppo, come prototipi o test cases. In questo modo si capisce subito se i requisiti sono “buoni abbastanza”. Visto il costo di queste attività, può essere pragmatico applicare questo principio ad un campione dei requisiti da validare.

Il sesto ed ultimo principio afferma la necessità di effettuare validazioni ripetute, in quanto la conoscenza del sistema aumenta nel tempo e non é detto che i requisiti restino validi al cambiare delle condizioni.

Esistono diverse tecniche di validazione, basate principalmente sulla review. Tra esse abbiamo (tengo i nomi originali):

Commenting, dove l’autore passa al revisore i documenti perché li commenti.

Inspection, ovvero un processo formale di valutazione degli artefatti. L’inspection é fatto in varie fasi: planning, dove vengono stabiliti gli obiettivi, ruoli e oggetto della revisione; overview, dove l’autore spiega i requirement perché i partecipanti possano avere una base di partenza condivisa; error detection, ovvero la fase di ricerca degli errori, che può essere fatta in team o singolarmente. Gli errori vengono documentati; error collection & consolidation, in cui gli errori sono raccolti, documentati, ripuliti di duplicati e falsi positivi. Vengono inoltre indicate le misure correttive.

Vi sono diversi ruoli durante un’ispezione: l’organizzatore, il moderatore, l’autore, il lettore (quello che fa l’overview), gli ispettori e il segretario (che tiene le minute).

Walk-Through, una versione “leggera” dell’ispezione, meno strutturata ma che prevede almeno la presenza di autore, ispettore, segretario ed eventualmente moderatore. I requisiti oggetto di review devono essere condivisi.

Vi sono alcune tecniche integrative che possono essere usate a prescindere dal tipo di review:

La Perspective-based reading prevede l’analisi della documentazione con un particolare punto di vista o con un particolare obiettivo. Il punto di vista può essere quello dell’utente, di chi deve sviluppare il sistema, del tester, etc… L’obiettivo può essere quello di valutare il contenuto, la conformità della documentazione o la validazione da parte degli stakeholder (agreement). Ciascuna prospettiva dovrebbe avere delle linee guida chiare. Ad esempio si può fornire una serie di domande a chi effettua la validazione.

L’uso di prototipi è la tecnica più efficace per trovare errori nei requisiti, in quanto permette agli stakeholder di verificare quello che hanno in mente rispetto a quanto implementato. I prototipi possono essere “a perdere” o costituire le basi dello sviluppo successivo. Un prototipo per definizione implementa un sottoinsieme dei requisiti, quindi occorre scegliere cosa realizzare.

La validazione tramite prototipi prevede una fase di preparazione, fornendo a chi valida le istruzioni, gli scenari da validare e la checklist di validazione. L’esecuzione della validazione prevede che chi valida possa eseguire gli scenari concordati, ma anche avere un approccio esplorativo. Questo implica che egli sappia quali requisiti sono stati realizzati e quali no.

L’esito della validazione prevede che l’auditor compili le checklist/risultati degli scenari. Inoltre un secondo osservatore può affiancare l’auditor per rilevare eventuali problemi di usabilità, difficoltà di esecuzione o ergonomia.

L’attività di negoziazione dei requisiti prevede innanzi tutto l’identificazione dei conflitti. Una volta identificati, essi devono essere analizzati per stabilirne le cause.

Esistono diversi tipi di conflitti: sui dati (ad esempio, un tempo di risposta ritenuto necessario da uno stakeholder e non fattibile da un altro), conflitti di interessi (ad esempio, stakeholder interessati ai costi vs qualità), differenza sui valori (open source vs proprietary), problemi interpersonali (politics) e problemi strutturali (gerarchia).

La risoluzione dei conflitti deve cercare di tenere tutti contenti, per evitare di avere persone “di traverso”. Perché questo avvenga, tutti gli stakeholder devono essere considerati. Il conflitto può essere risolto con un agreement, con un compromesso, per votazione, definendo diverse varianti o scalando la decisione (ultima risorsa).

Tutte le informazioni devono essere considerate (CAF, consider all facts) e poi si può usare la tecnica “plus-minus-interesting” per categorizzare le ripercussioni di una soluzione o una decision matrix per effettuare il ranking delle soluzioni alternative.

Una volta che un conflitto è stato risolto, è essenziale documentarne la risoluzione onde evitare di doverci tornare su o perché… potrebbe essere necessario doverci ritornare su. In entrambi i casi, la documentazione aiuta a non perdere tempo.

Requirement management

Tra le attività di gestione dei requisiti abbiamo la gestione dei loro attributi. Assegnare attributi ai requisiti aiuta lo loro gestione e fruizione. Seguire uno schema fisso aiuta a tenere ordine. Tipici attributi sono identificativi univoci, autore, stabilità, sorgente, versione, priorità, rischio, etc… La scelta di quali attributi utilizzare é libera, secondo le esigenze di progetto.

Un’altra attività é la creazione di viste sui requisiti. Con vista si intende una qualsiasi rielaborazione dei requisiti che possa servire ad uno stakeholder: selezionare un subset di requisiti, alcuni attributi, statistiche sui requisiti (dette anche condensed views).

La prioritizzazione dei requisiti è un’altra delle attività di gestione. La prioritizzazione può essere fatta secondo criteri diversi. Per prima cosa occorre definire l’obiettivo della prioritizzazione: costo, importanza, durata dell’implementazione, rischio, etc… L’obiettivo influenza infatti gli stakeholder da coinvolgere. Occorre inoltre scegliere un insieme di requisiti che sia omogeneo per grado di dettaglio.

Vi sono diverse tecniche di prioritizzazione, tra le più semplici e usate abbiamo il ranking, ovvero mettere in ordine i requisiti secondo un qualche criterio in linea con il goal e l’uso della top-ten, dove vengono scelti gli n requisiti più importanti (a cui successivamente si può applicare il ranking). Un altro metodo consiste nel classificare i requisiti in mandatory, optional e nice to have, dove le ultime due categorie sono pressoché indistinguibili. Da ultimo, si può usare il criterio di kano di cui abbiamo già parlato in precedenza.

Una tecnica analitica è quella della matrice di Wiegers. Questa tecnica permette un approccio sistematico alla prioritizzazione. In questa tecnica, dopo aver stabilito i pesi relativi per beneficio, perdita, costo e rischio, vengono assegnati i valori ai singoli requisiti, per i quali poi viene calcolato con una media pesata il valore (beneficio e perdita) e la priorità (costo e rischio). Questo approccio richiede tempo, ma da un certo livello di oggettività alla prioritizzazione.

Garantire la tracciabilità dei requisiti è un’altra attività che il requirement engineer deve svolgere nella gestione dei requisiti. La tracciabilità è importante la verificabilità degli stessi, per evitare il gold plating, per l’impact analysis, per il riuso, l’accountability e la maintenance. Poichè il mantenimento e la raccolta delle informazioni di tracciabilità é un processo time consuminig, occorre decire quali informazioni tracciare… e questo dipende dallo scopo del tracciamento.

La tracciabilità si applica a due macro contesti: il contesto pre-requirement specification e post-requirement specification. Il contesto Pre-RS prevede il tracciamento delle relazioni tra requisiti e le loro sorgenti (richieste degli stakeholder, normative, etc..). Il contesto Post-RS prevede il tracciamento delle relazioni tra requisiti e gli artefatti che da essi derivano (test cases, artefatti di sviluppo, etc…). Un’ultima categoria a parte é costituita dal tracciamento delle relazioni tra requisiti.

Le relazioni, indipendentemente dal contesto, possono essere tracciate tramite riferimenti, matrici (difficili da mantenere se il numero di oggetti cresce), grafi.

Il versionamento é un’altra attività essenziale, in quanto il cambiamento nei requisiti é la norma. Solitamente si segue uno schema a 2 cifre (version.increment), dove cambiamento consistenti causano l’avanzamanto di una versione. Un insieme di requisiti con la loro versione specificata é definito requirement configuration, dotato di un suo identificativo. Per definizione una requirement configuration è immutabile: un cambio in un requisito genera una nuova configuration. Una certa configuration, considerata stabile, può essere usata come baseline per stime, comparazioni (change management), pianificazione.

Strettamente legato al concetto di versionamento c’è il change management dei requisiti. Le ragioni di cambiamento sono molteplici, dal semplice errore al cambio di contesto o di normativa, al fallimento del sistema sviluppato. Il cambiamento dei requisiti non é di per se negativo (può indicare interesse attivo degli stakeholder), ma un eccesso é segno di qualcosa che non va nel processo.

Il processo di cambiamento deve essere gestito ed è responsabilità del change control board (CCB), che ha come attività la stima dell’effort, la valutazione dei costi/benefici, valutare il cambiamento di requisiti a seguito della change request, stabilire i criteri di accettazione, prioritizzare e indirizzare le iniziative di cambiamento.

La change request deve contenere un set minimo di informazioni: id univoco, titolo, descrizione, motivo, etc… I change manager (membro del CCB) classifica le change request come correttive, hotfix o adattive. Il processo di gestione può variare. Un processo base “buono per ogni stagione” prevede la valutazione d’impatto, la valutazione da parte del CCB e, a seguito dell’accettazione, la prioritizzazione e assegnazione ad un progetto di realizzazione della change. Il processo di impact analysis, ma anche la decisione del CCB, si avvalgono delle informazioni di tracciabilità.

Da ultimo, il requirement engineer produce diverse metriche relative ai requirement (metriche di prodotto), come ad esempio il numero di errori nei requisiti e al processo di gestione degli stessi (metriche di processo), come ad esempio il numero di change request.

Tool a supporto

Le attività di requirement engineering possono essere agevolate dall’uso di strumenti adeguati. Al di la dei tool generici di condivisione della conoscenza (wiki et similia), di modellizzazione e di produttività personale, la parte del leone la fanno i tool di requirement management (RM nel seguito).

I tool di requirement management hanno di solito le seguenti caratteristiche:

• permettono l’aggiunta di attributi ai requisiti e la loro organizzazione.
• permettono di gestire il versionamento e le baseline
• abilitano la produzione della reportistica
• consentono la tracciabilità delle dipendenze

Alternativamente, si possono usare i normali prodotti di office automation, con tutti i limiti del caso.

L’introduzione di un tool di requirement management ha come prerequisito la formalizzazione dei processi e metodologie di requirement management. Del resto, il tool deve supportare i processi, non viceversa.

Introdurre un nuovo tool ha un costo in termini di risorse per un’organizzazione. Conviene introdurre il tool con un progetto pilota per evitare impatti su progetti già avviati.

La scelta del prodotto giusto può essere lunga e tediosa, vista la pletora di prodotti disponibili. Nel valutare un prodotto, occorre considerare punti di vista differenti: supporto al progetto (planning, execution, etc…), utenti (role mapping, collaborazione, etc..), funzionalità, supporto al processo, posizione del fornitore (è solido? ha una buona fetta di mercato? ), caratteristiche tecniche (richiede l’uso di piattaforma che sappiamo gestire?), costi (licenze, integrazione, supporto, etc…).

Extra material: CPR3 3.0 Handbook

Le differenze fondamentali tra la versione 2.2 e 3 sono ben spiegate nel sillabo, da cui ho estratto lo schema che segue:

In questa sezione riporterò quelle che sono le principali aggiunte che l’handbook apporta al manuale base. In breve, hanno integrato meglio i concetti agili (il libro é moooolto waterfall style) e reso in modo più elegante alcuni concetti (work package, principi).

I principi del requirement engineering sono 9:

1. value orientation: i requisiti non sono un fine, ma un mezzo. C’é valore se il costo è inferiore al beneficio. Spesso i costi sono immediati, mentre i benefici si vedono nel tempo (minor difettosità, minor rework). Occorre tenerlo in considerazione.
2. stakeholder satisfaction: l’obiettivo di un sistema è soddisfare gli stakeholder. Se questi non esistono fisicamente, come nel caso di sistemi per il pubblico, si possono usare le personas. Gli stakeholder devono essere categorizzati e i conflitti nei loro requirement risolti.
3. shared understanding: le persone coinvolte in un progetto devono avere una visione comune. Lo shared understanding può essere esplicito, formalizzato nei requirement, oppure implicito, dovuto al fatto che le persone in un progetto condividono la visione del problema e della soluzione. In entrambi i casi, per essere ragionevolmente certi che una visione comune sussista, si possono usare tecniche come prototipi, glossari e soppratutto l’uso di un processo con feedback loop brevi. Ci sono diversi fattori che agevolano o ostacolano lo shared understanding: più sono gli ostacoli, meglio é ricorrere alla formalizzazione dei requirement.
4. context: vedi capitolo due del manuale base
5. problem, requirement, solution: questi tre elementi costituiscono una triade interconnessa. Non ha senso parlare di requisiti in assenza di un problema da risolvere. La soluzione non può prescindere dai requisiti. Compito del requirement engineer di tenere per quanto possibile lo spazio del problema e quello della soluzione separati.
6. validation: requisiti non validati sono inutili. La validazione deve partire prima possibile, per evitare di realizzare il sistema errato.
7. evolution: i requisiti cambieranno. Per mille ragioni.
8. innovation: questo è uno dei punti che nel manuale version 2.2 non c’era. Un buon requirement engineer non deve limitarsi a riportare le richieste degli stakeholder, ma contribuire a trovare soluzioni innovative e migliori.
9. systematic and disciplined work: scegliere il metodo giusto per il contesto giusto, ma in tutti i casi avere un approccio disciplinato e preciso.

Un altro concetto che viene aggiunto in modo più esplicito in questa versione é quello di work product: fondamentalmente quello che in altri contesti si chiama artefatto. I work product hanno una durata (lifespan), uno scopo, delle dimensioni, una rappresentazione e sono memorizzati da qualche parte. In particolare con riferimento al lifespan, possono essere temporanei, in evoluzione o durevoli.

Le tecniche di elicitazione sono categorizzate secondo una nuova tassonomia e divise in de macro categorie: gathering e design & idea generation. Ne vengono anche aggiunte alcune, come ad esempio scenarios & storyboards e crowd-based requirement engineering.

Tra le tecniche di validazione vengono aggiunti alcuni riferimenti ad alpha, beta e a/b testing (non sto a spiegare qui cosa sono).

Il contributo più originale rispetto al libro é dato dal capitolo che parla di processi e working structure. Il processo di requirement engineering deve essere scelto in base a vari criteri, tra cui la compatibilità col processo complessivo di costruzione del sistema, con il contesto di sviluppo (relazioni con i supplier e utenti e tipo di processo di sviluppo) e fiducia complessiva; la disponibilità degli stakeholder (non ha senso proporre un processo iterativo se hai gli stakeholder a disposizione solo all’inizio); il già citato shared understanding; la complessità del sistema; eventuali vincoli; il tasso di cambiamento e l’esperienza del requirement engineer.

Pur considerando i fattori citati sopra, non ha senso partire da zero ogni volta per selezionare il processo di requirement engineering. Possiamo partire da soluzioni preconfigurate considerando tre aspetti (facets). I tre aspetti sono

Tempo: possiamo avere un processo lineare, in cui tutto é specificato upfront e pochi cambiamenti sono previsti. Può essere utile/necessario quando i requisiti sono stabili e chiari (quando mai…) o per motivi normativo/contrattuali. Alternativamente possiamo avere un processo iterativo, in cui i requisiti sono specificati un po’ per volta, quando la durata è sufficiente per avere diverse iterazioni e il contesto lo permette.

Scopo: ad un estremo di questo asse abbiamo i processi prescrittivi, in cui il requisito costituisce un’obbligazione legale. Sono opportuni per contratti a costo fisso e per fare outsourcing. Per contro nei processi esplorativi solo gli obiettivi sono noti a priori. Sono utili quando gli stakeholder hanno solo una vaga idea di cosa vogliono, ma hanno disponibilità per un coinvolgimento continuo. Ovviamente anche i contratti devono essere calati su questa realtà di incertezza.

Target: ad un estremo dello spettro abbiamo sviluppo di sistemi per un customer specifico (ad esempio, software per il call center), all’altro sistemi per il mercato, quindi per utenti esterni all’organizzazione.

Le tre facet non sono scorrelate, come é facile intuire. L’approccio lineare si sposa bene con uno prescrittivo, meno con un approccio market oriented (visto che il feedback finale é quello del mercato, l’approccio lineare è troppo lento); quello esplorativo va a braccetto con quello iterativo.

La scelta del processo deve considerare il livello di rischio e l’esistenza di uno shared understanding.

Tipiche configurazioni di queste tre facet sono:

Processo partecipativo: iterativo-esplorativo-customer specific. Fornitore e richiedente devono collaborare strettamente, i tipici work product sono quelli dei processi agili (backlog, vision, prototipi).

Processo contrattuale: lineare-prescrittivo-customer specific. Le specifiche costituiscono la base contrattuale di collaborazione tra fornitore e richiedente e l’interazione successiva alla fase di specifica sarà minima. I tipici work product sono documenti di requisiti tradizionali.

Processo product-oriented: iterativo-esplorativo-market oriented. L’organizzazione produce sistemi o servizi per il mercato. I tipici work product sono quelli dei processi agili.

Per scegliere il processo giusto si suggerisce un processo in 5 passi: analizzare i fattori di influenza, valutare i tre facet, scegliere il processo, determinare i work product, selezionare le pratiche appropriate