Qual è il requisito non funzionale nell'ingegneria del software?

By: charles moore charles moore
Hours aggiornato

⚡ Riepilogo intelligente

I requisiti non funzionali specificano attributi di qualità quali prestazioni, sicurezza, usabilità, affidabilità, scalabilità e portabilità, definendo il comportamento che un sistema software deve possedere e trasformando aspettative vaghe in obiettivi di ingegneria misurabili, testabili e applicabili lungo tutto il ciclo di vita dello sviluppo.

  • 📘 Definizione: Un requisito non funzionale, o NFR, descrive le prestazioni di un sistema in termini di performance, sicurezza, usabilità, affidabilità e portabilità.
  • 🗂️ Tipi comuni: Usabilità, sicurezza, affidabilità, scalabilità, capacità, disponibilità, manutenibilità e conformità normativa sono le categorie dei team track più spesso.
  • 📊 Modello FURPS+: FURPS+ raggruppa i requisiti non funzionali (NFR) in funzionalità, usabilità, affidabilità, prestazioni, manutenibilità e vincoli di progettazione o interfaccia.
  • 🎯 Affermazioni verificabili: Sostituisci "veloce" o "sicuro" con soglie numeriche e metodi di verifica in modo che il requisito non funzionale (NFR) possa essere testato e accettato.
  • 🆚 Contrasto funzionale: I requisiti funzionali descrivono cosa deve fare il sistema; i requisiti non funzionali descrivono con quale efficacia lo fa in condizioni reali.
  • ✅ Impatto aziendale: La mancanza di requisiti non funzionali (NFR) è la causa principale di incidenti in produzione, non conformità normative e costose rielaborazioni architetturali in fase avanzata.
Scopri di più

Requisiti non funzionali nell'ingegneria del software

Che cos'è un requisito non funzionale?

A Requisito non funzionale (NFR) specifica un attributo di qualità di un sistema software. Gli NFR valutano il sistema in base a reattività, usabilità, sicurezza, portabilità e altri attributi di qualità che sono fondamentali per il successo. Un esempio comune di requisito non funzionale è: "quanto velocemente viene caricato il sito web?" Il mancato rispetto dei requisiti non funzionali produce sistemi che generano frustrazione negli utenti.

Nell'ingegneria del software, i requisiti non funzionali impongono vincoli alla progettazione del sistema lungo tutto il backlog agile. Ad esempio, il sito dovrebbe caricarsi in tre secondi quando gli utenti simultanei superano i 10,000. Descrivere i requisiti non funzionali è altrettanto importante quanto definire i requisiti funzionali.

Tipi di requisiti non funzionali

Le principali categorie di requisiti non funzionali sono:

Tipi di requisiti non funzionali

Tipi di requisiti non funzionali

  • usabilità
  • Facilità di manutenzione
  • Manageability
  • Recuperabilità
  • Sicurezza
  • Dati Integrity
  • Ultra-Grande
  • Disponibilità
  • Scalabilità
  • Interoperabilità
  • L’affidabilità
  • manutenibilità
  • Conformità normativa
  • Vincoli ambientali

Esempi di requisiti non funzionali

Ecco alcuni esempi pratici di requisiti non funzionali:

  1. Gli utenti devono cambiare la password iniziale dopo il primo accesso riuscito e la password iniziale non deve mai essere riutilizzata.
  2. Ai dipendenti non è consentito aggiornare autonomamente le informazioni relative al proprio stipendio e qualsiasi tentativo in tal senso sarà segnalato al responsabile della sicurezza.
  3. Ogni tentativo non riuscito da parte di un utente di accedere a un elemento di dati deve essere registrato in un registro di controllo.
  4. Il sito web dovrà supportare 20 milioni di utenti simultanei senza rallentamenti nei tempi di risposta.
  5. Il software deve essere portatile, in modo che il passaggio da un sistema operativo all'altro non crei problemi.
  6. La riservatezza delle informazioni, l'esportazione di tecnologie soggette a restrizioni e i diritti di proprietà intellettuale devono essere verificabili.

Requisiti funzionali vs. non funzionali

Le principali differenze tra requisiti funzionali e non funzionali sono:

Scheda Sintetica Requisito funzionale Requisito non funzionale
Che cos'è? Verbo Attributi
Requisito È obbligatorio Non è obbligatorio
Tipo di cattura Viene acquisito nel caso d'uso. Viene catturato come attributo di qualità.
Risultato finale caratteristica di prodotto Proprietà del prodotto
Catturare Facile da catturare Difficile da catturare
Obiettivo Aiuta a verificare la funzionalità del software. Ti aiuta a verificare le prestazioni del software.
Area di interesse Concentrarsi sulle esigenze dell'utente Si concentra sulle aspettative dell'utente.
Documentazione Descrivi cosa fa il prodotto Descrive come funziona il prodotto
Tipo di test Test di funzionalità come test di sistema, di integrazione, end-to-end, di API, ecc. Test non funzionali come prestazioni, stress, usabilità, test di sicurezza, ecc.
Esecuzione del test L'esecuzione del test viene eseguita prima dei test non funzionali. Dopo il test funzionale
Informazioni sul prodotto Caratteristiche Proprietà del prodotto

ARTICOLI CORRELATI

Vantaggi dei requisiti non funzionali

I principali vantaggi di Test non funzionali siamo:

  • I requisiti non funzionali garantiscono che il sistema rispetti le normative legali e di conformità.
  • Proteggono l'affidabilità, la disponibilità e le prestazioni del sistema.
  • Offrono una buona esperienza utente e facilità d'uso.
  • Definiscono le politiche di sicurezza del software.

Svantaggi dei requisiti non funzionali

Gli svantaggi più comuni dei requisiti non funzionali sono:

  • I requisiti non funzionali possono interessare diversi sottosistemi software di alto livello.
  • Richiedono una considerazione particolare in fase di progettazione architettonica e di alto livello, il che ne aumenta i costi.
  • L'implementazione raramente corrisponde a un singolo sottosistema software.
  • Sono difficili da modificare una volta completata la fase di progettazione.

Modello FURPS+ per la classificazione dei requisiti non funzionali

FURPS+ è la tassonomia più diffusa per i requisiti non funzionali. Sviluppata originariamente presso Hewlett-Packard, raggruppa gli attributi di qualità in cinque categorie principali, più vincoli aggiuntivi contrassegnati dal simbolo "+". Il modello aiuta gli analisti aziendali a evitare di trascurare un'intera classe di requisiti.

  • Funzionalità: Funzionalità, sicurezza e riutilizzabilità che vanno ben oltre l'elenco delle caratteristiche di base.
  • usabilità: Fattori umani, estetica, coerenza, documentazione e reattività dell'esperienza utente.
  • Affidabilità: Disponibilità, tempo medio tra i guasti, recuperabilità, prevedibilità e accuratezza.
  • Performance: Velocità, produttività, capacità, scalabilità e consumo di risorse sotto carico.
  • Supportabilità: Testabilità, flessibilità, installabilità, localizzabilità e manutenibilità del sistema fornito.
  • Più (+): Progettazione, implementazione, interfaccia e vincoli fisici quali piattaforme, standard o hardware richiesti.

I team che mappano ogni requisito non funzionale a una categoria FURPS+ hanno meno probabilità di rilasciare un sistema che soddisfi i requisiti funzionali ma che presenti problemi di prestazioni, sicurezza o manutenibilità.

Come scrivere requisiti non funzionali verificabili

Un requisito non funzionale ben formulato è misurabile, verificabile e con una scadenza definita. Affermazioni vaghe come "il sistema deve essere veloce" o "l'app deve essere sicura" sono aspirazioni, non requisiti. Segui i passaggi seguenti per convertire un intento in un requisito non funzionale testabile.

  1. Identificare l'attributo di qualità. Associa il problema a una categoria FURPS+ in modo che il team sappia se si tratta di un requisito di prestazioni, usabilità, sicurezza o affidabilità.
  2. Scegli una metrica. Ogni requisito non funzionale (NFR) necessita di un'unità di misura: millisecondi, richieste al secondo, utenti simultanei, percentuale di tempo di attività o uno standard di conformità come ISO 27001.
  3. Imposta una soglia numerica. Sostituire “veloce” con “meno di 400 millisecondi al 95° percentile”. Sostituire “altamente disponibile” con “tempo di attività mensile del 99.9%”.
  4. Descrivi la condizione. Specificare il carico, l'ambiente o il segmento di utenti a cui si applica la soglia, ad esempio "durante i picchi di vendita con 10,000 utenti simultanei".
  5. Definire il metodo di verifica. Annota il tipo di test (test di carico, test di penetrazione, esperimento di caos, verifica di accessibilità) e lo strumento che confermerà la soglia.
  6. Eseguire il controllo SMART. Prima di inserire il requisito nel backlog, assicurarsi che sia Specifico, Misurabile, Raggiungibile, Rilevante e con Scadenza definita.

Esempio di riscrittura: "Il sistema deve essere veloce" diventa "La pagina di checkout deve rispondere in meno di 500 millisecondi al 95° percentile con 5,000 utenti simultanei, verificato da un JMeter "Eseguire test di carico per ogni rilascio." La dichiarazione rivista permette agli sviluppatori di progettarla tenendo conto di questo aspetto, ai tester di verificarla e ai responsabili di prodotto di accettarla senza obiezioni.

DOMANDE FREQUENTI

Gli strumenti di carico e prestazioni basati sull'intelligenza artificiale generano traffico realistico, rilevano anomalie nelle distribuzioni dei tempi di risposta e prevedono i limiti di scalabilità prima della produzione. L'IA analizza anche i log e i modelli di accesso per segnalare eventi di sicurezza che i tradizionali strumenti basati su regole non riescono a individuare.

Copilot e GPT convertono dichiarazioni di qualità vaghe in requisiti non funzionali misurabili, definendo metriche, soglie, condizioni e metodi di verifica. Gli analisti aziendali esaminano ogni bozza confrontandola con le categorie FURPS+ e il framework SMART prima di accettarla nel backlog.

I test funzionali verificano il corretto funzionamento di alcune funzionalità, come ad esempio l'accesso o la ricerca. I test non funzionali misurano le prestazioni del sistema sotto carico, stress e utilizzo, prendendo in considerazione obiettivi relativi a prestazioni, sicurezza, usabilità, compatibilità e affidabilità.

Scalabilità, disponibilità, latenza, elasticità ed efficienza dei costi sono i requisiti non funzionali (NFR) del cloud più importanti. I team inoltre tracOsservabilità, obiettivi di ripristino di emergenza come RPO e RTO e conformità multiregionale sono i fattori che guidano la maggior parte delle decisioni relative all'architettura cloud.

Scegli una metrica con un'unità, imposta una soglia numerica, descrivi la condizione in cui si applica e indica il metodo di verifica. Ad esempio, tempo di risposta inferiore a 400 millisecondi al 95° percentile con 5,000 utenti, verificato da JMeter.

La crittografia dei dati a riposo e in transito, la robustezza dell'autenticazione, l'autorizzazione basata sui ruoli, la registrazione degli eventi di controllo, il timeout di sessione e la conformità a standard quali ISO 27001, PCI DSS e GDPR sono i requisiti non funzionali di sicurezza (NFR) che la maggior parte dei team documenta.

L'uso di aggettivi vaghi, l'omissione della metrica o della condizione, l'elenco dei requisiti non funzionali solo alla fine di un progetto e il copia-incolla di codice standard che nessun test può verificare sono gli errori più comuni che portano a rielaborazioni dell'architettura in fase avanzata.

I requisiti non funzionali (NFR) sono presenti nelle specifiche dei requisiti software, nei record delle decisioni architetturali, negli accordi sul livello di servizio (SLA) e nelle checklist della definizione di "fatto". I team Agile spesso associano NFR misurabili agli epic e alla definizione di "pronto" per ogni user story.

Riassumi questo post con: