Requirements engineering: perché l’analisi funzionale incide su costi e qualità
Nei progetti software enterprise, una parte significativa della complessità non nasce necessariamente dalla tecnologia utilizzata, ma dalla difficoltà di tradurre un’esigenza di business in un comportamento applicativo sufficientemente chiaro da poter essere progettato, sviluppato, testato e successivamente evoluto senza introdurre interpretazioni divergenti tra stakeholder, analisti e team tecnici.
È in questo spazio che si colloca l’analisi funzionale.
Il suo obiettivo non consiste nel definire nel dettaglio come il software debba essere implementato, ma nel descrivere in modo strutturato che cosa il sistema deve fare, quali processi deve supportare, quali informazioni deve utilizzare e come deve comportarsi nei principali scenari operativi.
Nel contesto più ampio della requirements engineering, questa attività permette di trasformare obiettivi, processi e aspettative spesso espresse inizialmente in forma non tecnica in requisiti sufficientemente precisi da diventare una base condivisa per le successive decisioni progettuali.
La rilevanza del tema rimane attuale anche nel 2026. Lo standard ISO/IEC/IEEE 29148 continua a rappresentare uno dei principali riferimenti internazionali per i processi di requirements engineering, definendo requisiti e information item lungo l’intero ciclo di vita di sistemi e prodotti software; nel luglio 2026 è inoltre entrata nella fase DIS la terza edizione dello standard, segnale di un ulteriore aggiornamento della disciplina rispetto all’evoluzione dei modelli di sviluppo contemporanei.
Per Tech Leader, Business Analyst, Product Owner e partner IT, quindi, l’analisi funzionale può essere letta meno come produzione documentale e più come meccanismo di riduzione dell’incertezza progettuale.
Requirements engineering: trasformare un’esigenza in un comportamento verificabile
Una richiesta iniziale raramente contiene già tutte le informazioni necessarie per sviluppare una soluzione.
“Digitalizzare il processo di approvazione”, “automatizzare gli ordini”, “creare una piattaforma per i clienti” o “integrare due sistemi” descrivono una direzione, ma non definiscono ancora un requisito implementabile.
Tra l’obiettivo di business e il codice esiste un livello intermedio che deve chiarire quali attori siano coinvolti, quali eventi avviino il processo, quali dati vengano utilizzati, quali regole condizionino il comportamento del sistema e quali risultati debbano essere prodotti.
L’analisi funzionale contribuisce a costruire questo livello.
Un requisito relativo a una procedura di approvazione, per esempio, può richiedere di stabilire chi possa avviare una richiesta, quali campi siano obbligatori, quali livelli autorizzativi dipendano dall’importo, cosa accada in caso di rifiuto, se una richiesta possa essere modificata dopo l’invio e quali notifiche debbano essere generate.
La differenza tra una richiesta generica e una specifica funzionale consiste quindi principalmente nel livello di ambiguità residua.
Un requisito utile allo sviluppo dovrebbe poter essere interpretato in modo sufficientemente simile da business, developer e tester.
Ambiguità dei requisiti: uno dei principali generatori di rework
Il rework si verifica quando una funzionalità già progettata o sviluppata deve essere modificata perché il risultato non corrisponde alle esigenze reali, perché sono emersi vincoli non considerati o perché stakeholder differenti avevano attribuito significati diversi allo stesso requisito.
Non tutto il rework è evitabile.
Nei progetti iterativi è fisiologico che nuove informazioni portino a modificare una soluzione e, in molti casi, questa capacità di adattamento rappresenta precisamente uno dei vantaggi dei modelli Agile.
Esiste tuttavia una differenza tra rework generato dall’apprendimento e rework generato dall’ambiguità.
Nel primo caso il progetto cambia perché è stata acquisita nuova conoscenza. Nel secondo, la modifica sarebbe potuta emergere prima attraverso una migliore condivisione del requisito.
L’analisi funzionale può ridurre soprattutto questa seconda categoria.
Il rapporto tra qualità dei requisiti e riduzione del rework è riconosciuto anche nei framework contemporanei di quality engineering. Il progetto IEEE P25000-70, dedicato al Quality Engineering Framework, identifica esplicitamente tra gli obiettivi della disciplina la riduzione del rework e dei costi di sviluppo attraverso pratiche applicate lungo l’intero software lifecycle.
Functional requirements e quality requirements devono rimanere distinti ma collegati
L’analisi funzionale descrive principalmente il comportamento richiesto al sistema, ma nei progetti enterprise deve essere collegata ai requisiti non funzionali e di qualità.
Un sistema può infatti implementare correttamente tutte le funzioni previste e risultare comunque inadeguato rispetto alle esigenze operative.
Un processo di autenticazione può funzionare correttamente ma avere una latenza non accettabile; una ricerca può restituire il risultato previsto ma non sostenere il volume di traffico reale; una piattaforma può elaborare correttamente dati personali senza rispettare le policy di accesso richieste.
Per questo functional requirements e quality requirements dovrebbero essere trattati come dimensioni complementari.
Lo standard ISO/IEC 25030, confermato come corrente nel 2025, definisce un framework specifico per l’elicitazione, la definizione, l’utilizzo e la governance dei requisiti di qualità di sistemi, software e dati.
La separazione resta utile perché evita di confondere cosa debba fare il sistema con le condizioni qualitative entro cui quella funzione deve operare.
Business process analysis: comprendere il processo prima di automatizzarlo
Una parte importante dell’analisi funzionale riguarda la comprensione del processo esistente.
Digitalizzare un’attività non significa necessariamente replicarne in software ogni passaggio.
Un processo può contenere controlli nati per compensare limitazioni di strumenti precedenti, duplicazioni manuali, passaggi informativi non più necessari o responsabilità che possono essere ridistribuite in un nuovo sistema.
L’analisi dovrebbe quindi distinguere il funzionamento attuale dal funzionamento desiderato.
Il modello AS-IS descrive il processo esistente, mentre il modello TO-BE rappresenta la configurazione prevista dopo l’introduzione della nuova soluzione.
Questa distinzione è utile perché impedisce di trasformare il software in una semplice replica digitale di inefficienze già presenti.
Nel contesto enterprise il valore dell’analista consiste quindi anche nella capacità di riconoscere dove la tecnologia debba supportare il processo e dove, invece, il processo possa essere riprogettato.
Scope management: definire ciò che il sistema farà e ciò che non farà
Una delle funzioni più importanti dell’analisi riguarda la delimitazione dello scope.
La complessità dei progetti cresce rapidamente quando nuove esigenze vengono introdotte senza valutarne l’impatto su architettura, tempi e dipendenze.
Definire il perimetro significa quindi esplicitare non soltanto le funzionalità incluse, ma anche quelle escluse o rimandate a release successive.
Questo consente di distinguere una modifica di dettaglio da una vera change request.
Se una funzionalità viene aggiunta dopo l’approvazione del perimetro, il problema non consiste nel fatto che il requisito sia “sbagliato”, ma nella necessità di valutarne l’impatto sul sistema.
Lo scope diventa così uno strumento di governance, non una barriera al cambiamento.
Use case e user story: rappresentazioni differenti dello stesso comportamento
L’analisi funzionale può essere documentata attraverso strumenti differenti.
Use case, user story, diagrammi di processo, acceptance criteria e prototipi possono descrivere aspetti diversi dello stesso sistema.
Lo use case tende a rappresentare in modo strutturato l’interazione tra un attore e il sistema, includendo precondizioni, flusso principale, scenari alternativi ed eccezioni.
La user story adotta invece una forma più sintetica, particolarmente utilizzata nei contesti Agile, collegando una necessità dell’utente al valore atteso.
Le due modalità non sono necessariamente alternative.
Una user story può essere sufficiente per una funzionalità semplice, mentre processi complessi possono richiedere scenari più articolati, diagrammi o specifiche aggiuntive.
Il livello di documentazione dovrebbe quindi essere proporzionato al rischio di ambiguità.
Documentare ogni dettaglio di una funzione intuitiva può aumentare inutilmente il costo dell’analisi, mentre descrivere con poche righe una procedura critica con numerose eccezioni può trasferire un’eccessiva quantità di interpretazione al team di sviluppo.
Acceptance criteria: rendere il requisito testabile
Un requisito diventa particolarmente utile quando è possibile stabilire in modo oggettivo se sia stato soddisfatto.
Gli acceptance criteria svolgono questa funzione.
Definiscono le condizioni che una funzionalità deve rispettare per essere considerata conforme alla richiesta.
Per esempio, specificare che “il sistema deve consentire l’approvazione delle spese” lascia aperte numerose interpretazioni.
Definire che richieste inferiori a una certa soglia richiedano un singolo livello di approvazione, mentre quelle superiori ne richiedano due, rende il comportamento più verificabile.
Questo collegamento tra analisi e testing riduce la distanza tra ciò che viene richiesto e ciò che viene validato.
Il tester non deve ricostruire autonomamente il significato del requisito, ma può utilizzare criteri già condivisi come base dei test case.
Traceability: collegare requisito, sviluppo e verifica
Nei progetti enterprise la tracciabilità diventa particolarmente importante quando il numero di requisiti aumenta o quando esistono vincoli normativi e contrattuali.
Requirements traceability significa poter collegare un requisito alla relativa implementazione, ai test che lo verificano e, quando necessario, alla decisione di business che lo ha originato.
Questo consente di rispondere a domande operative rilevanti.
Quali funzionalità sono interessate dalla modifica di un requisito? Quali test devono essere rieseguiti? Quale stakeholder ha richiesto quella capacità? Quali componenti implementano una specifica regola?
La tracciabilità aumenta il lavoro iniziale, ma può ridurre significativamente il costo delle modifiche nei sistemi complessi.
Non è necessario applicarla con lo stesso livello di granularità a ogni progetto.
La profondità dovrebbe essere proporzionata a dimensione, durata, criticità e requisiti di audit.
Data requirements: descrivere informazioni e regole, non soltanto schermate
Un rischio frequente dell’analisi funzionale consiste nel concentrarsi eccessivamente sull’interfaccia utente.
Wireframe e prototipi sono strumenti utili, ma una schermata rappresenta soltanto uno dei modi attraverso cui l’utente interagisce con il sistema.
Dietro ogni interfaccia esiste un modello informativo.
Quali dati devono essere acquisiti? Quali sono obbligatori? Qual è la fonte autorevole? Per quanto tempo devono essere conservati? Quali utenti possono modificarli? Quali relazioni esistono tra le entità?
Queste domande sono particolarmente importanti nelle integrazioni.
Quando due sistemi scambiano informazioni, il problema non consiste soltanto nel definire un endpoint, ma nel concordare significato, formato, ownership e lifecycle del dato.
L’analisi funzionale contribuisce quindi anche alla definizione dei data requirement che verranno successivamente tradotti in modelli tecnici.
Integration requirements: descrivere il comportamento ai confini del sistema
Le applicazioni enterprise raramente operano in isolamento.
ERP, CRM, identity provider, sistemi di pagamento, data platform, applicazioni legacy e servizi di terze parti formano un ecosistema nel quale la maggior parte dei processi attraversa più componenti.
Per questo una parte significativa dell’analisi riguarda i confini.
Quale sistema avvia l’evento? Quale detiene il master data? Cosa accade se il servizio esterno non risponde? Il processo deve essere sincrono o può essere asincrono? Come viene gestita una transazione parzialmente completata?
Questi aspetti si trovano sul confine tra analisi funzionale e progettazione tecnica.
L’analisi dovrebbe definire il comportamento atteso, lasciando alla progettazione il compito di individuare il meccanismo tecnologico più appropriato.
Questa distinzione evita che la soluzione tecnica venga incorporata troppo presto nel requisito.
Exception flow: il comportamento anomalo è parte della funzionalità
Molti requisiti descrivono con precisione il percorso ideale e dedicano poca attenzione alle eccezioni.
Nei sistemi reali, tuttavia, una parte importante della complessità deriva precisamente dagli scenari non lineari.
Cosa accade se il pagamento viene autorizzato ma l’ordine non viene creato? Come si comporta il sistema se due utenti modificano contemporaneamente la stessa informazione? Cosa succede se un documento obbligatorio viene eliminato durante una procedura?
Gli exception flow dovrebbero quindi essere considerati parte integrante del comportamento funzionale.
Questo non significa prevedere ogni possibile failure tecnico durante l’analisi, ma identificare gli scenari di business che richiedono una gestione specifica.
Una buona analisi riduce la quantità di decisioni che lo sviluppatore deve prendere autonomamente su comportamenti che appartengono in realtà al dominio.
Analisi funzionale e architettura: separare cosa e come senza creare silos
La distinzione classica tra analisi funzionale e progettazione tecnica rimane utile, ma nei progetti moderni non dovrebbe trasformarsi in una separazione rigida tra team.
Una scelta funzionale può avere conseguenze architetturali significative.
Richiedere aggiornamenti in real time, gestione offline, audit completo o multi-tenancy modifica il tipo di soluzione tecnica possibile.
Allo stesso modo, un vincolo infrastrutturale può rendere necessario rivedere una funzionalità.
Per questo Business Analyst, Architect e Tech Lead tendono a collaborare durante refinement e discovery.
L’analisi definisce il comportamento desiderato, mentre la progettazione verifica se quel comportamento sia tecnicamente sostenibile e quali trade-off introduca.
Il feedback tra le due discipline riduce il rischio di arrivare alla fase di sviluppo con requisiti formalmente completi ma incompatibili con i vincoli del sistema.
Agile requirements: analizzare progressivamente senza rinunciare alla precisione
L’adozione di Agile ha talvolta alimentato l’idea che documentare i requisiti sia contrario a un modello iterativo.
In realtà, Agile modifica soprattutto il momento e il livello di dettaglio con cui l’analisi viene svolta.
Invece di specificare l’intero sistema prima dell’inizio dello sviluppo, i requisiti possono essere progressivamente raffinati in prossimità della loro implementazione.
Questo modello viene spesso descritto attraverso il concetto di just-enough e just-in-time analysis.
La documentazione non scompare.
Diventa proporzionata all’informazione necessaria in quel momento.
La stessa IIBA mantiene una certificazione specifica dedicata all’Agile Analysis, sottolineando l’integrazione tra pratiche di business analysis e modelli Agile.
Il livello di precisione continua quindi a essere importante, ma viene distribuito lungo il ciclo di delivery.
Rework cost: intervenire prima tende a ridurre il costo della modifica
Un requisito incompleto può essere corretto in momenti differenti.
Se l’ambiguità viene individuata durante un workshop, l’intervento può consistere nella modifica di una specifica.
Se emerge dopo lo sviluppo, può richiedere variazioni al codice e ai test.
Se viene individuata dopo il rilascio, può coinvolgere migrazioni dati, documentazione, supporto agli utenti e attività operative.
Non è necessario assumere che il costo aumenti sempre secondo una proporzione universale, perché dipende fortemente dal tipo di sistema e dalla natura della modifica.
Il principio rimane tuttavia valido: più artefatti dipendono da una decisione, maggiore tende a essere l’impatto di modificarla.
È questa la ragione per cui requirements engineering e quality by design sono spesso associate alla riduzione del rework.
Change management: un buon requisito può cambiare
Formalizzare un requisito non significa renderlo immutabile.
In un progetto software, nuove informazioni possono modificare priorità e comportamenti attesi.
L’obiettivo dell’analisi non è impedire il cambiamento, ma renderlo visibile.
Quando un requisito viene modificato, dovrebbe essere possibile comprenderne l’impatto su backlog, architettura, integrazioni e test.
Questo consente di distinguere un cambiamento necessario da una modifica apparentemente piccola ma con conseguenze significative.
Un processo di change management maturo non valuta quindi soltanto la richiesta in sé, ma il suo impatto sul sistema.
AI-assisted requirements engineering: accelerare la documentazione senza delegare il significato
Nel 2026 anche la requirements engineering è interessata dall’utilizzo dell’intelligenza artificiale generativa.
LLM e strumenti integrati nelle piattaforme di sviluppo possono supportare sintesi di workshop, trasformazione di note in user story, generazione di acceptance criteria, individuazione di possibili scenari mancanti e produzione di prime versioni della documentazione.
Questa capacità può ridurre il tempo necessario per alcune attività, soprattutto quando devono essere elaborati grandi volumi di informazioni.
Il limite riguarda il significato.
Un modello può suggerire un requisito plausibile ma non possiede necessariamente il contesto organizzativo necessario per stabilire se quella regola rappresenti realmente il processo.
Lo stesso principio vale per il codice generato dall’AI.
Uno studio IEEE pubblicato nel 2025 su oltre 500.000 campioni Java e Python ha rilevato profili di difetto differenti tra codice umano e codice generato da LLM e una maggiore presenza di alcune vulnerabilità ad alto rischio nel codice AI-generated, rafforzando l’importanza di pratiche di verifica specifiche nei workflow assistiti dall’intelligenza artificiale.
L’AI può quindi accelerare l’elaborazione dell’analisi, ma la validazione del requisito rimane una responsabilità del team e degli stakeholder.
Functional specification: il documento è un mezzo, non il risultato dell’analisi
L’output dell’analisi funzionale può assumere forme molto differenti.
In alcuni progetti può esistere una Functional Specification dettagliata. In altri, la conoscenza può essere distribuita tra backlog, diagrammi BPMN, user story, mockup, acceptance criteria e documentazione API.
La qualità dell’analisi non dipende necessariamente dal numero di pagine prodotte.
Il criterio più utile consiste nel verificare se gli artefatti disponibili riducano sufficientemente l’ambiguità per le persone che devono progettare, sviluppare e testare il sistema.
Un documento molto esteso può diventare difficile da mantenere.
Una documentazione eccessivamente ridotta può trasferire troppe decisioni implicite ai developer.
Il livello appropriato dipende da complessità, criticità, turnover del team, requisiti normativi e durata prevista dell’applicazione.
Dal requisito alla testabilità: costruire una continuità tra analisi e QA
Una delle conseguenze più utili di una buona analisi è la possibilità di collegare direttamente requirement e quality assurance.
Quando requisiti e acceptance criteria sono sufficientemente precisi, possono diventare la base per test funzionali, integration test ed end-to-end test.
Questo riduce il rischio che analista e tester utilizzino interpretazioni differenti.
La stessa specifica diventa riferimento sia per chi implementa sia per chi verifica.
Nei contesti più maturi questa relazione può essere ulteriormente formalizzata attraverso requirements traceability matrix o strumenti ALM che collegano requisiti, ticket, commit e test case.
La tracciabilità non rappresenta necessariamente un requisito per ogni progetto, ma aumenta di valore con la crescita della complessità.
Requirements governance: evitare che il significato si frammenti nel tempo
Nei programmi enterprise di lunga durata i requisiti possono evolvere attraverso numerose release e team differenti.
Il rischio è che il significato originale di una regola venga progressivamente perso.
Una validazione introdotta cinque anni prima può apparire inutile a uno sviluppatore che non conosce più il processo che l’aveva resa necessaria.
La governance dei requisiti contribuisce a conservare questo contesto.
Ownership, versioning, decision log e collegamenti con le regole di business permettono di distinguere ciò che può essere modificato liberamente da ciò che dipende da vincoli normativi, contrattuali o operativi.
In questo senso l’analisi funzionale non appartiene soltanto alla fase iniziale del progetto.
Può accompagnare l’intero ciclo di vita del software.
Ridurre errori non significa eliminare l’incertezza
Una buona analisi funzionale non rende un progetto completamente prevedibile.
Software complessi operano in contesti nei quali requisiti, utenti, tecnologie e processi possono cambiare.
Il suo valore consiste piuttosto nel rendere esplicita una parte dell’incertezza prima che venga trasformata in codice. Assunzioni, eccezioni, dipendenze, vincoli e criteri di accettazione diventano visibili e possono quindi essere discussi. Questo rende più probabile che eventuali divergenze emergano quando modificarle costa relativamente poco.
L’obiettivo non è prevedere tutto. È ridurre la quantità di decisioni importanti che vengono prese implicitamente.
Analisi funzionale: dal documento alla riduzione del rischio progettuale
Nel 2026 l’analisi funzionale rimane quindi una componente rilevante del software engineering, anche se la forma con cui viene realizzata può variare significativamente tra progetti tradizionali, Agile e product-oriented.
Il suo ruolo non consiste necessariamente nel produrre una specifica completa prima dell’inizio dello sviluppo.
Consiste nel creare una rappresentazione condivisa e verificabile del comportamento atteso del sistema.
Quando questa rappresentazione è sufficientemente chiara, developer, architect, tester e stakeholder possono lavorare su una base comune, le modifiche possono essere valutate in modo più consapevole e una parte del rework generato da incomprensioni può essere evitata.
La requirements engineering contemporanea mantiene precisamente questa funzione. Non elimina il cambiamento, ma cerca di renderne esplicite condizioni e conseguenze lungo il ciclo di vita. Lo stesso standard ISO/IEC/IEEE 29148 è applicabile indipendentemente dalla metodologia, dalla dimensione e dalla complessità del progetto, mentre la nuova edizione in sviluppo nel 2026 conferma la continuità di questo approccio.
Per un progetto enterprise, quindi, l’analisi funzionale può essere interpretata come un investimento nella riduzione dell’ambiguità.
Il suo valore emerge quando consente di individuare prima una regola mancante, un’eccezione non considerata, una definizione incoerente o una dipendenza che altrimenti sarebbe diventata evidente soltanto durante sviluppo, testing o produzione.
In questa prospettiva, il risultato più importante non è la documentazione prodotta.
È la quantità di interpretazioni divergenti che quella documentazione, insieme al processo di confronto che l’ha generata, riesce a evitare.
Fonti citate:
- International Institute of Business Analysis. (2026). Agile Analysis Certification. IIBA.
- International Organization for Standardization. (2018). ISO/IEC/IEEE 29148:2018. Systems and software engineering — Life cycle processes — Requirements engineering. ISO.
- International Organization for Standardization. (2026). ISO/IEC/IEEE DIS 29148. Systems and software engineering — Life cycle processes — Requirements engineering. ISO.
- International Organization for Standardization. (2019). ISO/IEC 25030:2019. Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Quality requirements framework. ISO.
- International Organization for Standardization. (2023). ISO/IEC TR 7052:2023. Software engineering — Controlling frequently occurring risks during development and maintenance of custom software. ISO.
- Institute of Electrical and Electronics Engineers. (2025). IEEE P25000-70: Systems and software Quality Requirements and Evaluation — Quality engineering framework. IEEE Standards Association.
- Liu, et al. (2025). Human-Written vs. AI-Generated Code: A Large-Scale Study of Defects, Vulnerabilities, and Complexity. Proceedings of the 36th IEEE International Symposium on Software Reliability Engineering.
Autore: Martina Pegoraro
