Quando uno stakeholder di business dice “Voglio [qualcosa]”, potrebbe trattarsi di una esigenza reale e quantificabile che è rilevante per il business. Ma in molti casi non è così. Le persone chiedono frammenti di funzionalità che riguardano solo la propria parte del lavoro, oppure chiedono di perpetuare il modo in cui le cose vengono già eseguite ora. Oppure ancora, chiedono una soluzione, ma non comprendono fino in fondo (o non conoscono) l’esigenza. E a volte tralasciano di menzionare qualche dettaglio, pensando che tutti conoscano già quello che loro stessi sanno. Questi desideri mal indicati, che chiameremo magma, devono essere compresi, tradotti in reali esigenze, e trasmessi a sviluppatori, solutions architect, business architect e fornitori, che sono tutte figure alle quali serve la concretezza del cemento, ovvero requisiti precisi e pertinenti.

Le esigenze di un business provengono da molte fonti. Alcuni nascono dalla consapevolezza degli stakeholder che c’è bisogno di un miglioramento per aiutare a svolgere il loro lavoro. Ma potrebbero esserci anche esigenze inconsce: “Non ha mai funzionato prima, quindi non ha senso chiederlo, e dobbiamo solo continuare a lavorarci intorno”. Un’altra serie di esigenze sono quelle che gli stakeholder non avrebbero nemmeno sognato, perché non sanno che una tecnologia esiste ed è diventata disponibile e accessibile. Per esempio, gli stakeholder di un’impresa ferroviaria non hanno pensato che i macchinisti potessero avere una programmazione on-demand dei turni perché ritenevano che la tecnologia fosse troppo costosa. Ma quando le esigenze dei macchinisti sono state comprese a fondo, è emerso che usare alcuni tablet insieme a software commerciale, off-the-shelf, può costituire una soluzione efficace per comunicare le programmazioni ai macchinisti.

Migliorare gli hard skill – Ci sono tecniche consolidate, gli hard skill, per definire la portata, il processo di modellazione, i dati e le dinamiche, e per la scrittura di requisiti e regole di business. Queste tecniche confezionano le conoscenze in una forma comprensibile. La maggior parte di queste tecniche comportano la costruzione di un modello. Ovviamente, si userà una notazione con cui si abbia dimestichezza e che sia conosciuta e compresa dai colleghi.

Tuttavia, invece di utilizzare gli stessi hard skill ogni volta, vale la pena di pensare in modo diverso e di sperimentare alternative per enunciare un problema o una sua soluzione. Tra i modi suggeriti per venire a conoscenza di altre tecniche vi sono:

• Leggere un libro su una tecnica che non si è mai utilizzato prima e provare una delle idee nel lavoro di tutti i giorni.
• Entrare in un ordine professionale, come l’International Institute of Business Analysis, il BCS o l’IEEE.
• Identificare uno degli hard skill di cui già si dispone e destinare una mezz’ora a esplorarlo ulteriormente sul web. Per esempio, si possono concentrare le ricerche web ponendosi domande del tipo: “Come faccio a definire le regole di business?”. Risulterà sorprendente vedere quante nuove idee si possono trovare.
• Considerare come state realizzando un risultato e chiedetevi: “Tutto questo porta davvero vantaggi? Ho davvero bisogno di fare questo, o sto semplicemente seguendo le abitudini?”
• Cercare blog interessanti e confrontarsi con i colleghi sulle tecniche che ritengono utili.
• Partecipare a una conferenza sulla business analysis una volta o due all’anno.

Questi modi di migliorare gli hard skill suggeriscono di guardare verso l’esterno, e di trovare nuove idee in nuovi posti, che significa tutto fuorché far cose perché è così che si è sempre fatto.

Migliorare i soft skill – Le persone che si dedicano al pensiero analitico, come i responsabili di prodotto, i business analyst, i systems architect e così via, hanno di solito un certo addestramento (la cui quantità e profondità varia enormemente) e una consapevolezza delle proprie competenze di tipo hard. Ma lo stesso non vale per le loro competenze trasversali, quelle di tipo soft.

Se si chiede alle persone di cosa hanno bisogno, le risposte che si ottengono variano molto in base a sensibilità, atteggiamento, umore, personalità ed esperienza delle diverse persone. Non si può premere un pulsante e avere tutti che si comportano nel modo in cui vogliamo. Invece di un pulsante, abbiamo soft skill che possono renderci consapevoli delle differenze tra le persone, e aiutarci a delineare la strategia di comunicazione più appropriata per ciascuno.

Ecco qualche spunto per migliorare i soft skill – 1) Quanto siete bravi ad ascoltare? Conoscete la differenza tra sentire, che è tutto ciò che entra nelle orecchie, e ascoltare, cioè determinare il significato di ciò che si sente osservandolo dal punto di vista della persona che lo dice? Per ulteriori informazioni su come ascoltare in modo efficace, ci si può riferire a due saggi di Nancy Kline: “Time to think” e “More time to think”.

Quando si pensa di aver capito ciò che viene detto, sarebbe consigliabile provare a dare un feedback a quello che abbiamo capito. Ed essere pronti ad accorgersi di avere sbagliato. Una delle forme più efficaci di feedback è uno schizzo informale per mostrare le parole e le idee enunciate dal soggetto. Questo feedback collega più strettamente al soggetto e ha maggiori probabilità di suscitare ancora più informazioni, quando si dimostri che si sta assorbendo e capendo ciò che stanno dicendo. Per ulteriori informazioni sull’utilizzo degli schizzi per aiutare la comunicazione, si consigliano due libri di Dan Roam: “Back of the napkin” e “Blah blah blah”, oltre ai suoi video su come utilizzare gli schizzi per comunicare le idee e la comprensione.

A volte è difficile avere un feedback: o qualcuno è d’accordo con tutto quello che dici, oppure non viene detto nulla. A volte il loro linguaggio del corpo indica che forse desidererebbero che ve ne andaste via. In questi casi, c’è una ragione per la mancanza di connessione. Forse, questa persona non ha le conoscenze necessarie per rispondere alle vostre domande. È il caso che parli con qualcun altro? Forse, si tratta di una persona che ha bisogno di riflessione interna prima di rispondere a una domanda. A volte, è difficile non far parlare un pensatore esterno, perché in genere ha bisogno di parlare prima di poter formulare una risposta. O forse, la persona non vede l’importanza delle domande che state ponendo. Forse, la persona teme che stiate per modificare o eliminare il suo lavoro, oppure ha qualche ragione politica per non comunicare con voi. Un libro consigliato per saperne di più sui possibili fattori che bloccano la comunicazione è “People Skills” di Robert Bolton. Un’ultima idea è quella di leggere le biografie di personaggi famosi o le opere di narrativa. Poi immaginare i personaggi come se fossero qualcuno che si sta intervistando. Come intervistereste Hermione Granger nei libri Harry Potter? Quale approccio useremmo intervistando Winston Churchill o George Washington? Sarebbe diverso se l’intervistato è Beethoven? L’idea è quella di essere consapevoli del fatto che le persone con cui si comunica sono diverse, e per ognuno c’è bisogno di una diversa miscela di soft skill per stabilire una comunicazione efficace.

Prendere da altre discipline – Non è necessario ripartire da zero: si può imparare molto di più sui soft skill esplorando altre professioni. Ci sono altre discipline che vale la pena di esplorare per ricavare idee su come migliorare i soft skill. La terapia familiare si concentra su come i gruppi familiari funzionano o non funzionano, e molte delle idee sono applicabili per aiutare un gruppo di stakeholder a lavorare insieme. La psicologia e la sociologia sono ricche di idee per migliorare la capacità di comunicare e di aiutare gli altri a fare collegamenti. Queste discipline si occupano di altri argomenti, ma sono ugualmente applicabili alla business analysis. Prendere in prestito da altre discipline migliora anche gli hard skill: se ci si imbatte in un diagramma architettonico, o in un sondaggio di marketing con una struttura innovativa, perché non adattare l’idea? Essere alla ricerca di nuove competenze, spesso in luoghi improbabili, migliorerà la vostra capacità di trasformare vaghe idee magmatiche in esigenze di business più concrete del cemento.

James & Suzanne Robertson

Hanno aiutato centinaia di aziende a migliorare le tecniche dei requisiti e a rendere lo sviluppo dei sistemi molto più efficace e pertinente. I loro corsi e seminari negli ambiti dei requisiti, della business analysis e della progettazione sono ampiamente apprezzati per l’approccio innovativo. Membri di primo piano dell’Atlantic Systems Guild, molto nota nell’ambito della consulenza sulle dimensioni umane della costruzione di sistemi complessi, James & Suzanne Robertson sono coautori di “Mastering the Requirements Process – edition 3”, “Getting Requirements Right” e dell’approccio Volere alle tecniche dei requisiti.

Suzanne Robertson presenterà a Roma per Technology Transfer il seminario “Mastering the Requirements Process” il 16-18 ottobre 2017, e James Robertson terrà, sempre a Roma, il seminario “Mastering Business Analysis” il 19-20 ottobre 2017.

L'articolo Tra desideri e necessità. La business analysis, dal magma al cemento proviene da Data Manager Online.

Se si parla di requisiti ai business stakeholder, cioè alle parti interessate nel business, si rischia di sentire affermazioni come: «Vorrei un altro schermo che mi mostri i totali di produzione giornalieri. Vorrei che Excel mi visualizzi le vendite per il trimestre precedente. Vorrei sapere quanti dipendenti nuovi si aggiungono ogni mese». Oppure, si sentono racconti come questo: «In qualità di direttore di produzione, vorrei uno schermo che mostri la produzione di ogni fabbrica in modo da vedere la produttività di tutti i nostri stabilimenti». In ciascuno di questi esempi, lo stakeholder sta esprimendo la soluzione da lui percepita per una qualche necessità inespressa. Ma non sappiamo perché lo stakeholder vuole i totali di produzione giornalieri, dato che non ha spiegato cosa farà con i dati di vendita. Solo quando si conosce il motivo per cui qualcuno sta chiedendo qualcosa, allora si è in grado di fornire un valore. Cioè, è possibile fornire una soluzione che corrisponda alla reale esigenza di business, anche se la vera necessità è ancora inespressa. In questo senso, qualsiasi soluzione che non soddisfa un bisogno reale è uno spreco di risorse.

#RequirementsProcess Che cosa significa valore? @techtran
Click To Tweet

Ascoltare le richieste

Bisogna quindi prendere in considerazione il motivo per cui vengono chieste soluzioni, e cosa si può fare per arrivare alla reale esigenza. In primo luogo, è abbastanza naturale per un essere umano chiedere una soluzione che sia vicina alla propria realtà tangibile. Se si sta progettando un viaggio si è più propensi a dire: «Prendiamo l’autobus delle 9.30» – invece di dire – «Voglio spostarmi da casa al lavoro con mezzi di trasporto che mi portino in tempo al meeting delle 10.15». Qui il punto è che si parla in termini tangibili invece che per astrazioni. Uno skill chiave di business analysis è quello di ascoltare le richieste degli stakeholder, e poi applicare il pensiero analitico e sistemico per scoprire la reale esigenza. E questo scopo si raggiunge soprattutto chiedendosi perché: «Perché avete bisogno dei totali di produzione giornalieri? Per confrontare le unità prodotte con quelle vendute? E poi cosa ne farete? Per regolare il ciclo produttivo della prossima settimana in modo da coprire le previsioni di vendita»?

Il risultato di questa conversazione è che l’analista comincia a comprendere la reale esigenza di business: «In qualità di responsabile di produzione, posso confrontare le unità prodotte ogni giorno con quelle vendute, in modo da sapere come regolare il ciclo produttivo per la prossima settimana e assicurare che siamo in grado di soddisfare tutti gli ordini dei nostri clienti». Va anche notato che adesso vengono usati termini come “posso” invece di “voglio”, dove “posso” indica un bisogno, mentre “voglio” suggerisce una soluzione.

#TechnologyTransfer Suzanne Robertson sarà a Roma 17-19 ott per @techtran
Click To Tweet

Fornire valore di business

Applicando il pensiero analitico e sistemico, il business analyst scopre cosa può fornire valore al business. Anche se può sembrare strano, spesso gli stakeholder non chiedono direttamente valore di business, e lo fanno per molteplici ragioni. Gli stakeholder pensano in termini di come le cose vengono fatte ora. Non sanno cosa è possibile. La mentalità a silos mette pareti intorno al loro modo di pensare, rendendo difficile vedere il quadro più ampio. Pensano in termini di come fare qualcosa, invece che di quello che deve essere fatto. Il loro pensiero è centrato su se stessi, invece che sul business complessivo. In considerazione di tutto questo, l’analista di business può (e deve) chiedere perché la richiesta è stata fatta: comprendendone la ragione, il business analyst è in grado di fornire una soluzione che produce reale valore di business. Ma l’analista ha anche bisogno di esplorare altre possibilità di miglioramento del business. Per esempio, dovrebbe suggerire idee innovative per migliorare la policy di business esistente: anche se il business analyst non la determina, può però fare raccomandazioni in modo che gli stakeholder di business siano in grado di scegliere le innovazioni che forniranno il massimo valore.

L’analista deve quindi chiedere agli stakeholder: «Quanto sarebbe utile essere in grado di fornire una soluzione che offre un ciclo di produzione giornaliero rettificato al fine di evitare ordini inevasi? Quanti ordini sono inevasi in questo momento? Quanto ci costano questi ordini inevasi? Ci sono altri fattori che causano ordini inevasi? Potrebbe essere utile correlare il programma di produzione con le consegne dei materiali da parte dei fornitori»? Queste domande indicano che l’analista di business sta usando il pensiero sistemico per trovare le reali esigenze, guardando all’intera attività e all’effetto di ciascuna parte sulle altre. È solo trovando la reale esigenza che la soluzione ottimale può essere realizzata. La soluzione ottimale è quella che corrisponde alle reali esigenze e fornisce il massimo valore di business per il suo costo.

La scoperta dei bisogni reali è responsabilità dei business analyst, ma la scelta della soluzione ottimale è di solito responsabilità degli stakeholder: operando insieme, entrambi possono garantire che stanno fornendo il massimo valore di business.

#TechnologyTransfer James Robertson sarà a Roma 20-21 ott 2016 per @techtran
Click To Tweet

James Robertson

Consulente, insegnante, autore e project leader. La sua opera nel campo della Business Analysis e della raccolta dei requisiti è apprezzata 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

Principal dell’Atlantic Systems Guild. Indiscussa autorità nel mondo della system analysis e requirements modeling. È co-autrice con James Robertson di “Complete Systems Analysis: the Workbook, the Textbook, the Answers” e di “Mastering the Requirements Process”. È roving ambassador per il Reuse Group della British Computer Society e ha fatto parte del comitato per Object Technology 97.

Suzanne Robertson presenterà a Roma per Technology Transfer il seminario “Mastering the Requirements Process” il 17-19 ottobre 2016 e James Robertson terrà sempre a Roma il seminario “Mastering Business Analysis” il 20-21 ottobre 2016.

L'articolo Che cosa significa “valore” per un business analyst? proviene da Data Manager Online.

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.

L'articolo La catena alimentare dei requisiti proviene da Data Manager Online.

by Suzanne Robertson e James Robertson

Se si lavora nello sviluppo di sistemi, soprattutto se si sta sviluppando software, è improbabile che si abbia mai avuto l’idea di essere “agile”. Quello che forse non si sa è da dove derivi il termine: il Manifesto dell’agilità (cioè un insieme di principi) è il risultato di una collaborazione, iniziata nel 2001, tra un gruppo di specialisti di system engineering che si rese conto che le metodologie di sviluppo software e la documentazione avevano l’effetto di rallentare lo sviluppo. In realtà, molti aspetti del modo in cui si stava sviluppando software impedivano di realizzare lo scopo dei veri lavori, che è quello di fornire software prezioso che aiuta i clienti a fare il loro lavoro.

Fin dalla nascita del Manifesto, molti sviluppatori di sistemi, operanti in tutto il mondo, si sono impegnati ad applicare i principi dell’agilità al modo in cui realizzano sistemi. Più di recente, i business analyst e gli specialisti di requisiti hanno preso in considerazione come i principi dell’agilità possono essere applicati quando di scoprono e si comunicano i requisiti di business.

Gli utenti delle tecniche per i requisiti Volere spesso discutono di come le tecniche possono aiutarli a essere più agili. In altre parole, come possono le tecniche migliorare la capacità di fornire applicazioni utili e pertinenti più rapidamente nel loro ambiente? Nel corso di una recente discussione su questo argomento sul gruppo LinkedIn Volere, John Palmer ha suggerito che sarebbe stato utile tracciare un parallelo tra i principi dell’agilità e come le tecniche Volere affrontano ognuno di tali principi. Questo articolo si occupa esattamente di questo.

Affrontare i Principi dell’Agilità – Di seguito, vengono elencati (in corsivo) i Principi dell’agilità, seguiti dal modo in cui le tecniche Volere affrontano tale principio.

La nostra massima priorità è soddisfare il cliente attraverso la fornitura tempestiva e continua di software di valore. Volere è basato su principi ben consolidati di system engineering.

Il modello di conoscenza e il template forniscono una struttura linguistica per definire e collegare le proprie conoscenze dei requisiti in un certo numero di livelli. Questa modalità massimizza la libertà di lavorare in qualunque ordine o a qualsiasi livello di requisiti di dettaglio che faciliterà la più tempestiva realizzazione di software.

Benvenuti requisiti in trasformazione, anche nelle fasi avanzate di sviluppo. I processi agili sfruttano il cambiamento per il vantaggio competitivo del cliente.

Non si può aver a che fare con i requisiti in cambiamento se non si sa da cosa si sta modificando. Le tecniche Volere forniscono modi rapidi e trasmissibili per tenere traccia di ciò che si sa e mettono in grado di riconoscere e integrare i cambiamenti indipendentemente da quando accadono.

Fornire frequentemente software che funziona, da un paio di settimane a un paio di mesi, con una preferenza per i tempi più brevi.

Tornare al modello di conoscenza che identifica piccoli e grandi blocchi funzionali che possono essere forniti in modo indipendente pur mantenendo traccia di come si collegano ad altre parti del problema di business.

Le persone di business e gli sviluppatori devono lavorare insieme quotidianamente durante l’intero progetto. Utilizzando le tecniche Volere è possibile raggruppare ed esprimere la conoscenza sui requisiti sia dal punto di vista business sia da quello dello sviluppo. E soprattutto tenere traccia delle connessioni.

Costruire progetti attorno a persone motivate. Creare l’ambiente e fornire il sostegno di cui hanno bisogno, avendo fiducia che il lavoro verrà realizzato da loro.

Le tecniche di sociologia dei progetti supportano le differenze tra le persone e l’importanza che ogni gruppo di progetto abbia una strategia che si adatta al proprio mix sociologico.

Il metodo più efficiente ed efficace per scambiare informazioni verso e all’interno di un team di sviluppo è la conversazione faccia a faccia.

Volere è guidato dai contenuti e non dalla forma. Il nostro approccio, quando possibile, è quello di parlare faccia a faccia e lasciare una traccia se qualcun altro ha bisogno di raccogliere le informazioni. Il percorso dovrebbe idealmente essere il risultato di tenere una conversazione, in qualsiasi forma: blocco note, video, diagramma sulla lavagna, fotografia, libro degli indizi, modello scelto, e così via. In relazione alla sociologia del progetto, questa potrebbe essere l’unica documentazione necessaria.

Un software che funziona è la principale misura del progresso.

Naturalmente. Volere rende tutti i requisiti verificabili in modo che il “funzionamento” può essere dimostrato. Questo è aiutato anche dall’integrazione della prototipazione e della simulazione in qualsiasi fase del processo di sviluppo.

I processi agili promuovono lo sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere un ritmo costante a tempo indeterminato.

Volere supporta tutto questo, incoraggiando un linguaggio coerente, in modo che tutti gli interessati possano contribuire e condividere il fermento che il progresso offre.

L’attenzione costante all’eccellenza tecnica e buon design migliora l’agilità.

Le tecniche Volere forniscono diversi modi di articolare le alternative progettuali, confrontando e scegliendo il meglio, oltre a favorire il riconoscimento dei buoni modelli di progettazione.

La semplicità, cioè l’arte di massimizzare la quantità di lavoro non svolto, è essenziale.

Le tecniche Volere si concentrano sull’identificazione dell’essenza del problema e sulla selezione delle parti che forniscono il massimo valore di business.

I migliori requisiti, progetti e architetture emergono da team che si auto-organizzano.

Volere fornisce ai team che si auto-organizzano i mezzi per comunicare con l’intera azienda.

A intervalli regolari, il team riflette su come diventare più efficace, e quindi mette a punto e regola il proprio comportamento di conseguenza.

Le tecniche Volere affrontano entrambi gli aspetti, sociologici e tecnologici, e spingono le persone a cercare le ragioni sia tecniche sia sociali per il successo e il fallimento.

In conclusione – Per massimizzare il potenziale di agilità è necessario essere in grado di distinguere le tecniche che supportano la capacità di fornire software di valore da quelle che la inibiscono. Qualsiasi tecnica che costringe a fare le cose in un determinato ordine, a un livello fisso di dettaglio, o in una specifica forma, è una tecnica che inibisce l’agilità. Le tecniche Volere migliorano la capacità di essere agili, supportando il pensiero e la comunicazione con i colleghi, incoraggiando a essere innovativi ed estemporanei. Le tecniche sono basate su solidi principi di system engineering, quali: il partizionamento, il guardare da diversi punti di vista, la comunicazione degli scopi da raggiungere, gli elementi linguistici adeguati al dominio, l’operare astrazioni e i diversi livelli di dettaglio. È possibile lavorare in modo appropriato per il progetto e produrre un percorso della conoscenza come risultato di svolgere il proprio lavoro.

James Robertson

James Robertson è consulente, insegnante, autore e project leader. Il suo lavoro 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 tank conosciuto in tutto il mondo per le sue tecniche innovative di systems engineering.

Suzanne Robertson

Suzanne Robertson è principal dell’Atlantic Systems Guild. Indiscussa autorità nel mondo della system analysis e requirements modeling. È co-autore con James Robertson di Complete Systems Analysis: the Workbook, the Textbook, the Answers e di Mastering the Requirements Process. È roving ambassador per il Reuse Group della British Computer Society e ha fatto parte del comitato per Object Technology ‘97.

Suzanne Robertson presenterà a Roma per Technology Transfer il seminario “Mastering the Requirements Process” il 20-22 ottobre 2014 e James Robertson terrà sempre a Roma il seminario “Mastering Business Analysis” il 23-24 ottobre 2014.

L'articolo Agilità? Basta Volere proviene da Data Manager Online.

di Suzanne Robertson 

Marziano: Salve Terrestre. Mi porta dal suo capo?                                  

Terrestre: Ma ancora quei vecchi cliché? Sta per caso parlando di CEO, CIO, CTO, del capo dei business analyst, del project manager, del program manager, del product owner o del responsabile tecnico?

Veramente mi aspettavo un primo ministro o un presidente. Chi sono tutte queste persone di cui parla?

Tutti hanno un certo impatto sui requisiti per il progetto che sto facendo.

Requisiti? Cosa sono i requisiti?

Requisiti sono ciò che la soluzione deve fare, e come deve farlo. La sua navicella spaziale ha il requisito di essere in grado di viaggiare alla velocità di 25mila km all’ora, in modo da permetterle di fare il viaggio in circa 150 giorni, e deve tenerla comodamente in vita durante il viaggio da Marte.

Ci ho messo 100 giorni. Ma è stato davvero difficile capire il sistema di navigazione.

Questo è il risultato di un cattivo lavoro sui requisiti. Ci sono anche i requisiti ambientali riguardanti il freddo che si sarebbe trovato durante il viaggio, e i requisiti di sicurezza su chi potrebbe usare quali controlli, per non parlare dei requisiti di legge che avrebbero indicato che l’astronave non è parcheggiata correttamente in strada. Ma c’è molto di più. Io uso questo modello “Volere”, che mi aiuta a fare tutte le domande giuste.

“Volere”? Cos’è?

È un framework che molti utilizzano quando scoprono i requisiti. Trovo utile avere una guida senza essere vincolati da un processo formale. Mi piace molto.

Che cosa c’è di diverso?

In primo luogo, si fa una distinzione tra il lavoro e la soluzione. Il lavoro è l’attività che l’organizzazione sta facendo e la soluzione è l’automazione (o qualcos’altro) che è concepito per migliorare il lavoro.

Come si può sapere quale soluzione migliorerà il lavoro se non si sa in cosa consiste?

Esatto. È importante avere una chiara comprensione del lavoro e separarlo dalla tecnologia di qualsiasi soluzione alla quale si potrebbe pensare.

Come si fa a farlo?

Io uso questo modello “Brown Cow” che mostra ogni punto di vista e mi permette di vedere in qualsiasi momento esattamente quello che io e i miei stakeholder hanno bisogno di vedere.

Brown Cow?

Sì, magari dopo le spiegherò perché si chiama “Brown Cow”. Ma quello che mostra è una separazione della vista tecnologica, il Come, dall’essenza astratta, il Cosa. E poi si separa ulteriormente l’Ora dal Futuro. Rende davvero facile vedere di che cosa si sta parlando, e rende più facile comunicare con gli stakeholder.

Pensavo che “essenza” fosse un concentrato di una pianta.

Sì, in effetti ha anche quel significato, ma qui si intende il core del lavoro come se lo si potesse vedere senza alcun tipo di tecnologia abilitante. Cioè la filosofia sottostante, se vogliamo.

Voi terrestri siete così orgogliosi della vostra tecnologia. Ma perché bisogna vedere il lavoro senza la sua tecnologia?

Serve per vedere che si sta risolvendo il problema giusto, e non si sta solo utilizzando una soluzione interessante. Moltissimi progetti falliscono perché costruiscono una buona soluzione per il problema sbagliato.

Forse questo è il problema che abbiamo su Marte. Basta che diciamo cosa vogliamo e questo compare. Di solito si ottiene quello che diciamo di volere, ma poi si scopre che non è quello che ci serve. Se scoprissimo le nostre esigenze come fate voi terrestri, questo migliorerebbe le cose per noi?

È probabile, ma è necessario assicurarsi che si sta vedendo il vero problema e non solo parlando di una proposta di soluzione.

Noi marziani abbiamo “abstractOvision”, che voi potreste chiamare visione a raggi X. Possiamo vedere la ragione di fondo, guardando ogni soluzione.

Sarebbe utile, ma noi terrestri dobbiamo costruire modelli che ci facciano vedere l’essenza senza la sua tecnologia, perché è molto più facile guardare ogni vista separatamente. Non è così difficile da fare, ma bisogna pensarci un po’.

Voi terrestri parlate di pensare molto. Per esempio, cos’è il “Pensiero Sistemico”? È simile al modo in cui noi marziani pensiamo?

Forse, o anche meglio. Il pensiero sistemico (o dei sistemi) si ha quando si guarda la totalità di un sistema di business per garantire che se si cambia un componente non si influenza un altro. Inoltre, si potrebbe scoprire che un cambiamento vantaggioso per una parte del sistema significa che si apre un’opportunità in un’altra parte. Vuol dire che si guarda all’intera portata del lavoro.

Come si fa a sapere di avere davanti l’intera portata del lavoro?

Ecco dove “Volere” si dimostra particolarmente utile. Ho realizzato questo diagramma di contesto che mostra il lavoro e come si inserisce nel mondo che lo circonda. Questo mi permette di sapere esattamente quanto è ampio lo spazio di lavoro. Alcune delle aree problematiche sono grandi.

Grandi? Ma come si trattano i grandi problemi?

Ovviamente si dividono in più piccoli. Il mio metodo di suddividere il lavoro è utilizzare gli eventi di business.

Eventi di business?

Sì, eventi di business: sono le cose che accadono al di fuori del lavoro. Se guardo un evento di lavoro alla volta, vuol dire che sto vedendo il lavoro come lo vedono i clienti che ne sono al di fuori. Si tratta di un modo più naturale di suddividere.

Cosa si fa dopo aver suddiviso il lavoro?

Studio ogni partizione per giungere a un accordo con le parti interessate su ciò che tutti noi vogliamo e soprattutto abbiamo bisogno che il lavoro sia. Una volta che sappiamo che siamo in grado di cercare la soluzione ottimale, scriviamo sia scenari di utilizzo dei prodotti sia schede di eventi.

Schede di eventi?

Sì, scrivo un evento su una scheda come questa: “Come cliente della banca posso effettuare proiezioni sul mio bilancio in modo da poter vedere quello che mi rimane da spendere questo mese”. Questa scheda funge da segnaposto per i requisiti che si dipanano in una conversazione tra gli sviluppatori, il business analyst e alcuni degli stakeholder aziendali. Però, posso anche scrivere i requisiti utilizzando questa “snow card”.

“Snow card”?

Sì, è un modo per catturare i requisiti, per sapere perché i requisiti esistono e come misurarli, per poterli testare quando lo sviluppatore li realizza. Questo è ciò che definiamo un criterio adatto.

Come funziona un criterio adatto?

Supponiamo che io stia costruendo un sistema smart card per il trasporto urbano, e che io abbia un requisito non funzionale, come per esempio “Il prodotto deve essere intuitivo da utilizzare anche per chi lo usa la prima volta”. Ne chiederei la ragione sottostante, e potremmo supporre che questa sia “così la gente non ha esitazioni nell’usarlo e non si blocca alle porte di ingresso dei mezzi”. Vorrei misurare questo, aggiungendo così il criterio adatto, dicendo che “il 90% di chi viaggia per la prima volta passa attraverso il cancello di ingresso entro 3 secondi dal punto in cui si trova a un metro dal gate”. Si tratta di un requisito molto importante, per cui è valsa la pena e la spesa della sperimentazione su un gruppo di viaggiatori rappresentativi.

Ma lei ha parlato di requisiti non funzionali. Di cosa si tratta?

I requisiti funzionali sono ciò che il prodotto deve fare, mentre i requisiti non funzionali specificano quanto bene deve farlo. Per esempio, i requisiti non funzionali coprono aspetti quali il “look and feel”, l’usabilità, l’operatività, la sicurezza e così via. Ce n’è un elenco completo nel modello “Volere”, che può essere consultato online.

Posso vedere senza “online”, se ricorda la nostra vista a raggi X. E sì, questo modello si presenta come un elenco molto completo dei tipi di requisiti.

Lo trovo molto utile, in quanto mi permette di porre tutte le domande giuste, e agli stakeholder consente di capire perché io faccio tutte queste domande. Quindi, indipendentente dal fatto che io stia lavorando su un progetto agile o sequenziale, devo sempre trovare ciò che il prodotto deve fare e come deve farlo.

Tutti questi requisiti suonano come una quantità enorme di informazioni che devono essere elaborate da voi terrestri. Come si fa a tenerne traccia?

“Volere” comprende questo modello di conoscenza: una sorta di linguaggio per parlare di requisiti. Mostra tutte le informazioni che è necessario raccogliere, e aiuta a suddividerle in blocchi più piccoli e a utilizzarle per lo sviluppo iterativo. C’è anche un libro: “Mastering the Requirements Process”, anche in versione per Kindle.

Ah, ma io posso vederlo anche “online”: davvero interessante. Ne prenderò una copia su Marte.

Già che è “online”, dovrebbe dare un’occhiata al sito www.technologytransfer.eu, dove vi sono corsi specifici sul tema. Però, se fossi in lei, proseguirei: vedo che la sua astronave sta per essere multata. Ma a proposito, perché parla in corsivo?

Suzanne Robertson

Suzanne Robertson è un Principal dell’Atlantic Systems Guild. Indiscussa autorità nel mondo della system analysis e del requirements modeling, ha scritto e tenuto numerosi corsi su systems analysis, quality assessment e software design. Con James Robertson, ha scritto: “Complete Systems Analysis: the Workbook, the Textbook, the Answers” (Dorset House, 1994), “Mastering the Requirements Process” (Addison Wesley, 1999) e “Requirements-Led Project Management: Discovering David’s Slingshot” (Addison Wesley, 2004).

Suzanne Robertson presenterà a Roma per Technology Transfer il seminario “Mastering the Requirements Process” dal 7 al 9 aprile 2014

L'articolo Conversando con un marziano proviene da Data Manager Online.

By Suzanne Robertson e James Robertson

Avete qualche idea per una nuova disposizione del vostro giardino e volete comunicare i dettagli al vostro partner. Bene, tenete presente che un giardino è un sistema multidimensionale, che deve essere valutato in base a considerazioni intangibili e funzionali. Potete fare uno schizzo del nuovo layout, fare delle fotografie di giardini simili oppure fare una lista dei nomi di tutte le piante di cui avete intenzione di disporre. Ma quale di queste scelte è la migliore per comunicare le vostre idee? Ciascuna di esse ha un suo particolare vantaggio, ma il modo migliore è una combinazione delle varie tipologie di comunicazione. Lo stesso discorso vale quando si devono comunicare i requisiti per un sistema software poiché anch’esso è soggetto a considerazioni intangibili e funzionali. Per spiegare tutti i dettagli, le dimensioni e punti di vista dei requisiti dovete usare una combinazione di modelli, immagini e testo. E un modo per correlarle.

I punti di debolezza dei linguaggi naturali

I requisiti vengono di solito scritti utilizzando linguaggi naturali. Questi ultimi vengono utilizzati per specificare requisiti atomici, per definire obiettivi, descrivere scenari, sintetizzare livelli di requisiti. Il linguaggio naturale è conosciuto da tutti ed è quindi un terreno comune su cui si possono confrontare gli stakeholder della componente business e i tecnici che hanno il compito di creare il prodotto finale. Tuttavia, nonostante gli impliciti vantaggi, vi sono anche dei punti di debolezza.

Supponete di lavorare in un team dove tutti utilizzano uno stesso linguaggio nativo e che la lingua utilizzata sia l’inglese. I vostri compagni sono cresciuti imparando l’inglese, hanno imparato la grammatica e il vocabolario sin da quando erano bambini. E’ quindi naturale aspettarsi che tutti possano comunicare in inglese. Ma la lingua e il linguaggio sono compresi da tutti nello stesso modo? Ovviamente la risposta è no. L’esperienza personale insegna che il passaggio di informazioni a propri colleghi non sempre avviene con successo. Quando si parla a una persona guardandola negli occhi, e utilizzando un significato che noi diamo per condiviso, si ha la sensazione che la persona che ci sta di fronte comprenda tutto. Non è così, correte sempre il rischio di confrontarvi con un modello mentale che recepisce quanto da voi comunicato nel modo sbagliato.

Comunicare un’idea a un’altra persona, facendo sì che l’interpretazione del significato sia del tutto identica a entrambi gli interlocutori è molto più difficile di quanto si possa immaginare. D’altra parte dobbiamo essere consapevoli che si ricevono informazioni, e le si elaborano, in base alla propria esperienza e attitudine. Ecco perché è utile capire i problemi di comunicazione che possono nascere dall’utilizzo di un linguaggio naturale, anche in contesti specifici come quelli, appunto, legati allo sviluppo di un sistema software e alla definizione dei suoi requisiti.

Durante l’attività di ricezione del messaggio, aspettative, linguaggio corporeo, cultura e altri fattori possono interferire e alterare la comprensione del significato. L’interpretazione è dipendente dall’esperienza e dalla cultura. E’ l’importanza che viene attribuita al messaggio, importanza legata a criteri di priorità mentale del ricettore, che può determinare il successo della comunicazione. La risposta viene quindi formulata in base a una serie di elementi potenzialmente distorsivi che compromettono il significato originario. Nel momento in cui si vuole definire l’ampiezza e portata di un problema, in modo che gli interlocutori ne percepiscano l’esatta valenza, dobbiamo, quindi, essere coscienti della difficoltà e dei limiti del linguaggio naturale. Per esempio, una descrizione testuale di un’area di business non ha molta speranza di poter essere definita con sufficiente precisione in modo tale da indicare quali funzionalità siano interne o esterne a essa.

I linguaggi naturali sono molto spesso il miglior modo per definire requisiti atomici. Tuttavia, se il numero di questi ultimi è dell’ordine delle migliaia è impossibile gestirli senza un livello di dettaglio intermedio. Occorre perciò definire ciascun livello di dettaglio in modo da non compromettere il significato. Il potenziale rischio di una cattiva comunicazione può essere gestito utilizzando un insieme di modelli, di linguaggi, di sketch o immagini informali.

Una cornucopia di modelli

Esistono tutta una serie di modelli che possono essere usati per definire i requisiti: modelli che si focalizzano sul processing, altri che hanno maggiore attinenza con i dati, altri che si concentrano sullo stato. Vi sono pertanto modelli che fanno riferimento a processi di business, diagrammi di attività UML, diagrammi di classe, modelli di relazioni tra entità, diagrammi di transizione di stato, diagrammi SYSML… la lista è praticamente infinita. Considerate tutte le possibili opzioni, per aiutarvi nella specifica dei requisiti del vostro ambiente, vale la pena prendere come riferimento i modelli più utili.

Definire la portata dell’intervento

Come precedentemente detto, occorre definire la portata o scope del sistema in modo che sia interpretata correttamente da tutti. A livello più alto si devono identificare le funzionalità incluse e quelle che, invece, ne vengono specificamente escluse. E’ difficile descrivere o declinare le funzionalità in un modello mentre quest’ultimo risulta efficiente per quanto riguarda i dati. Ciascuna funzione deve processare propri dati di input e produrre un output corrispondente: in questo modo, modellando i dati e il materiale che entra ed esce dal vostro scope di studio, potrete formulare senza nessuna ambiguità le funzionalità incluse. Per ciascun input e output si dovrà poi specificare la provenienza e la sua destinazione. Un modo semplice per fare ciò è disegnare un diagramma del contesto di lavoro in cui si evidenziano dati e materiale in input e in output andando a caratterizzare con forme geometriche le diverse funzionalità. Questi diagrammi servono a mappare i requisiti al loro più alto livello. Si può inoltre migliorare e rendere più accettabile la comunicazione utilizzando una terminologia sufficientemente conosciuta da tutti. Se ciascun flusso ha un significato unico e ben definito, il diagramma non darà adito ad alcuna ambiguità interpretativa.

Il collante del dizionario dati

Il dizionario dati è il repository per il significato di ciascuno degli input e output dei vostri diagrammi di contesto di lavoro. Prendiamo come esempio l’input di una richiesta di estensione di un prestito di un libro presso una biblioteca. Per essere sicuri che tutti ne abbiamo la stessa identica comprensione ne deve essere definito il significato all’interno del dizionario dati.

La richiesta di estensione del prestito può corrispondere a un input che contiene codice debitore, codice ISBN del libro, titolo del libro e data di estensione richiesta. E’ quindi opportuno trasferire maggiori livelli di dettaglio nel dizionario dati, per esempio, per quanto riguarda l’ISBN: identificativo unico del libro, assegnato dall’agenzia responsabile dell’ISBN in ciascun particolare Paese.

Definendo in modo accurato il contenuto, e di conseguenza il significato, dei dati in input e output, fate sì che si costruisca una base di comprensione comune del significato. Infine, raggiunta una definizione atomica dei requisiti, si continueranno a utilizzare i termini definiti nel dizionario. In questo modo il pericolo di ambiguità del significato viene minimizzato, se non annullato.

Conclusioni

In questo articolo abbiamo discusso dei limiti dell’utilizzo di un linguaggio naturale relativamente a un’attività di definizione dei requisiti. Altrettanti limiti possono esistere se si utilizzano modelli. L’idea vincente è di combinare modelli e linguaggi naturali e creare relazioni utilizzando il formalismo di un dizionario dati.

——————————————————————–

Suzanne Robertson è una system engineer specializzata nel campo dei requisiti. E’ un Principal dell’Atlantic Systems Guild. Ha scritto e tenuto numerosi corsi su systems analysis, quality assessment e software design sia per sistemi procedurali che Object-Oriented. Ha scritto con James Robertson i libri: “Complete Systems Analysis: the Workbook, the Textbook, the Answers” (Dorset House), “Mastering the Requirements Process” (Addison Wesley), “Led Project Management: Discovering David’s Slingshot” (Addison Wesley). Ha più di 30 anni di esperienza nella specifica e nella costruzione dei sistemi. Ha ideato Volere, un insieme completo di processi e templates per valutare la qualità dei requisiti e per la specifica dei requisiti di Business.

James Robertson è un consulente, docente, autore e project leader. Il suo lavoro nell’area della Business Analysis e della raccolta dei requisiti è apprezzato da molti clienti in molte parti del mondo. E’ co-autore di “Mastering the Requirements Process”, “Requirements-Led Project Management” e dell’approccio Volere per l’engineering dei requisiti. E’ anche fondatore dell’Atlantic Systems Guild, un think thank conosciuto in tutto il mondo per le sue tecniche innovative di systems engineering.

Saranno presentati a Roma per Technology Transfer i seminari di Suzanne Robertson “Mastering the Requirements Process” del 22-24 Ottobre 2012 e di James Robertson “Mastering Business Analysis” del 25-26 Ottobre 2012.

L'articolo Modelli e linguaggi naturali, quale il modo migliore per definire i requisiti? proviene da Data Manager Online.