Comunicare in modo efficiente senza correre il rischio di non essere compresi è quanto mai complicato. La soluzione sta nel combinare diverse forme di espressione e linguaggi
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.
