Requirements Management in PM²: trasformare bisogni in criteri verificabili

Sedicesimo articolo della serie “Imparare PM² attraverso un progetto”

La frase “ci serve una funzione per le prenotazioni” non è un requisito gestibile. Esprime un bisogno, ma non definisce chi usa la funzione, in quale situazione, con quale regola, quale risultato deve produrre e come si verificherà che sia corretta.

In PM², il Requirements Management serve a far sì che il progetto consegni ciò che è stato realmente concordato, non soltanto ciò che il team ha interpretato.

Che cosa è un requisito

Un requisito descrive una necessità, una capacità, una condizione o un vincolo che una soluzione deve soddisfare.

Può riguardare:

Tipo	Esempio
Business requirement	Ridurre i no-show nelle lezioni di gruppo.
User requirement	Un iscritto deve poter annullare una prenotazione entro un limite configurabile.
Functional requirement	Il sistema deve liberare automaticamente il posto e promuovere il primo utente in lista d’attesa.
Non-functional requirement	La disponibilità dei posti deve aggiornarsi entro cinque secondi in condizioni normali di utilizzo.
Constraint	L’accesso deve usare l’autenticazione già presente in Annotatio.

Distinguere questi livelli evita un errore comune: discutere subito la soluzione tecnica prima di avere chiarito il problema e il risultato atteso.

Il ciclo di vita di un requisito

flowchart LR
  A[Raccogliere] --> B[Analizzare e chiarire]
  B --> C[Documentare e validare]
  C --> D[Approvare e baselinare]
  D --> E[Realizzare e verificare]
  E --> F[Accettare o gestire la modifica]

Un requisito non è “finito” quando è scritto. È gestito quando resta collegato alla sua origine, alla decisione che lo ha approvato, al deliverable che lo implementa e alla verifica che dimostra il soddisfacimento.

Le caratteristiche di un buon requisito

Caratteristica	Domanda di controllo
Chiaro	Due persone lo interpretano nello stesso modo?
Necessario	Contribuisce a un bisogno, un beneficio o un vincolo reale?
Completo	Indica contesto, regole, eccezioni e risultato atteso?
Verificabile	Esiste un test, un criterio di accettazione o un’evidenza oggettiva?
Fattibile	Può essere realizzato con vincoli, capacità e tecnologie disponibili?
Tracciabile	Possiamo risalire a origine, decisione, implementazione e test?

Parole come “intuitivo”, “veloce”, “moderno” o “facile” non sono vietate, ma da sole sono ambigue. Vanno trasformate in condizioni osservabili: per esempio, “un nuovo iscritto completa una prenotazione in massimo tre passaggi, senza assistenza”.

Baseline dei requisiti: il punto da cui si misura il cambiamento

Quando un insieme di requisiti è analizzato, concordato e approvato, diventa una baseline. Da quel momento non deve essere modificato informalmente.

Questo non rende il progetto rigido. Rende visibile la differenza fra:

chiarire meglio un requisito già approvato;
correggere un difetto di implementazione;
proporre una modifica del requisito o dello scope.

L’ultimo caso richiede Change Management: registrazione, valutazione di impatto e decisione da parte dell’autorità competente.

Tracciabilità: perché serve davvero

La tracciabilità collega almeno quattro elementi:

Collegamento	Domanda a cui risponde
Bisogno / beneficio → requisito	Perché stiamo realizzando questa cosa?
Requisito → deliverable o attività	Dove viene realizzata?
Requisito → test o criterio di accettazione	Come dimostriamo che è soddisfatto?
Requisito → change / decisione	Perché è cambiato, chi l’ha deciso e con quale impatto?

Non occorre sempre uno strumento complesso. Per un progetto piccolo può bastare una tabella disciplinata; per uno grande può servire un backlog o un repository dedicato. Conta la catena di evidenze, non il software usato.

Il caso Annotatio: da richiesta vaga a requisito verificabile

Richiesta iniziale: “Vorremmo gestire meglio la lista d’attesa”.

Una possibile evoluzione è:

Livello	Formulazione
Bisogno business	Ridurre posti vuoti causati da cancellazioni tardive.
User requirement	Il gestore deve poter definire se la promozione dalla lista d’attesa è automatica o manuale.
Functional requirement	Quando un posto si libera, il sistema deve notificare il primo iscritto in lista; se non conferma entro 30 minuti, deve passare al successivo.
Criterio di accettazione	In una prova con tre utenti in lista, il primo riceve la notifica; allo scadere dei 30 minuti senza risposta, il secondo è promosso e l’evento è registrato.

Questa formulazione rende possibile stimare, sviluppare, testare e accettare. Inoltre fa emergere domande che la richiesta vaga nascondeva: il tempo è configurabile? cosa avviene se non ci sono notifiche push? il gestore può intervenire? esistono limiti per le cancellazioni?

Validazione e verifica: due azioni diverse

Azione	Domanda	Chi contribuisce tipicamente
Validazione	Stiamo specificando la cosa giusta per il bisogno?	PO, BM, utenti e stakeholder di business.
Verifica	La soluzione realizza correttamente ciò che è stato specificato?	Team di soluzione, QA, PM e soggetti coinvolti nell’accettazione.

Una funzione può superare tutti i test e non creare valore: in quel caso è verificata, ma il requisito potrebbe non essere stato validato bene.

Da non confondere

Affermazione	Correzione
“Un requisito è una schermata o una soluzione tecnica.”	Può esserlo a un livello dettagliato, ma prima deve esprimere bisogno, capacità o vincolo.
“Se il cliente lo dice a voce, è già nello scope.”	Deve essere chiarito, documentato e approvato secondo la governance.
“Un test che passa dimostra che abbiamo costruito la cosa giusta.”	Dimostra soprattutto che è stata implementata secondo una specifica; la validazione riguarda il bisogno.
“La baseline blocca ogni cambiamento.”	Permette di gestire i cambiamenti in modo consapevole e tracciabile.

Tre domande per fissarlo

Quale beneficio o bisogno giustifica questo requisito?
Come dimostrerai oggettivamente che è soddisfatto?
Se cambia dopo l’approvazione, quale impatto avrà su tempi, costi, qualità e altri requisiti?

Flashcard

D: Che cos’è una baseline dei requisiti?
R: L’insieme di requisiti analizzati e approvati che diventa riferimento controllato per realizzazione, verifica e cambiamenti.

D: Qual è la differenza tra validazione e verifica?
R: La validazione controlla che si stia definendo la cosa giusta; la verifica controlla che la soluzione realizzi correttamente quanto specificato.

D: A cosa serve la tracciabilità?
R: A collegare bisogno, requisito, implementazione, test e decisioni di cambiamento.

Domanda in stile esame

Durante il test, gli utenti chiedono che il tempo di conferma dalla lista d’attesa passi da 30 a 10 minuti. Il PM dice al team di cambiare subito il parametro, perché è una richiesta piccola.

Qual è l’approccio corretto?

Risposta: prima va chiarito se la modifica altera un requisito o una configurazione già approvata e va valutato l’impatto. Anche una modifica piccola può incidere su esperienza utente, regole operative, test e comunicazione. Se cambia la baseline, si applica il processo di Change Management proporzionato al progetto.

Fonte

Requirements Management, Requirements Management Plan e i relativi log sono trattati nella PM² Methodology Guide 3.1 della Commissione europea.

Nel prossimo articolo: Scope e Change Management, per mantenere il perimetro sotto controllo senza impedire modifiche utili.