Il processo di raccolta e analisi dei requisiti è un'identificazione sistematica, organizzazione e documentazione delle esigenze aziendali del cliente per la loro successiva implementazione nei sistemi IT o nei processi aziendali. Le fasi principali:
Identificazione delle fonti dei requisiti: interviste con i clienti, gruppi di lavoro, analisi della documentazione e dei processi attuali.
Raccolta dei requisiti: utilizzo di sessioni tecniche (workshop), questionari, osservazioni, prototipazione. È importante garantire il coinvolgimento di tutti gli stakeholder.
Analisi e categorizzazione: identificazione di contraddizioni, attività duplicate, classificazione dei requisiti in aziendali/funzionali/non funzionali.
Documentazione: formalizzazione sotto forma di SRS (Specification Requirement Specification), user stories o scenari.
Validazione e approvazione: conduzione di revisioni con il cliente, apportare correzioni, approvazione della versione finale dei requisiti.
Caratteristiche chiave:
Profonda comprensione dei processi aziendali è necessaria per l'interpretazione corretta delle esigenze del cliente.
Comunicazione costante: la raccolta dei requisiti è un processo iterativo, soggetto a cambiamenti durante il progetto.
Artefatti dei requisiti (diagrammi, modelli, specifiche) sono cruciali per il lavoro futuro del team.
È possibile limitarsi a un solo tipo (ad esempio, aziendale o funzionale) di requisiti?
No, l'analista aziendale deve coprire tutti i tipi di requisiti: aziendali, utente, funzionali e non funzionali. Altrimenti, si rischia di ottenere un prodotto che non soddisfa le aspettative di tutti gli stakeholder.
È sempre sufficiente condurre solo una sessione di raccolta dei requisiti?
No, nella pratica ci sono molti requisiti, che vengono precisati gradualmente, in modo iterativo. Di solito si svolgono più sessioni per raccogliere e approvare il tutto correttamente.
È possibile modificare i requisiti approvati senza procedure formali?
No, qualsiasi modifica deve seguire il processo di change management, altrimenti verrà il caos, disallineamenti e incomprensioni tra i team.
Durante lo sviluppo di un modulo analitico per una banca, all'inizio è stato condotto solo un workshop. In seguito si è scoperto che le funzionalità non consideravano i requisiti del servizio di sicurezza delle informazioni, ed è stato necessario rielaborare significativamente il prodotto, spendendo tempo e budget.