Cos'è un requisito non funzionale

I Requisiti Non Funzionali o NFR descrivono caratteristiche del software che non sono definite in termini di funzionalità. Generalmente si tratta di attributi o vincoli del sistema che terminano con '-ility' o '-ilities'. Per esempio:

  • manutenibilità
  • scalabilità
  • usabilità

Tipi di requisiti non funzionali

Esistono potenzialmente dozzine di tipi NFR. L'importanza di ciascun tipo di NFR dipenderà dal tipo di software, dal contesto e dal caso d'uso. Alcuni dei tipi NFR più comunemente considerati sono:

  • Sicurezza
  • Prestazione
  • Scalabilità
  • Affidabilità
  • Usabilità
  • Legale
  • Manutenibilità
  • Portabilità

UN elenco completo degli NFR è disponibile su Wikipedia.

Sicurezza: un caso speciale

Vale la pena dare un'occhiata più da vicino alla sicurezza come NFR. Sebbene la sicurezza sia comunemente considerata non funzionale, in realtà la maggior parte dei requisiti di sicurezza sono infatti funzionali. Ad esempio, è probabile che i controlli delle autorizzazioni prima di eseguire un processo siano un requisito funzionale. Nei nostri studi oltre 90% tutti i requisiti di sicurezza sono funzionali.

I vantaggi del rilevamento automatico degli NFR

I requisiti non funzionali sono una dimensione importante del software. Spesso vengono trascurati o di scarsa qualità (non specifici, incompleti o incoerenti). Gli NFR possono avere un impatto significativo sul lavoro di fornitura di un software. Trascurarli può portare ad un aumento del rischio per un progetto.

Quando utilizzi ScopeMaster per analizzare i tuoi requisiti per potenziali NFR, puoi creare una lista di controllo per garantire che le NFR siano coperte correttamente e adeguatamente. Ciò ridurrà i rischi per il tuo progetto. Inoltre, si desidera evitare di mescolare requisiti funzionali con requisiti non funzionali a meno che non sia necessario farlo.

Rilevamento NFR, Automatizzato

ScopeMaster analizza i tuoi requisiti (o storie degli utenti) alla ricerca di indizi su importanti requisiti non funzionali.

Analisi CRUD con ScopeMaster - screenshot

ScopeMaster analizza il testo dei requisiti software. Esso rileva i requisiti non funzionali più probabili dall'interno di ciascun requisito.

Determina la probabilità che ciascun requisito sia o contenga un requisito non funzionale.

Casi d'uso di esempio

La maggior parte degli NFR sono “sepolti” all’interno di altri requisiti e sono difficili da individuare. Gli architetti spesso devono vagliare centinaia di requisiti per cercare di filtrare gli NFR che potrebbero avere un impatto sull'architettura di un sistema. Se questi non vengono identificati abbastanza presto, potrebbero essere prese decisioni di progettazione inappropriate. Queste decisioni di progettazione possono comportare costose rilavorazioni o debiti tecnici. La capacità di ScopeMaster di individuare questi NFR fin dall'inizio aiuta a esporli prima che il lavoro di progettazione abbia avuto luogo. Casi d'uso tipici:

  • Hai molti requisiti e stai cercando di rilevare tutti gli NFR di una particolare categoria.
  • Hai molti requisiti e non sei sicuro di aver incluso degli NFR al loro interno.
  • È necessario verificare la presenza di NFR potenzialmente in conflitto
  • I tuoi requisiti sono stati raccolti da più persone ed è necessario armonizzare gli NFR.

ScopeMaster rileva la probabile fraseologia dai requisiti che potrebbero essere o deduce un requisito non funzionale.

Requisiti di qualità non funzionali

Cosa rende NFR di alta qualità? Dovresti sempre cercare di quantificare i requisiti non funzionali in termini quantificabili che abbiano senso per il team e con cui il cliente possa identificarsi. Questi dovrebbero darti il “livello di accettabilità” di ogni dato NFR. Per esempio, tutte le pagine web dovrebbero essere caricate entro 1,5 secondi, pronte per l'interazione dell'utente.  

Esempi di requisiti non funzionali

Ecco alcuni esempi di NFR, nota la specificità di ciascuno. Criteri di superamento/fallimento inequivocabili sono inclusi in ciascuno di essi:

Prestazione – Tutte le pagine web verranno caricate per l'interazione entro 2 secondi su una connessione da 5 Mbs da qualsiasi parte del mondo.

Capacità – Con modifiche trascurabili, il software dovrebbe essere in grado di gestire 3 milioni di record di transazioni.

Legale – Il sistema deve essere conforme alla legislazione GDPR, inclusa la possibilità di segnalare e/o eliminare i record personali soggetti a richiesta specifica.

Usabilità – Il sito web deve essere conforme alle WCAG 2.2 livello A