Risposta.

Requisiti funzionali descrivono cosa il sistema deve fare: operazioni aziendali, processi, scenari utente — cioè funzionalità.

Requisiti non funzionali definiscono come il sistema deve funzionare: vincoli, parametri di qualità, prestazioni, sicurezza, usabilità, ecc. Questi requisiti influenzano spesso la scelta delle tecnologie, la scalabilità e la robustezza della soluzione.

Perché è importante distinguere:

• Una chiara separazione aiuta a formulare correttamente i compiti per sviluppatori e tester.
• Permette di evitare il rischio di trascurare caratteristiche critiche (ad esempio, sicurezza, scalabilità).
• Requisiti non funzionali non considerati diventano spesso fonte di fallimento del progetto.

Caratteristiche chiave:

• Requisiti funzionali — comportamento del sistema.
• Requisiti non funzionali — qualità e vincoli.
• Entrambi i tipi devono essere chiaramente documentati e concordati.

Domande trabocchetto.

L'"usabilità dell'interfaccia" rientra nei requisiti funzionali?

No, è un parametro non funzionale (usability). Un requisito funzionale è la presenza, ad esempio, di un pulsante "Salva", un requisito non funzionale è la velocità di risposta e la facilità d'uso.

Si possono ignorare i requisiti non funzionali se non sono esplicitamente indicati dal cliente?

No. L'analista è tenuto a discutere e formalizzare anche i requisiti non funzionali impliciti, altrimenti aumenta il rischio di ritardi nel lancio, lamentele degli utenti e costi aggiuntivi.

“Il sistema deve essere in grado di elaborare 1000 richieste al minuto”. È un requisito funzionale?

No, è un requisito non funzionale — caratteristica di prestazione.

Errori comuni e anti-pattern

• Focalizzarsi solo sulle funzionalità ("l'importante è che funzioni, la velocità si vedrà dopo").
• Formulazione implicita dei requisiti non funzionali — "deve essere veloce", "affidabile", "sicuro".
• Ignorare il testing della non funzionalità.

Esempio della vita reale

Casi negativi: Il sistema ha implementato completamente le funzionalità aziendali dichiarate, ma sotto carico elevato iniziava a "bloccarsi", poiché le prestazioni non erano state considerate affatto. Pro:

• Sviluppo rapido, esecuzione accurata degli scenari dichiarati. Contro:
• Il sistema non era adatto per l'uso in condizioni di carico reale, l'azienda ha dovuto rivedere urgentemente l'architettura.

Casi positivi: L'analista insieme all'architetto e al cliente ha fissato nei requisiti il carico massimo, i criteri di risposta e ha condotto test di carico. Pro:

• Il prodotto funzionava stabilmente e resisteva all'aumento degli utenti.
• I piani di sviluppo prevedevano la scalabilità. Contro:
• All'inizio della progettazione è stato necessario dedicare più tempo alla discussione e ai test aggiuntivi.