Raccolta dei requisiti: quali tecniche scegliere e come combinarle

Le migliori tecniche di raccolta dei requisiti sono quelle che rispondono a ciò che ancora non sai. Usa le interviste per capire di cosa hanno bisogno le singole persone. Usa i workshop per risolvere i conflitti tra loro. Usa l’osservazione e l’analisi dei documenti per vedere come si lavora davvero, e usa i prototipi per mettere alla prova le idee prima di costruirle. Nessun metodo basta da solo, perciò la maggior parte dei progetti software ne combina tre o quattro. Questa guida spiega cosa rivela ogni tecnica, come scegliere una combinazione e come trasformare i risultati in requisiti che uno sviluppatore può realizzare e uno stakeholder può approvare.

In breve

• La raccolta è il lavoro completo: identificare, documentare, analizzare, validare e far approvare i bisogni. L’elicitazione è la parte attiva, quella in cui tiri fuori i bisogni dalle persone.
• Interviste e workshop esprimono i bisogni. Osservazione e analisi dei documenti mostrano come si lavora oggi. I prototipi mostrano cosa potrebbe essere.
• Parti da obiettivi, contesto e stakeholder, e solo dopo raccogli i requisiti di dettaglio.
• Rendi misurabili i requisiti di qualità, così «veloce» diventa un numero che qualcuno può verificare.
• I requisiti che nessuno ha validato non servono a nulla: chiudi ogni ciclo con una revisione.

Cosa significa raccolta dei requisiti (e in cosa si distingue dall’elicitazione)

La raccolta dei requisiti è il processo ampio che consiste nel identifying, documenting and organizing what a system needs to do. Comprende l’individuazione degli stakeholder, l’elicitazione dei bisogni, la loro analisi, la validazione e l’approvazione finale. L’elicitazione è il sottoinsieme attivo: far emergere bisogni, aspettative e vincoli da utenti, ingegneri, autorità di regolamentazione ed esperti di dominio.

Sul vocabolario si discute. L’esperto di requisiti Robin Goldsmith sostiene che «raccogliere» ed «elicitare» siano termini fuorvianti, perché i requisiti non se ne stanno lì belli e pronti. Lui preferisce talk about discovering requirements analizzando i dati. Karl Wiegers e Candase Hokanson fanno un ragionamento simile: un buon analista tratta l’elicitazione as exploration and discovery, not just collection.

La lezione pratica è che nessuno ti consegnerà una lista già pronta. Un fondatore dice «ci serve un’app con una dashboard». Quello di cui l’azienda ha bisogno, di solito, è qualcos’altro che sta sotto: meno report manuali, onboarding più rapido, meno ticket di supporto. Le tue tecniche servono proprio a passare dalla prima affermazione alla seconda.

Prima di ogni tecnica: obiettivi, contesto e stakeholder

La ricerca del gruppo di requirements engineering dell’Università di Zurigo è chiara sull’ordine del lavoro. Prima di elicitare i dettagli, occorre clarify the system’s goals and vision, consider its context, and identify stakeholder roles and their representatives. Saltare questo passaggio è il motivo più comune per cui il primo workshop di un progetto produce una lista dei desideri lunga e senza fuoco.

Tre cose da fare per prime:

1. Scrivi l’obiettivo in una o due frasi. Per esempio: «Ridurre da 40 a 10 minuti il tempo che il team vendite impiega per creare un’offerta.» Se non ci riesci, ecco il tema del tuo primo workshop.
2. Mappa il contesto. Quali sistemi, team, fornitori, leggi e processi esistenti toccano il prodotto? Un negozio collegato a un ERP e a un fornitore di pagamenti ha requisiti che vivono fuori dal negozio.
3. Elenca i ruoli degli stakeholder, poi assegna a ciascuno una persona in carne e ossa. Pensa a utenti, acquirenti, personale operativo, finanza, IT e ufficio legale. Dove non riesci a raggiungere una persona reale, lo stesso materiale di Zurigo suggerisce di usare clarify the system’s goals and vision, consider its context, and identify stakeholder roles and their representatives.

Se sei nuovo in un’organizzazione, comincia leggendo. La documentazione dei sistemi esistenti e gli organigrammi sono un foundational way to understand business objectives prima di occupare il tempo di qualcuno.

Le principali tecniche di raccolta dei requisiti

Una rassegna sistematica degli studi sull’elicitazione ha rilevato che ogni tecnica rivela cose diverse: interviews clarify individual needs and motivations, while observation highlights real-world workflows. Il materiale del corso di Zurigo lo riassume in modo compatto: clarify the system’s goals and vision, consider its context, and identify stakeholder roles and their representatives. Ecco come funziona nella pratica.

Interviste

Il colloquio uno a uno è il cavallo di battaglia. Si adatta a chi non parla liberamente in gruppo: il responsabile finanziario che conosce il vero problema del reporting, il responsabile operativo che aggira uno strumento mal funzionante.

• Rivela: bisogni individuali, motivazioni, linguaggio, vincoli nascosti.
• Usala quando: hai pochi stakeholder, temi delicati o ti serve profondità.
• Consigli: chiedi dell’ultima volta che qualcosa è andato storto, non di cosa «vorrebbero». Chiedi «perché» finché non arrivi a una ragione di business. Resta entro i 45 minuti e invia poi un riepilogo scritto.

Workshop

Un workshop mette più stakeholder in una stanza (o in una videochiamata) con un’agenda chiara. È il modo più rapido per far emergere i conflitti e risolverli.

• Rivela: disaccordi tra reparti, priorità, linguaggio condiviso.
• Usalo quando: più gruppi dipendono dallo stesso prodotto, oppure ti servono decisioni e non solo informazioni.
• Consigli: invita chi può decidere, non solo chi sa. Chiudi con una lista ordinata per priorità, non aperta. Da cinque a otto persone è un numero gestibile.

Osservazione e affiancamento sul lavoro

Guardare le persone mentre lavorano mostra ciò che le interviste si perdono, perché le persone descrivono il processo ufficiale e poi fanno qualcosa di diverso. Un addetto al magazzino può tenere un foglio di calcolo accanto al sistema ufficiale. Quel foglio di calcolo è un requisito.

• Rivela: flussi di lavoro reali, soluzioni di ripiego, interruzioni, strumenti usati in parallelo.
• Usala quando: stai sostituendo o automatizzando un processo esistente.
• Consigli: dedica mezza giornata per ogni ruolo, prendi nota di ciò che le persone fanno più che di ciò che dicono, e chiedi poi spiegazioni su ogni soluzione di ripiego.

Analisi dei documenti

Manuali esistenti, descrizioni di processo, contratti, ticket di supporto, dati analitici e vecchie specifiche ti dicono cosa l’organizzazione già sa. Inoltre costano poco da leggere e non tolgono tempo a nessuno.

• Rivela: regole attuali, campi dati, integrazioni, problemi ricorrenti.
• Usala quando: all’inizio di ogni progetto, e soprattutto quando migri un sistema legacy.
• Consigli: tratta i documenti come affermazioni da verificare. La vecchia documentazione è spesso superata, quindi confrontala con l’osservazione.

Sondaggi e questionari

I sondaggi raggiungono molte persone a basso costo. Funzionano per confermare qualcosa che già sospetti, per esempio quale fra cinque funzionalità i clienti apprezzano di più. Funzionano male per scoprire cose a cui nessuno ha pensato.

• Rivela: schemi ricorrenti in un ampio gruppo di utenti.
• Usali quando: hai molti utenti e una domanda precisa.
• Consigli: resta sotto le dieci domande e fai prima qualche intervista, così le domande saranno quelle giuste.

Brainstorming

Il brainstorming genera opzioni in fretta. Si adatta ai prodotti in fase iniziale, dove il problema è chiaro ma la soluzione no. Il suo risultato sono idee grezze, non requisiti, quindi fai seguire una fase di definizione delle priorità.

• Rivela: possibili soluzioni e idee che gli stakeholder non avevano espresso.
• Usalo quando: sei alla fase dell’idea oppure un workshop si è arenato.
• Consigli: separa la generazione delle idee dal loro giudizio, poi valuta le idee rispetto all’obiettivo che hai messo per iscritto.

Prototipazione

Un mock-up cliccabile o una versione funzionante grezza permette alle persone di reagire a qualcosa di concreto. Spesso gli stakeholder non sanno dire di cosa hanno bisogno, ma capiscono subito cosa non va in una schermata.

• Rivela: problemi di usabilità, passaggi mancanti, aspettative non dichiarate.
• Usala quando: l’interfaccia è centrale, gli utenti non hanno familiarità con l’idea, oppure gli stakeholder non concordano su come «dovrebbe» essere.
• Consigli: fai i test con utenti reali, non solo con il committente del progetto. Butta via le ipotesi del prototipo, non solo i suoi pixel.

User story e casi d’uso

Le user story («Come venditore, voglio duplicare un’offerta passata per poterne inviare una nuova in pochi minuti») e i casi d’uso o scenari trasformano i risultati in una forma da cui un team può partire a costruire. Il materiale di Zurigo elenca scenarios and use cases, glossaries, process models and object models tra le tecniche di analisi che danno forma a informazioni non strutturate trasformandole in requisiti veri e propri.

• Rivela: lacune nei flussi, casi limite e quali passaggi contano di più per gli utenti.
• Usali quando: dopo l’elicitazione, per strutturare quello che hai ascoltato.
• Consigli: associa criteri di accettazione a ogni story, così team e cliente concordano sul significato di «fatto».

Come scegliere e combinare le tecniche

L’International Requirements Engineering Board afferma che there is no universal requirements process: va adattato al contesto di sviluppo, al tipo di progetto (lineare o agile) e alla disponibilità degli stakeholder. Scegli quindi partendo da tre domande.

1. Cosa non sai ancora?

Incognita	Tecniche migliori
Quale problema conta di più	Interviste, analisi dei documenti
Come si lavora oggi	Osservazione, analisi dei documenti
Chi vuole cosa, e dove sono in conflitto	Workshop
Che aspetto deve avere la soluzione	Prototipazione, brainstorming
Quanto è diffuso un bisogno	Sondaggi
Cosa deve costruire il team come prossima cosa	User story con criteri di accettazione

2. Chi riesci a raggiungere e quanto tempo hai a disposizione da parte loro? Per cinque dirigenti impegnati funzionano meglio interviste brevi e un workshop decisionale che una serie di riunioni lunghe. Centinaia di utenti finali richiedono un sondaggio sostenuto da una manciata di interviste.

3. Quanto costa sbagliare previsione? Un sito di marketing si può correggere dopo il lancio. Un flusso di pagamento, un sistema che dialoga con un ERP o un processo regolamentato no, quindi lì vale la pena dedicare più tempo a osservazione e prototipazione.

Tre combinazioni che funzionano

• Nuovo prodotto o MVP: interviste agli stakeholder, un workshop per definire gli obiettivi, un prototipo cliccabile testato con cinque utenti target, poi le user story. Così la prima release resta piccola e fondata su dati concreti.
• Sostituzione di un sistema legacy: analisi dei documenti, osservazione di ogni ruolo utente, interviste sulle soluzioni di ripiego, poi un workshop per decidere quali vecchi comportamenti mantenere. I vecchi sistemi nascondono regole di business che nessuno ricorda di aver scritto.
• Automazione di un processo ripetitivo: osservazione del processo dall’inizio alla fine, un breve workshop per concordare le eccezioni e un prototipo del flusso automatizzato provato su un campione di casi reali.

In ogni caso, combina una tecnica che raccoglie ciò che le persone dicono con una che verifica ciò che fanno.

Requisiti di qualità: quelli che tutti dimenticano

Gli stakeholder parlano di funzionalità. Raramente menzionano velocità, sicurezza, disponibilità o facilità d’uso, finché qualcosa non si rompe. La ricerca di Zurigo elenca i requisiti di qualità e i vincoli trascurati tra i problemi più comuni e consiglia di clarify the system’s goals and vision, consider its context, and identify stakeholder roles and their representatives.

Le affermazioni vaghe hanno bisogno di numeri. Un requisito come «il sistema deve essere veloce» è, secondo la stessa fonte, clarify the system’s goals and vision, consider its context, and identify stakeholder roles and their representatives. Per esempio:

• Invece di «veloce»: «I risultati della ricerca compaiono entro due secondi nel 95 percento delle richieste.»
• Invece di «sicuro»: «Il personale accede con autenticazione a due fattori e i dati dei clienti sono archiviati in Svizzera.»
• Invece di «facile da usare»: «Un nuovo collaboratore crea un’offerta senza formazione in meno di dieci minuti.»

Fai le domande in modo diretto: quanti utenti contemporaneamente? Cosa succede se il sistema resta fermo per un’ora? Quali dati sono personali? Ricercatori dell’Università di Zurigo e della FHNW avvertono inoltre che quality models must be tailored to the project’s context per funzionare come schemi di elicitazione, quindi usa le checklist come spunti, non come copioni.

Problemi frequenti e come affrontarli

Lo stesso materiale di Zurigo nomina i problemi che incontrerai: clarify the system’s goals and vision, consider its context, and identify stakeholder roles and their representatives. Ecco alcune risposte pratiche.

• Due reparti vogliono cose opposte. Non risolverlo via e-mail. Mettili entrambi in un workshop con chi è responsabile dell’obiettivo, e decidete in base all’obiettivo scritto.
• Uno stakeholder dice «fate e basta X». Chiedi cosa succede oggi senza X e cosa cambia con X. Spesso le persone descrivono una soluzione quando intendono un problema.
• Nessuno sa di cosa ha bisogno. Mostra loro qualcosa. Un prototipo grezzo o un prodotto simile sbloccano spesso più di un’altra riunione.
• Le parole hanno significati diversi. Tieni un glossario. «Cliente» per le vendite può essere un acquirente, per gli sviluppatori un account utente.
• Una persona chiave non è disponibile. Nomina un delegato con potere decisionale, oppure usa una persona fittizia e segnala l’ipotesi per verificarla più avanti.
• Lo scope continua a crescere. Classifica i requisiti (indispensabile, auspicabile, facoltativo) a ogni workshop e registra chi ha richiesto ogni voce e perché.

Documentare, validare e tenere aggiornati i requisiti

Scrivi i requisiti nella forma di cui ha bisogno chi legge. Un documento dei requisiti di business descrive gli obiettivi di alto livello. Una specifica dei requisiti di sistema, in tedesco chiamata Pflichtenheft in German, descrive cosa farà il sistema. I clienti svizzeri conoscono spesso il termine tedesco, e vale la pena chiedere se in un bando o in un contratto ci si aspetta un Pflichtenheft.

Un minimo praticabile per un progetto piccolo:

1. Obiettivo e indicatori di successo.
2. Ruoli degli stakeholder e chi decide.
3. User story o casi d’uso, ordinati per priorità, ciascuno con criteri di accettazione.
4. Requisiti di qualità con numeri.
5. Integrazioni, dati e vincoli come budget, scadenze e norme di legge.
6. Domande aperte e ipotesi, con un responsabile per ciascuna.

Poi valida. Il manuale IREB è netto: there is no universal requirements process. La validazione può essere una revisione guidata con gli stakeholder, una revisione del prototipo o casi di test scritti a partire dai criteri di accettazione prima dell’inizio dello sviluppo. L’approvazione deve significare che persone con potere decisionale hanno letto il documento e concordano che corrisponde ai loro bisogni.

Se lavori in un settore regolamentato come i dispositivi medici o l’automotive, aspettati di più. I settori regolamentati richiedono spesso identifying, documenting and organizing what a system needs to do secondo standard come FDA 21 CFR 820.30 o ISO 26262. Chiedi al tuo referente per la conformità quali standard si applicano prima di scegliere un formato di documentazione.

Infine, tieni vivo il documento. La ricerca dell’Università di Zurigo mostra che up-to-date requirements specifications prevent the loss of the rationale behind past decisions e rendono più semplici le discussioni successive sulle funzionalità. Quando una decisione cambia, annota accanto il motivo.

Un processo passo passo da avviare questa settimana

1. Definisci per iscritto l’obiettivo e gli indicatori di successo e falli confermare dal committente.
2. Elenca stakeholder e contesto: ruoli, sistemi, regole, documenti esistenti.
3. Prima leggi: documenti, ticket, dati analitici, organigrammi.
4. Intervista una persona per ogni ruolo, su situazioni reali e recenti.
5. Osserva i due o tre flussi di lavoro più importanti.
6. Organizza un workshop per risolvere i conflitti e ordinare le priorità.
7. Prototipa la parte più rischiosa e testala con utenti reali.
8. Scrivi le story con criteri di accettazione e requisiti di qualità misurabili.
9. Valida e fai approvare, poi programma una revisione ogni volta che lo scope cambia.

Per un prodotto piccolo, i passi da 1 a 8 rientrano spesso in due o tre settimane di impegno a tempo parziale da parte del cliente. Più stakeholder e integrazioni ci sono, più tempo serve, e quel tempo costa meno che riscrivere il software in seguito.

Requisiti fatti bene, con un team senior

Il lavoro sui requisiti è il punto in cui i progetti si vincono o si perdono, e dipende da chi siede al tavolo. Da Ampersand, piccolo studio di Zurigo, gli ingegneri senior partecipano dalla prima consulenza fino alla consegna. L’obiettivo è che le persone che hanno ascoltato i tuoi bisogni siano le stesse che costruiscono la soluzione, così i requisiti non si perdono né vengono riscritti a metà strada. Se stai pianificando un sito web, un’app, una piattaforma, un’integrazione o una migrazione, puoi vedere come organizziamo il nostro lavoro nella nostra pagina su prezzi e servizi, oppure iniziare una conversazione tramite ampersand.ch.

Domande frequenti

Qual è la differenza tra raccolta ed elicitazione dei requisiti?

La raccolta è l’intero processo: identificare gli stakeholder, elicitare, documentare, analizzare, validare e far approvare. L’elicitazione è la parte attiva al suo interno, quella in cui fai emergere bisogni e vincoli da utenti, esperti e altri stakeholder. Nella pratica i due termini vengono spesso usati come sinonimi.

Qual è la tecnica migliore per raccogliere i requisiti?

Nessuna è la migliore da sola. Le interviste danno profondità, i workshop risolvono i conflitti, l’osservazione mostra i flussi di lavoro reali e i prototipi mettono alla prova le idee. Scegli il mix in base a ciò che non sai ancora, a chi riesci a raggiungere e a quanto costerebbe un’ipotesi sbagliata.

Come si raccolgono i requisiti per un progetto software?

Parti dall’obiettivo, dal contesto e dagli stakeholder. Poi combina lettura, interviste, osservazione e un workshop sulle priorità, e verifica le parti rischiose con un prototipo. Scrivi le story con criteri di accettazione e requisiti di qualità misurabili, e falle validare dalle persone con potere decisionale.

Quali tecniche si usano nell’analisi dei requisiti?

L’analisi dà forma a ciò che hai raccolto trasformandolo in requisiti chiari. Tra gli strumenti più comuni ci sono glossari, scenari e casi d’uso, modelli di processo o di attività, modelli di comportamento, modelli a oggetti o a classi e strutture gerarchiche di obiettivi e funzionalità.

Come gestire gli stakeholder che non sanno dire di cosa hanno bisogno?

Mostra loro qualcosa di concreto, per esempio un prototipo, una schermata di un prodotto simile o un report di esempio. Osserva come lavorano invece di chiedere soltanto cosa vogliono. Dove non è disponibile una persona reale, usa una persona fittizia e segnala che si tratta di un’ipotesi da verificare.

Fonti

• identifying, documenting and organizing what a system needs to do
• talk about discovering requirements
• as exploration and discovery, not just collection
• interviews clarify individual needs and motivations, while observation highlights real-world workflows
• clarify the system’s goals and vision, consider its context, and identify stakeholder roles and their representatives
• scenarios and use cases, glossaries, process models and object models
• Pflichtenheft in German
• quality models must be tailored to the project’s context
• up-to-date requirements specifications prevent the loss of the rationale behind past decisions
• there is no universal requirements process
• foundational way to understand business objectives