Risposta.

Storicamente, nei progetti IT, l'attenzione principale è stata dedicata ai requisiti funzionali: cosa deve fare il sistema. Nel frattempo, problemi come le prestazioni, l'affidabilità, la scalabilità, la disponibilità, la sicurezza e la manutenibilità (queste caratteristiche rientrano nel termine «requisiti non funzionali», NFT) sono rimasti a lungo secondari e spesso non sono stati formalizzati affatto.

Problema

Ignorare o descrivere formalmente gli NFT porta a problemi significativi durante l'operatività: il sistema non è pronto per i carichi di lavoro previsti, non resiste agli attacchi informatici, è difficile da mantenere e scalare, oppure non è accessibile per il numero necessario di utenti.

Soluzione

Un moderno analista di sistema deve avviare, formalizzare, analizzare e documentare gli NFT. Questo include:

collaborare con architetti, team DevOps e operativi per identificare vincoli tecnologici e infrastrutturali;
raccogliere requisiti dal business (ad esempio, in base agli SLA);
formare un elenco dettagliato di NFT con valori soglia specifici;
implementare misure per il controllo durante le fasi di implementazione e supporto;
registrare i requisiti in sezioni separate delle specifiche.

Caratteristiche chiave:

Gli NFT sono obbligatori per qualsiasi progetto di grandi dimensioni.
Vengono definiti in collaborazione con stakeholder tecnici e di business.
Devono essere chiari, testabili e legati agli obiettivi aziendali.

Domande trabocchetto.

Qual è la differenza tra "qualità del prodotto" e "requisiti non funzionali"?

La qualità del prodotto è un concetto più ampio che include non solo parametri formalizzabili ma anche valutazioni soggettive (ad esempio, l'usabilità UX/UI). Gli NFT sono caratteristiche chiaramente misurabili (prestazioni, affidabilità, ecc.) soggette a validazione automatica.

Può un analista delegare la definizione di tutti i requisiti non funzionali all'architetto?

No, l'analista deve identificare questi requisiti insieme all'architetto e al business nella fase di analisi, altrimenti i requisiti saranno incompleti o descritti solo dal punto di vista tecnico, senza considerare le esigenze del business.

Possono i requisiti non funzionali essere formulati solo in modo generico ("il sistema deve essere affidabile")?

No, tali formulazioni non sono idonee per il controllo e il testing. È necessaria una maggiore specificità: ad esempio, "il tempo di ripristino del servizio dopo un guasto non deve superare i 10 minuti".

Errori comuni e anti-pattern

Formulazione dei requisiti senza criteri testabili ("veloce", "fantastico", "affidabile").
Salto di intere classi di NFT (ad esempio, sicurezza per sistemi interni).
Incoerenza dei requisiti tra cliente e supporto.

Esempio dalla vita reale

Caso negativo: Il progetto del portale nazionale dei servizi pubblici non ha formalizzato i requisiti per i carichi di lavoro di picco. Il sistema "crollava" nei giorni di lancio di servizi popolari, si verificavano incidenti legati alla sicurezza.

Vantaggi:

MVP veloce

Svantaggi:

Costi elevati per le modifiche
Perdita di fiducia degli utenti
Difficoltà nella manutenzione

Caso positivo: L'analista all'inizio del progetto di un impianto di automazione industriale ha scoperto insieme all'operatività che i tempi di inattività del sistema erano più importanti delle nuove funzionalità. Ha elaborato SLA, scenari di emergenza e ha definito metriche specifiche.