Dal “vai” al “wow”
Christopher vuole comprare un vestito nuovo da indossare al matrimonio della figlia. Vuole un abito blu scuro con un gilet, e lo vuole per sembrare il più elegante possibile. Per raggiungere questo obiettivo, vuole l’abito fatto appositamente per lui. Va in un negozio di abbigliamento maschile in Jermyn Street a Londra e spiega a Jerome, il commesso, quello che vuole. In questa fase, i requisiti di Christopher sono abbastanza confusi: potrebbe sapere (o potrebbe pensare di sapere) quello che vuole, ma finora lo ha espresso in un modo che non è sufficientemente preciso per ottenere il risultato desiderato.
Jerome pone molte domande a Christopher e gli mostra immagini e campioni per aiutarlo a concentrarsi sui dettagli. Vuole doppio petto o singolo? Farà caldo? Il matrimonio di sua figlia è all’aperto oppure all’interno con aria condizionata? Sarà un matrimonio di giorno o di pomeriggio? Quale di queste tonalità di blu le piacciono di più? Qual è il suo budget? Che cosa indosserà sua moglie? Qual è la data del matrimonio? Quale di questi stili di pantaloni preferisce?
Jerome scrive le risposte alle sue domande e butta giù uno schizzo ogni volta che pensa che potrebbe aiutare a chiarire le idee a Christopher. Quando Jerome ritiene di avere un abbozzo ragionevole del progetto sartoriale, chiama il sarto Rupert.
Jerome ha fatto un’interpretazione comprensibile dei requisiti di Christopher. Adesso, Rupert esamina i requisiti e usa la sua esperienza per proporre progetti di abiti che rispondono ai requisiti di Christopher e rispettano i vincoli. Jerome discute le raccomandazioni del sarto con Christopher e lo aiuta a fare una scelta definitiva di materiale e stile, oltre ad assicurarsi che le misure di Christopher siano state prese con precisione. Quando inizia la produzione, il sarto Rupert assegna i compiti (tagliare il tessuto, tagliare la fodera, realizzare le maniche, i pantaloni, e così via) all’equipe di sartoria; e così il vestito nasce poco a poco. L’esito migliore è che il vestito sia perfetto per Christopher, e che questi sia soddisfatto del disegno, del tessuto e del rapporto qualità-prezzo.
Una catena alimentare semplice
I requisiti hanno viaggiato lungo tutto il percorso di questa storiella del vestito per la cerimonia nuziale. Il punto di partenza è stato quando Christopher ha deciso di avere bisogno di qualcosa di nuovo da indossare al matrimonio della figlia. Le caratteristiche sono diventate più precise con le domande di Jerome, che hanno anche fissato alcuni dettagli, e sono risultate ancora più precise quando il sarto Rupert ha fornito le scelte specifiche; e, infine, si è raggiunta la massima precisione dei requisiti, quando Rupert ha fornito i dettagli delle singole specifiche per ogni pezzo del vestito. In alcuni punti lungo il processo di produzione, nuovi particolari sono stati prodotti.
Nella catena lineare, un requisito viaggia dalla sua origine alla sua soluzione finale. Mentre si avanza nel processo, vengono aggiunti dettagli ed effettuate nuove modifiche.
Originatori e consumatori
La catena alimentare dei requisiti, popolata dagli “originatori” e dai “consumatori”, è un modo di mappare gli interessi e le responsabilità dei diversi stakeholder nel percorso di maturazione dei requisiti. Un requisito non è una semplice frase, ma un composto di attributi diversi, e ciascuno di essi è rilevante per persone diverse per differenti ragioni. Per esempio, uno degli attributi di un requisito singolo è il suo fondamento logico, che descrive il perché tale requisito è importante. Supponiamo che, nella propria organizzazione, sia responsabilità dei business analyst garantire che il fondamento logico venga registrato. Quindi, possiamo dire che i business analyst sono gli “originatori” del fondamento logico. Proseguendo lungo la catena alimentare dei requisiti, gli sviluppatori utilizzano il fondamento logico come input per le loro decisioni di progettazione, e i tester utilizzano il fondamento logico come guida nella progettazione di test e nel decidere quanta importanza assegnare alle prove. In altre parole, gli sviluppatori e i tester sono “consumatori” di fondamento logico, ognuno per un motivo diverso.
Un consumatore di un attributo potrebbe anche essere un originatore di altri attributi. Gli stakeholder di business potrebbero originare la dichiarazione di intenti “il prodotto è…”, che a sua volta è consumato dai business analyst che poi originano il fondamento logico. Entrambi questi originatori potrebbero quindi leggere (cioè consumare) questi attributi e originare il criterio di misurazione, cioè la misura del requisito per renderlo verificabile. Naturalmente anche il tester diventerà un consumatore del criterio di misurazione.
È importante che i consumatori rispettino gli attributi che altri hanno originato. Non devono falsare o alterare oppure omettere alcun attributo nell’aggiungere elementi o nel perfezionare il requisito. Il requisito deve rimanere intatto semanticamente nel suo percorso lungo la catena alimentare.
Una catena alimentare più realistica
Ma la catena alimentare non è esattamente lineare come precedentemente descritto: una vista più realistica di come un requisito matura prevede il percorso completo dal suo stato embrionale alla sua soluzione, comprendente i cicli di feedback e le modifiche e integrazioni al requisito fatte da vari originatori, mentre si sposta lungo la catena alimentare.
Tutti nella catena alimentare si concentrano sulle proprie ragioni connesse al proprio ruolo per essere interessati al requisito. Questo significa che a volte ci sarà conflitto tra le aspirazioni delle diverse parti interessate, portando a revisioni e iterazioni, invece di una progressione costante per il risultato finale. Ma la natura dei requisiti è proprio questa, e punta alla necessità di collaborazione tra le parti, e a come il requisito sia il veicolo per mettere insieme punti di vista diversi. Proprio come gli esseri umani fanno tesoro di nuove esperienze e influenze che li cambiano e li modificano nel percorso dall’infanzia alla maturità, il requisito passa attraverso varie fasi formative prima che sia pronto a realizzare la soluzione ottimale definitiva.
Il ruolo dei business analyst
In un modo o nell’altro, ogni progetto ha bisogno di una maniera per evitare l’inquinamento della catena alimentare dei requisiti da interessi figli dell’ostinazione. Ciò significa che qualcuno deve essere responsabile per la tracciabilità dei requisiti dallo stadio embrionale a quello di soluzione. Questo è uno dei motivi per impiegare i business analyst.
Chiaramente, un business analyst non può avere tutte le competenze relative ai ruoli specializzati presenti lungo la catena dei requisiti. Invece, il business analyst è la persona che riconosce ogni specializzazione e garantisce che l’intenzione del requisito sia accuratamente comunicata a ciascuno di esse lungo la catena. Le organizzazioni sono in crescita in termini di dimensioni e complessità geografica, anche in base alle combinazioni tecnologiche in continuo cambiamento. La risultante complessità delle comunicazioni significa che il business analyst deve avere un mix di capacità tecnologiche e sociologiche.
Ecco perché pensiamo al business analyst come a qualcuno che guida i requisiti nel loro movimento lungo la catena alimentare. È il business analyst che, in virtù della sua posizione distaccata, è il più indicato per garantire che il vero significato del requisito sia espresso e conservato grazie al contributo dei partecipanti alla catena alimentare. E in definitiva, è il business analyst a essere responsabile per avere portato il processo a completa maturità. Allora, e solo allora, gli sviluppatori possono realizzare esattamente il prodotto di cui il business ha bisogno.
James Robertson
Consulente, insegnante, autore e project leader. La sua opera nel campo della Business Analysis e della raccolta dei requisiti è apprezzato da molti clienti in molte parti del mondo. È co-autore di “Mastering the Requirements Process”, “Requirements-Led Project Management” e dell’approccio Volere per l’engineering dei requisiti. È anche fondatore dell’Atlantic Systems Guild, un think thank conosciuto in tutto il mondo per le sue tecniche innovative di systems engineering.
Suzanne Robertson
Indiscussa autorità nel mondo della system analysis e requirements modeling, è principal dell’Atlantic Systems Guild. Insieme a James Robertson è co-autore di “Complete Systems Analysis: the Workbook, the Textbook, the Answers” e di “Mastering the Requirements Process”. Ha fatto parte del comitato per Object Technology 97 ed è roving ambassador per il Reuse Group della British Computer Society.
Suzanne Robertson presenterà a Roma per Technology Transfer il seminario “Mastering the Requirements Process” il 13-15 aprile 2015 e James Robertson terrà sempre a Roma il seminario “Mastering Business Analysis” il 16-17 aprile 2015.
