Template per la raccolta dei requisiti: 7 trucchi che uso nei progetti

Un template per la raccolta dei requisiti si guadagna il posto solo se costringe ad affrontare presto le conversazioni difficili: chi firma, chi può bloccare, che aspetto ha il successo e quanto deve essere veloce il sistema. Questa guida è per project manager, business analyst e responsabili SAP che hanno bisogno di un template che regga oltre il primo comitato direttivo. Qui sotto trova lo schema completo che uso, con un responsabile per ogni sezione, le cinque sezioni che non salto mai e sette trucchi per interviste, definizione delle priorità e cambiamento. Copi lo schema nel suo documento e lo compili prima che inizi il design.

Una volta ho visto implodere un progetto da sei cifre perché nessuno aveva fatto un vero lavoro sui requisiti. Il cliente si aspettava una cosa. Il team di sviluppo ne ha costruita un'altra. Tutti sono stati scaricati come capri espiatori, ed è allora che sono stato chiamato io.

Lo schema non è insolito. Il rapporto Pulse of the Profession 2014 del PMI sulla gestione dei requisiti ha rilevato che il 47% dei progetti non riusciti non ha raggiunto i propri obiettivi a causa di una cattiva gestione dei requisiti. L'ho visto accadere decine di volte.

Io stesso ho rischiato di ritrovarmi nella stessa situazione in un grande rollout di sistema. Gli stakeholder andavano in ogni direzione. Gli sviluppatori tiravano a indovinare. Ci siamo fermati, abbiamo messo insieme un template di requisiti come si deve e abbiamo consegnato ciò che serviva al business, nei tempi e nel budget.

L'azienda di un amico ha speso 350.000 dollari per un CRM su misura che nessuno usa. Le vendite avevano bisogno di una cosa, il marketing ne voleva un'altra e gli sviluppatori hanno costruito ciò che pensavano volessero tutti.

Un mio cliente del settore sanitario ha sprecato 18 mesi in un'implementazione di cartelle cliniche elettroniche (EMR) che i medici si rifiutavano di usare. Nessuno aveva chiesto loro di che cosa avessero bisogno nel lavoro quotidiano. Il progetto è stato abbandonato e ricominciato.

Scoprire tardi costa caro. Uno studio della NASA sull'escalation dei costi degli errori ha rilevato che correggere un errore di requisiti individuato in integrazione e test costava da 21 a 78 volte di più rispetto a uno individuato durante la fase dei requisiti. Se individuato in esercizio, il multiplo andava da 29 a oltre 1.500. In un programma enterprise è la differenza tra un workshop e una change request da centinaia di migliaia.

1. RequisitiIl costo base di correzioneIndividuato mentre i requisiti sono ancora in stesura
2. Integrazione e testDa 21 a 78 volte il costoIndividuato quando il sistema è costruito e in fase di test
3. EsercizioDa 29 a oltre 1,500 volte il costoIndividuato quando il sistema è già in produzione

Fonte: Studio della NASA sull'escalation dei costi degli errori

Dopo averlo imparato a mie spese, queste sono le cinque sezioni che nessun template di requisiti dovrebbe saltare.

1. Executive summary con un blocco firme

I dirigenti molto impegnati non leggeranno un documento di requisiti di 30 pagine. Una volta uno sponsor ha approvato un progetto senza capire che cosa stava firmando, per poi perdere le staffe quando ha visto il risultato. Lo tenga a una pagina: impatto sul business, tempistiche, risorse, beneficio atteso e un blocco firme sulla stessa pagina, in modo che chi approva non possa sostenere di essersi perso i dettagli critici.

2. Mappatura di ruoli e influenza

Un elenco di nomi non basta. Serve una mappa del potere: chi può affossare il progetto, chi va consultato, chi ha bisogno solo di aggiornamenti. In un lavoro precedente eravamo a sei mesi dall'inizio dello sviluppo quando è arrivato l'ufficio legale con requisiti che hanno imposto una riprogettazione. Nessuno aveva pensato di includerli. Mappi ogni reparto coinvolto, il suo rappresentante e la sua influenza.

3. Obiettivi di business, non requisiti tecnici

Quale problema stiamo risolvendo e come misureremo il successo? Un cliente manifatturiero ha implementato un software di inventario esattamente come da specifica, e questo ha rallentato del 20% le operazioni di magazzino. Il template dovrebbe costringere gli stakeholder a definire il successo per il business partendo da una baseline attuale, non da un elenco di funzionalità.

4. Requisiti funzionali che gli sviluppatori possano usare

Via il gergo. Ogni requisito deve essere specifico e verificabile. «Il sistema dovrebbe migliorare l'esperienza del cliente» è inutile. «Gli utenti devono poter gestire un reso ed emettere un rimborso in meno di 3 minuti» è un requisito. Se non può verificare che sia stato soddisfatto, lo riscriva.

5. Requisiti non funzionali

Prestazioni, sicurezza, conformità, disponibilità, scalabilità. È la sezione che quasi tutti saltano, e poi il sistema cede sotto carico o non supera un audit di sicurezza. Ho sentito parlare di un progetto retail in cui il sistema funzionava alla perfezione fino al Black Friday, quando è crollato sotto carico perché nessuno aveva specificato requisiti di prestazione. Scriva sotto forma di numeri i tempi di risposta, l'uptime, i picchi di utenti e gli obblighi di conformità.

Ecco lo schema completo. Le cinque sezioni qui sopra ne fanno parte, insieme ai registri che lo tengono in vita dopo la firma.

Sezione	Cosa contiene	Responsabile	Approvato da
1. Executive summary	Problema, impatto sul business, tempistiche, risorse, beneficio atteso. Una pagina con blocco firme	Sponsor, bozza a cura del BA lead	Sponsor e finanza
2. Ambito e baseline di deployment	Cosa è dentro e fuori ambito, vincoli. Per SAP: Public Edition, Private Edition o on-premise	Direttore del programma	Comitato direttivo
3. Mappa di ruoli e influenza	Reparti, rappresentanti, livello di influenza, consultare o informare	BA lead	Sponsor
4. Obiettivi di business	Ogni obiettivo con un KPI, la sua baseline attuale e un target	Responsabili di processo	Sponsor
5. Requisiti funzionali	ID (es. REQ-FUN-023), descrizione, origine, priorità, criteri di accettazione, decisione fit-to-standard	Responsabili funzionali	Responsabili di processo
6. Requisiti non funzionali	Prestazioni, sicurezza, conformità, disponibilità; per SAP, l'approccio alle estensioni per ogni gap	Solution architect	IT, sicurezza e conformità
7. Parking lot	Richieste rinviate, chi le ha avanzate, data della prossima revisione	BA lead	Nessuno finché non vengono promosse
8. Registro dei respinti	Cosa è stato respinto, perché, quando e da chi	BA lead	Sponsor
9. Registro delle modifiche	Ogni modifica dopo la firma con il relativo impatto su tempi e costi	PMO	Change board

1. Usare i Cinque perché nelle interviste agli stakeholder

Se chiede «di che cosa ha bisogno?», otterrà una lista dei desideri. Chieda invece del problema che fa male: «Che cosa le fa venire voglia di buttare il computer dalla finestra?» Poi chieda perché, e ancora perché, per cinque volte. Il vero requisito di solito è diverso dalla prima richiesta.

Uno stakeholder insisteva per avere funzionalità di reportistica complesse. Dopo aver ripercorso i suoi casi d'uso reali, gli servivano tre semplici dashboard.

2. Creare un parking lot dei requisiti

Buona parte di ciò che gli stakeholder chiedono non verrà mai usata. Quando qualcuno insiste su qualcosa di discutibile, non discuto. Lo metto nel parking lot e invio un promemoria mensile per chiedere se debba passare ai requisiti attivi. La maggior parte resta parcheggiata per sempre.

3. Applicare la regola del tre agli stakeholder che cambiano continuamente idea

Possono cambiare direzione due volte senza conseguenze. Al terzo cambio, scrivono al loro capo per spiegare il cambiamento e il suo impatto. Nessuno vuole mandare quell'email. I cambi si fermano.

4. Usare la tecnica dell'allocazione dei fondi per forzare le priorità

Dia a ogni stakeholder 100 dollari virtuali da spendere su tutti i requisiti. Non possono avere tutto, quindi mettono i soldi dove conta. L'ho fatto con un cliente di servizi finanziari che aveva più di 200 requisiti «critici». In un'ora avevamo i veri 20 principali.

5. Numerare ogni requisito

Usi un formato coerente come REQ-FUN-023. Mette fine alla confusione del «di quale requisito stiamo parlando?» che fa sprecare tempo nelle riunioni. Registri l'origine, chi lo ha chiesto e perché, così saprà chi chiamare quando bisognerà tagliare delle voci.

6. Riproporre i requisiti nel linguaggio dello stakeholder

Dopo averli documentati, rilegga i requisiti agli stakeholder con le loro stesse parole. Costruisca un prototipo o un wireframe veloce per tutto ciò che è complesso prima che parta lo sviluppo. Gli equivoci emergono quando correggerli costa ancora poco.

7. Documentare ciò che è stato respinto

Qualcuno riproporrà un requisito respinto al quinto mese. «Ne abbiamo discusso ad aprile, ed ecco perché abbiamo deciso contro» chiude la conversazione in fretta. Senza il registro, la discussione si rifà da capo.

I sette trucchi funzionano su qualsiasi progetto. I programmi SAP richiedono tre elementi in più nel template.

Il modello di deployment entra nella baseline

Registri il modello di deployment prima di raccogliere i requisiti funzionali: S/4HANA Cloud Public Edition (tramite GROW with SAP, o RISE), Private Edition (di solito tramite RISE) oppure on-premise. Determina che cosa è possibile. La Public Edition non consente alcuna modifica del core, quindi i requisiti che dipendono da processi non standard vanno rimodellati o respinti. La Private Edition e l'on-premise consentono di più, al prezzo di un maggiore impegno negli upgrade.

Se raccoglie i requisiti prima di questa decisione, ne riscriverà molti quando arriverà.

Una decisione sull'estensione per ogni gap

L'approccio Clean Core di SAP prevede che ogni gap abbia una decisione registrata: configurarlo, estenderlo con API rilasciate (on-stack con ABAP Cloud o side-by-side su SAP BTP) oppure respingerlo. Sulla Public Edition lo impone il prodotto. Sulla Private Edition e on-premise è un'indicazione forte di SAP, e ogni modifica che consente diventa lavoro di upgrade più avanti. Inserisca la decisione nella sezione 6 del template, accanto a prestazioni e sicurezza, e dia a un solo architetto l'autorità di approvarla. La mia guida al Clean Core spiega i livelli.

L'AI redige, le persone decidono

L'AI ormai aiuta con le carte. SAP Cloud ALM offre una funzione di generazione dei requisiti che, a partire dalle trascrizioni dei workshop fit-to-standard, redige i requisiti in un template, a pagamento tramite AI unit. Assistenti generali come Microsoft Copilot redigono riepiloghi e verbali a partire dagli appunti delle riunioni.

Gli strumenti di stesura con l'AI fanno risparmiare tempo reale sulla parte documentale quando il materiale di partenza è pulito. Non cambiano l'intervista. È ancora una persona a porre i Cinque perché. E nessuno strumento costringe il responsabile di un reparto a firmare l'executive summary. Validazione, definizione delle priorità e approvazione restano lavoro umano.

Sviluppo software. Aggiunga vincoli tecnici, punti di integrazione, flussi utente (i passaggi effettivi che gli utenti compiono, non solo le funzionalità) e criteri di accettazione pass/fail. Lo abbiamo mancato in un progetto di portale clienti e abbiamo passato tre mesi a discutere se le funzionalità «funzionassero bene».

Miglioramento dei processi. Mappi lo stato attuale con tutti i workaround disordinati di cui nelle riunioni nessuno parla, valuti l'impatto per ruolo e raccolga baseline di prestazioni concrete. Un cliente manifatturiero ha rivoluzionato il proprio processo di magazzino senza baseline. Sei mesi dopo non riusciva a dimostrare il miglioramento né a giustificare la spesa.

Selezione del fornitore. Separi gli elementi imprescindibili da quelli desiderabili, pesi i criteri di punteggio ed espliciti nei minimi dettagli le aspettative su supporto e implementazione. Ho visto un'azienda scegliere un fornitore quasi solo in base alle funzionalità e alle impressioni della demo. Ha ignorato i requisiti di supporto ed è finita con un sistema che non poteva implementare senza forti costi aggiuntivi di consulenza.

Per i progetti più piccoli: Trello per far avanzare i requisiti attraverso le fasi di approvazione, Google Docs con i commenti per la revisione e Miro per la mappatura dei processi nei workshop.

Per i programmi enterprise: Jira con un add-on di gestione dei requisiti, Confluence per i documenti vivi (le sue funzionalità di AI ora rientrano nel marchio Rovo di Atlassian) e Modern Requirements se si usa Azure DevOps. Nei programmi SAP, SAP Cloud ALM raccoglie in un unico posto requisiti, user story e casi di test, collegati alla roadmap di SAP Activate.

Lo strumento conta meno del collegamento. Colleghi i requisiti al piano di progetto e ai casi di test e invii notifiche automatiche quando un requisito cambia. «Non sapevo che fosse cambiato» uccide più progetti degli strumenti scadenti. Una volta firmati i requisiti, la mia guida per evitare lo scope creep nelle implementazioni SAP spiega come mantenerli tali, e i quality gate SAP mostrano dove si colloca l'approvazione dei requisiti nel ciclo di governance.

Un template che nessuno apre dopo la firma è teatro. Quelli che funzionano sono brevi, assegnati sezione per sezione e aggiornati ogni volta che qualcuno cambia idea, il che, in qualsiasi programma che valga la pena di fare, succede ogni settimana.

Quali sono le 5 fasi della raccolta dei requisiti?

1. Elicitazione: raccolta di informazioni tramite interviste, workshop e osservazione
2. Analisi: organizzazione, definizione delle priorità e risoluzione dei conflitti tra requisiti
3. Documentazione: stesura della specifica (BRD, FRD o user story, a seconda del metodo)
4. Validazione: conferma che i requisiti riflettano esigenze reali e siano verificabili
5. Gestione: tracciamento delle modifiche per tutta la durata del progetto

Ogni fase si appoggia su quella precedente. Mettere fretta all'elicitazione, come fa la maggior parte dei team, crea problemi in ogni fase successiva.

Qual è la differenza tra BRD e FRD?

Un Business Requirements Document (BRD) copre le esigenze di business: contesto, obiettivi, stakeholder, vincoli e requisiti di alto livello. Risponde alla domanda «di che cosa ha bisogno il business?»

Un Functional Requirements Document (FRD) copre come si comporterà il sistema: user story, comportamento del sistema, interfacce e criteri di accettazione. Risponde alla domanda «che cosa deve fare il sistema?»

Parto sempre dal BRD per ottenere l'allineamento del business prima dell'FRD. I team che passano direttamente all'FRD spesso costruiscono un sistema tecnicamente corretto che risolve il problema sbagliato.

Quali sono i 3 tipi di requisiti?

1. Requisiti di business: perché esiste il progetto, i suoi obiettivi e le misure di successo
2. Requisiti funzionali: che cosa deve fare il sistema
3. Requisiti non funzionali: con quale qualità deve farlo (prestazioni, sicurezza, scalabilità, conformità)

La maggior parte dei fallimenti di progetto che ho visto risale a requisiti non funzionali mancanti. Il sistema fa ciò che era stato chiesto, poi cede sotto un carico reale o non supera un audit di conformità.

Come cambia la raccolta dei requisiti in base al modello di deployment SAP?

Lo si registri per primo. S/4HANA Cloud Public Edition non consente alcuna modifica del core, quindi i requisiti basati su processi non standard vanno rimodellati o respinti. La Private Edition e l'on-premise offrono più flessibilità, ma ogni modifica aggiunge lavoro di upgrade.

Se raccoglie i requisiti funzionali prima della decisione, ne rielaborerà molti. Aggiunga una decisione sull'estensione registrata (configurare, estendere tramite API rilasciate o respingere) per ogni gap.

Che cosa rende verificabile un requisito?

Una condizione di superamento o fallimento chiara e misurabile. «Il sistema dovrebbe essere veloce» non è verificabile. «I risultati di ricerca devono tornare in meno di 2 secondi per il 95% delle query a carico standard» lo è.

Il mio test: riesce a scrivere subito il caso di test, con criteri chiari di pass/fail? Se no, riscriva il requisito. I requisiti non verificabili causano più contese al go-live di qualsiasi altra cosa che io veda.

Come si evita che i requisiti cambino in continuazione?

1. Change control: ogni modifica dopo la firma documenta il proprio impatto su tempi, budget e risorse prima che qualcuno la approvi. Si renda visibile il costo del cambiamento.
2. Parking lot: le nuove richieste vanno nel parking lot, non direttamente nell'ambito. Revisione mensile. La maggior parte delle richieste che sembrano urgenti non sopravvive all'attesa.
3. Quality gate: si definisca che cosa significa «requisiti completi» e non si avvii il design finché non è soddisfatto.

Nei programmi SAP, la decisione sull'estensione aggiunge un controllo tecnico: una richiesta che richiede una modifica del core deve ottenere il via libera dell'architetto prima di poter essere approvata.