La qualità dei Solution Requirements

Tutte le organizzazioni desiderano chiarezza e allineamento fra i diversi stakeholder, ma spesso l’approccio può risultare manchevole, creando distanza fra necessità strategiche e tattiche implementative, o in altri termini, solutions requirements con una qualità insufficiente.

Le tecniche per modellare un requisito posso essere molteplici, come abbiamo introdotto.

Fra gli strumenti suggeriti dal Babok v3 troviamo le checklists, facilmente adattabili alle proprie esigenze, ma strutturanti la natura stessa dell’informazione.

In questo articolo approfondiamo le modalità con cui ci si può assicurare che i requisiti legati alla soluzione (Solution Requirements) siano effettivamente di qualità, con le eventuali considerazioni da fare a risalire verso i requisiti di business (Business Requirements).

Aspetti organizzativi

In ambito Software Development, le organizzazioni che lavorano secondo approcci adattivi (in particolare di natura Agile, più o meno maturi) rischiano di non avere le giuste pratiche per assicurare qualità dei requisiti, giustificate dalla natura iterativa dei processi implementati.

Premesso che l’apprendimento organizzativo si costruisce con scambio interpersonale e buy-in degli stakeholders, le pratiche che operano sugli aspetti più strutturali e svincolati dall’agency degli attori hanno comunque una forza importante nell’operare il cambiamento. Queste pratiche segnalano la guida che l’organizzazione è in grado di porre sulla conformità dell’informazione per creare allineamento fra teams, piuttosto che avere linee di reporting e controllo mirate a porre un unico punto di approvazione.

In tal senso, strumenti di controllo di processo gestiti in maniera orizzontale e soggetti a revisione periodica rafforzano l’efficacia delle pratiche adattive, sottolineando le possibilità di contribuzione e l’ownership condivisa, permettendo di ritestare ciclicamente i presupposti su cui si basano tali strumenti.

In altre parole, il risultato finale dipende anche da quanto è diffusa la consapevolezza che TUTTI gli stakeholders abilitano il lavoro del singolo e ciascuno strumento scelto non è mai neutrale.

Ad ogni modo, lo sforzo per assicurarci che un requisito sia di qualità è direttamente legato al livello di formalità scelta. Per evitare di avere sistemi di conformità troppo complessi da manutenere, è fondamentale bilanciare convenienza ed efficacia, basandosi sugli strumenti e sulla mentalità propri dell’organizzazione.

Consigli del Babok per Solution Requirements di Qualità

Tre Knowledge Areas del Babok v3 ci offrono supporto nel strutturare la logica sottostante a questi strumenti:

1. Business Analysis Planning and Monitoring: area che descrive le attività per organizzare e coordinare l’effort di Business Analysts e stakeholders;
2. Requirements Analysis and Design Definition: area che descrive le attività mirate a modellare e specificare requisiti e designs, così come a validare e verificare le informazioni utili a soddisfare i bisogni organizzativi tramite un confronto tra possibili soluzioni;
3. Requirements Life Cycle Management: area che descrive le attività di gestione e manutenzione di requisiti e design, dalla creazione al ritiro.

Raccogliendo i suggerimenti e le linee guida indicate nella guida, possiamo identificare vari aspetti in base a cui valutare la bontà di un requisito. La valutazione di questi aspetti può essere poi condensata in un checklist mirata ad assicurare qualità e allineamento fra stakeholders.

In maniera più generale, specificatamente alla verifica dei requisiti, il Babok v3 (versione in inglese) indica come di qualità requisiti che siano:

• Atomic
• Complete
• Consistent
• Concise
• Feasible
• Unambiguous
• Testable
• Proritized
• Understandable

Queste caratteristiche riguardano tutti i tipi di requisiti, ma relativamente ai Solution Requirements e loro qualità in ambito Agile è molto diffusa la pratica di adottare il punto di vista dell’utente finale o del beneficiario della soluzione scelta. L’ acronimo INVEST permette l’accostamento fra User Stories, attività e requisiti.

• Independent
• Negotiable
• Vertical
• Estimable
• Small
• Testable

Come si può notare, c’è una relativa sovrapposizione fra i criteri generali di qualità raccomandati dal Babok v3 e le buone pratiche diffuse in ambito Agile. Tra questi criteri, la seguente lista di attributi potrebbe essere un buon punto di partenza che riassume gli aspetti di qualità usati anche dagli approcci adattivi per i Solution Requirements:

• Chiarezza
• Tracciabilità
• Completezza
• Manutenibilità
• Testabilità

Chiarezza

La chiarezza può essere definita come l’assenza di ambiguità, ovvero la restrizione del campo concettuale a poche variabili. Si tratta di una caratteristica associata a concetti dotati quanto più possibile di autonomia e indipendenza semantica, e perciò privi di informazioni non necessarie, concisi, mirati e ristretti.

Inanzitutto, per migliorare la chiarezza del requisito e ridurre le alternative di interpretazione, è importante che le frasi siano grammaticalmente corrette e prive di errori di battitura.

Un’altra indicazione è il preferire strutture positive nelle frasi, contrapposte a quelle negative (ovvero, “DEVE” piuttosto che “NON DEVE”). In tale maniera si specifica l’insieme a cui un concetto appartiene, piuttosto che fare riferimento a ciò che vi è estraneo.

L’utilizzo di liste puntate permette di combinare più facilmente queste caratteristiche con la necessità in ambito Agile di esprimersi secondo criteri di accettazione. Nuovamente, possiamo soddisfare l’aspetto di atomicità indicato dal Babok tarando la dimensione di ciascun punto.

Tracciabilità

La tracciabilità si focalizza sull’esposizione di una chiara visibilità delle informazioni raggiungibile tramite categorizzazione, scomposizione funzionale e attribuzione di metadati, ad esempio lo status, così come potenzialmente il tracciamento delle attività o items legati.

Status

Tracciare un requisito significa esporne l’origine e gli impatti. Scegliendo di porre diversi requisiti in un solo documento, una modalità per esprimere lo Status potrebbe essere l’utilizzo di quattro opzioni disponibili:

• IN CORSO: le attività di analisi, stesura e negoziazione delle informazioni sono ancora in corso
• IN ATTESA DI APPROVAZIONE: i requisiti nel documento sono stati modellati e hanno il livello di qualità richiesto per l’approvazione da parte degli stakeholder principali
• APPROVATO: questo stato (non eterno) indica che gli stakeholder indicati hanno approvato le informazioni presenti e i requisiti hanno un livello sufficiente per poter essere presi in carico
• DEPRECATO: il requisito è stato indicato come non più in linea con lo Scope della soluzione/iniziativa

Per ognuno di questi valori, è utile tracciare l’ultima data di cambiamento di stato, indicando anche stakeholders coinvolti ed eventuali motivazioni aggiuntive.

Attività

Ad ogni requisito raccolto tramite lista puntata, dovrebbe essere possibile associare le attività richieste per il suo soddisfacimento.

In ambito Agile, strumenti come il Product Backlog consentono di tenere facilmente traccia delle attività rimanenti. Per massimizzare la tracciabilità di requisiti e designs preventivamente negoziati e poi accettati, risulta utile l’associazione di singoli punti atomici alle relative attività mirate al completamento di un incremento di valore.

Ogni caratteristica di un design dovrebbe avere un insieme di attività esplicitate in fase di analisi. Usando un Product Backlog per l’associazione di attività e Solution Requirements, è possibile perciò avere anche una maniera flessibile e trasparente di riprioritizzazione delle necessità.

Completezza

La completezza è legata alle proprietà identificate dalla semiologia come “estensione” e “intensione“.

L’estensione di un enunciato è il suo valore di verità riferito a tutti i possibili concetti. L’intensione è l’insieme delle informazioni specifiche che determinano a cosa si riferisce l’espressione. Ne consegue che maggiore è l’estensione, minore è l’intensione.

Ad esempio, i quadrupedi sono un’ampia classe caratterizzata dall’essere animali con quattro gambe. I gatti sono una sottoclasse dei quadrupedi e hanno un numero maggiore di proprietà specifiche.

In poche parole, ci interessa sapere di più sulle relazioni che un concetto ha con la classe dei concetti a cui appartiene? Oppure ci interessa avere una maggiore specifica circa le proprietà specifiche e gli attributi di quel concetto?

In ambito software, dove i sistemi tecnologici sono il focus principale, fra gli aspetti di completezza possibili possiamo identificare:

• assunti (benefici attesi dall’implementazione e riferimenti alla strategia corrente)
• utenti finali (da un punto di vista organizzativo e di business)
• disponibilità (ruoli applicativi impattati, disponibilità del dato)
• comportamento (architettura dell’informazione/UX e logica funzionale)
• requisiti non funzionali (aspetti relativi a qualità del servizio, performance, usabilità)
• dipendenze (sia logico-funzionali, sia a livello di modello dati)
• interfaccie tecniche (relative a vincoli tecnici, quali DTO, firme, metodi, protocolli)

To Be Resolved

In entrambi i casi, è importante identificare i punti ciechi e renderli ben visibili tramite l’utilizzo di strumenti come il TBR (To Be Resolved). Lo scopo è quello di catturare l’incertezza e il rischio derivante da un’incognita per poterlo tracciare e risolvere attraverso le modalità che più si adattano all’approccio usato dall’organizzazione.

Le modalità di risoluzione potrebbero riguardare la raccolta di ulteriori requisiti da parte di stakeholder specifici, così come il testing di specifiche ipotesi in ambiti incerti.

Il TBR può essere visto come appartenente alla categoria più generale degli strumenti di Item Tracking, come descritti dal Babok v3, pensati anche per derivare metriche benefiche alla trasparenza dell’iniziativa.

Qualunque sia la strada scelta, è bene non lasciare i punti incompleti senza indicare stakeholders e momenti dedicati alla risoluzione. In caso ciò si verifichi, sarebbe cosa buona e giusta indagare gli aspetti di strategia legati agli effettivi bisogni di business, capendo conseguentemente gli impatti sugli altri tipi di requisiti.

Manutenibilità

Riutilizzo

Uno degli aspetti chiave che determina la qualità di un requisito è la facilità del suo riutilizzo, instrinsecamente legata alla facilità di accertarsi della sua correttezza nel tempo. Per tale motivo, implementare manutenibilità aiuta nel riconoscere in anticipo limitazioni nella soluzione implementata. A titolo informativo, il Babok v3 identifica varie tipologie di requisiti candidati al riutilizzo, come ad esempio requisiti legali, contrattuali, standard di qualità, SLA, regole o processi di business, features, interfacce.

L’utilizzo di una tassonomia condivisa per l’iniziativa (o meglio ancora a livello di organizzazione) facilita il mantenimento (nonché la tracciabilità) dei requisiti esistenti.

Nuovamente, la dimensione del singolo requisito è importante per restringere la specificità delle specifiche su una singola soluzione. Focalizzarsi sull’atomicità e l’indipendenza logico-concettuale favorisce la riadattabilità delle informazioni.

Testabilità

La testabilità è una qualità direttamente legata alla restrizione del campo applicativo di un requisito all’interno della logica del vero/falso. Un requisito testabile può essere sottoposto a test sperimentale, ovvero si compone di assunti formalmente dimostrabili sulla base di verifica empirica.

Nell’ambito generale del Babok v3, la testabilità non riguarda solo la qualità e la conformità della soluzione implementata, ma anche gli assunti sono testabili (ad esempio nell’ambito di un’attività esplorativa di mercato).

Ad ogni modo, nello scope dei Solution Requirements, la testabilità viene garantita tanto più quanto vengono evitati termini qualitativi non verificabili (flessibile, facile, sufficiente, sicuro, ad hoc, adeguato, user-friendly, usabile, “se necessario”, appropriato, veloce, portatile, leggero, piccolo, grande, e via dicendo). Come è possibile notare, questi termini possono essere adatti in fasi precedenti per contestualizzare un requisito di business o legati agli stakeholders, ma peccano in termini di verificabilità.

In questo senso, i criteri di validazione di un Solution Requirement (funzionale o non funzionale che sia) devono poter essere misurabili secondo parametri quantificabili (ad esempio, in termini di verità/falsità, occorenze, secondi, banda, ecc.).

Ne consegue che per un testing efficace, le precondizioni devono essere chiare.

Una checklist per Solution Requirements di Qualità

Come abbiamo visto, la qualità dei Solution Requirements può essere valutata sotto diversi aspetti. Per ognuno di questi aspetti abbiamo evidenziato delle caratteristiche che proviamo a raccogliere nella seguente checklist, uno strumento veloce e flessibile.

• Tracciabilità
  1. I requisiti sono facilmente identificabili con codici univoci
  2. Status presente e aggiornato
  3. I requisiti raggiungono la percentuale desiderata di attività implementative associate
• Chiarezza
  1. I requisiti vengono scritti tramite lista a punti
  2. Ogni frase è priva di errori grammaticali e di punteggiatura
  3. Ogni requisito è scritto in forma attiva e positiva
• Completezza
  1. I requisiti incompleti sono tracciati usando lo schema TBR
  2. Tutte gli aspetti di un requisito sono stati riempiti. In caso contrario, viene usato un TBR.
• Manutenibilità
  1. Vengono utilizzati solo i termini decisi a livello di tassonomia di iniziativa
• Testabilità
  1. Ogni requisito è privo di termini non verificabili
  2. Ogni requisito è espresso secondo parametri quantificabili
  3. Le precondizioni per il testing sono state definite

Conclusioni

Il Babok v3 rappresenta un’incredibile risorsa per ciascun Business Analyst ed è ricco di suggeriementi per l’effettivo adattamento delle pratiche di settore. Traendone spunto e accostando pratiche proprie di framework adattivi, abbiamo mostrato come sia possibile identificare caratteristiche base per costruire un punto di riferimento comune circa la qualità dei Solution Requirements.

Ne va da sé che quanto mostrato è frutto di una realtà organizzativa particolare e ciò che è davvero importante è astrarre la logica di identificazione delle caratteristiche legate al requisito. Infatti, se i criteri secondo i quali sono andato a definire la qualità di un requisito potrebbero essere diversi in un’altra organizzazione, ciò che resta uguale è la pratica di scomporre questi concetti ed esplorarne la portata in termini di verifica in ambito di qualità.

A mio avviso, al centro si trovano le pratiche collaborative nella definizione di tali tassonomie, pratiche pensate per portare allineamento fra stakeholders, ridefinire priorità e assicurare il buy-in organizzativo.

Il mio appello è perciò quello di andare cercando coesione, con un eventuale navigazione della politica interna!