Questa immagine l’ho vista la prima volta molti anni fa, non saprei neanche più ricavare la sua provenienza, è conservata sul mio computer ed è l’avatar che uso quando eseguo l’accesso alla mia postazione di lavoro.
Per me esprime quanto di più vicino il genere umano possa immaginare nel comprendere un contesto leggendario, archeologicamente posto intorno al II millennio a.C. e riferito alla ziggurat Etemenanki: la Torre in Balilonia. Famosa la rappresentazione pittorica della Torre di Balele disegnata da Pieter Bruegel nel 1563 (fonte wikipedia, “un dettaglio”).
Nonostante sia passato qualche migliaio di anni il contesto lo trovo attualissimo.
C’è una disciplina che cerca di avvicinare “how the customer explained it” e “what the customer really needed“: la Business Analysis (BA).
La BA contiene l’insieme dei compiti e delle tecniche utilizzati per lavorare, in accordo con Stakeholders. Il fine è quello di capire la struttura, le politiche e le operazioni di una organizzazione e consigliare soluzioni che consentano di raggiungere un obiettivo. Si parte dal requisito per conseguire un obiettivo.
Un requisito è definito in letteratura in molti modi, qui ne riporto alcuni.
- Condizione o capacità necessaria ad uno stakeholder per risolvere un problema o ottenere un obiettivo.
- Condizione o capacità che deve essere soddisfatta o posseduta da una soluzione o una Componente per soddisfare un contratto, uno standard, una specifica o altro indicato formalmente in un documento.
La mia preferita è: una descrizione astratta di alto livello che indica qualcosa che un sistema deve fare o di un vincolo che deve essere osservato.
Da ciò si comprende come non esista una sola tipologia di requisito poiché è in relazione al contesto in cui si opera.
In prima istanza occorre capire cosa raccogliere.
Mr. McConnell [graduated with a bachelor’s degree in philosophy (meraviglioso), minoring in computer science] dice: The most difficult part of the requirements development activity of helping users figures out what they want.
L’elicitation a mio parere è il cuore della BA, mi piace però evidenziare che sollecitare non è raccogliere.
Altra aspetto fondamentale è l’esame di tutti i requisiti giusti e reali.
Di seguito rappresento il percorso lineare, come indica l’approccio descritto nella guida Babok v3, che riformula i principi della versione precedente (Babok v2) che unifica in requirements e designs facilitando il ciclo di analisi.
Una volta analizzato, un requisito deve osservare molteplici characteristics, e tutti i requisiti, ma proprio tutti, devono trovare corrispondenza con i bisogni.
Anche io amo disegnare mappe mentali con classificazioni e raggruppamenti estremamente flessibili che mi permettono di “vedere” cosa si sta costruendo. Mantengo però sempre un link fra il requisito raccolto, la sua analisi e la successiva specificazione.
Il requisito è fondamentale per conseguire un obiettivo, ma qual è il modo migliore per formalizzare un requisito?
IREB lo definisce boilerPlate per formalizzare in maniera testuale un requisito quando si deve costruire un sistema informativo.
Ha lo scopo di ridurre le ambiguità e le inconsistenze che nascono quando si applicano le tecniche previste nelle aree elicitation e requirements analysis (Babok).
Il vantaggio maggiore a mio parere è agevolare l’interazione fra il business analyst e gli stakeholder.
Sono curioso di conoscere statistiche su quanto è diffusa questa pratica e quali principali difficoltà incontra.
Grazie del post Gianni,
ho una domanda relativamente alla verifica dei requisiti come definiti dal BABOK per la Knowledge Area “Requirements Analysis and Design Definition”. In particolare, il BABOK consiglia di usare delle checklist per il completamento del task “Verify Requirements”. Sapete indicarmi degli strumenti/risorse per costruire una checklist in base alle mie necessità relativamente agli standard di qualità dei requisiti?
Se può essere utile ad altri, premetto che attualmente sto prendendo spunto dalle linee guida NASA (https://www.nasa.gov/seh/appendix-c-how-to-write-a-good-requirement/), settore che intende i sistemi con una logica affine a quella che tratto nel mio settore (IT Consulting).
Ma sarei comunque interessato ad avere altri consigli, soprattutto relativamente ai – chiamiamoli – “quality gates in contesto adattivo”.
Grazie a tutti!
Ciao Daniele, con Italy Chapter in passato avevamo pensato di costruire una libreria di template, anche sfruttando gli esercizi che si fanno con il Gruppo di Studio del Babok promosso dal Chapter. Ma poi non abbiamo finalizzato, nè noi ne altri Chapter se non erro, forse perchè il Babok rimane sempre a livello molto alto senza suggerire specifici template che potrebbero essere… infiniti! Un suggerimonto banale che talvolta fornisco è quello di costruirsi in proprio un semplice XL per tracciare gli id con un ID, Nome_req, Desc_req, Data_creaz, Autore_creaz, Data_mod, Autore_Mod, e poi una serie di stati relativi al loro ciclo di qualità, oltre che eventuali ID_Padre o ID_Figlio o ID_Fratello per eventuale classificazione gerarchica e/o altri attributi utili alle tue esigenze specifiche (es. se è un requisito di back-end, di front-end, oppure la fase di processo relativa…). E da oggi grazie a te segnalerei come risorsa anche la check-list della Nasa, Grazie!
ciao Daniele,
grazie per l’attenzione e il tuo ulteriore contributo: lo scopo del blog è proprio questo e tu sei stato bravo a coglierlo.
Come ha già risposto Luigi in precedenza, il manuale dell’IIBA non farà mai riferimento a specifici strumenti ma mette nelle condizioni di capire di cosa abbiamo bisogno per ottenere gli scopi prefissati.
Innanzitutto prenderei in considerazione il contesto in cui mi trovo, non tutte le organizzazioni approcciano alla Business Analysis allo stesso modo.
Se mi coinvolgono per lavorare alla NASA e devo predisporre una matrice come la tabella D-1 allora posso immaginare un certo tipo di organizzazione con determinati standard e processi di controllo.
Inoltre non considero l’effort necessario per produrre e poi manutenere quella griglia.
Mi trasmette una visione documentaristica delle attività opposta all’attuale necessità di osservazione e gestione dell’evoluzione e del cambiamento che sono le caratteristiche vincenti richieste per un buon risultato.
Oggi gli strumenti di lifecycling management oltre ad essere basati su piattaforme condivise permettono di fruire di informazioni strutturate, codificate e con propri workflow.
L’oggetto “requisito” dalla sua nascita fino alla suo “rilascio” si arricchisce di tali patrimoni informativi che stridono abbastanza con la visione ‘foglio excel’.
Perché vedere la checklist come una lista su un foglio di calcolo o su un documento?
Potrebbe anche essere una serie di task/attività a loro volta corredati da materiale che è servito allo scopo e con relativa Kanban di monitoraggio.
Poi si è sempre liberi di usare un documento per scrivere i requisiti, usare fogli di calcolo per tracciare e monitorare eventi, riportare informazioni già espresse in altri deliverable per avere riepiloghi soddisfacenti, referenziare materiali sparsi nel tuo repository.
Contattami su linkedIn e ci confrontiamo su qualche tool più appropriato.
Quindi a mio parere il segreto è capovolgere l’impostazione, e arriviamo alla domanda:
come e quando arriverò alla fase in cui occorre verificare i requisiti in che modo sarò in grado di gestirli?
Provo ad andare controcorrente.
Il ragionamento è ineccepibile e va bene tra business analysts, ma in azienda, con utenti che non hanno competenze solide di business analysis, la parola requisito (o requirement) andrebbe abolita.
E’ quasi una provocazione sostenere questo, ma ci sono molti modi interessanti e stimolanti per scrivere i requirements senza nominare la parola.
Gli strumenti proposti dalle metodologie Agile mi sembrano piu’ promettenti.
ciao Francesco, non credo che tu sia controcorrente. La prassi vuole che si dialoghi con il committente ma ciò non si traduce in “dammi i requisiti”. Di solito invece questo termine viene più usato a valle dell’interazione con il committente e all’interno del ciclo di vita del disegno e della costruzione. Sempre parlando di business analysis un esempio è la cornice del framework BACCM (qui un mio contributo https://miacomunicazione.wordpress.com/2023/01/12/quando-il-baccm-diventa-canvas/) in cui si dovrebbe comprendere quali fattori e quale contesto agiscono e condizionano l’attività più complicata in carico al business analyst.
Venendo all’Agile e premesso che uno dei limiti è che applicare quella metodologia non è sempre possibile mi potresti dire a quali strumenti fai riferimento?