I requisiti funzionali specificano le funzionalità che un sistema deve implementare.
I requisiti non funzionali specificano tutti gli altri requisiti che il sistema deve implementare.

Se la tua esigenza di una GUI più semplice non aggiunge nuove funzionalità al sistema, ma specifica solo la facilità con cui deve accedere a tali funzionalità, allora è un requisito non funzionale.

D'altra parte, la distinzione tra requisiti funzionali e non funzionali è abbastanza arbitraria. Sapere se un requisito è un requisito funzionale o non funzionale non ti aiuta veramente ad implementarlo.

link

La semplicità d'uso può essere testata su gruppi target e mostrerebbe. Quindi direi che è funzionale. Non funzionale è più come devi usare questa particolare marca di equipaggiamento o devi usare energia verde per gestirla.

Questo non è un requisito funzionale o non funzionale.

Poiché ho già spiegato alcuni anni fa, i requisiti sono oggettivi e, come già affermato da Robert Harvey in suo commento , verificabile . Potrebbe non essere necessariamente possibile codificare un test in un modo in cui i test di unità sono fatti, ma ci dovrebbe essere un modo per avere un test di validazione che indichi in modo definitivo e non ambiguo se il requisito è soddisfatto o meno.

Il primo brutto segno è l'uso di "più facile". Aggettivi come "facile", "semplice", "bello" o "facile da usare" hanno una strong connotazione soggettiva. A meno che non concordiamo in modo specifico - ed è molto possibile farlo - sulle misure precise della semplicità, della semplicità, della gentilezza e della facilità d'uso di un software, la presenza di tali termini indica che siamo di fronte a qualcosa che è non un requisito.

Il secondo problema è "più utilizzabile". Non dovrebbero esserci paragoni senza obiettivi nei requisiti. Più di cosa? "Più, rispetto al nostro prodotto precedente" o "Più della versione 3.0 di La nostra concorrenza Inc." ha senso, non appena il confronto stesso può essere tradotto in un test di validazione. Ma solo "di più"? No, questo non ce l'avrebbe fatta.

Se strongmente riformulato (e per questo, intendo completamente rimosso e sostituito da un requisito reale, correttamente scritto), potrebbe diventare un requisito non funzionale. L'accessibilità, già citata da Robert Harvey, è una cosa molto obiettiva; ad esempio, un requisito non funzionale per un sito Web può specificare un livello richiesto tra le Linee guida per l'accessibilità del contenuto Web (WCAG) tre livelli di conformità : da allora, il sito Web è conforme al livello richiesto e, quindi, soddisfa il requisito, oppure no.

Ma formulazioni oniriche su belle GUI che sono user-friendly? Tenerlo ai venditori.

Cosa c'è che non va nei requisiti soggettivi?

L'obiettivo dei requisiti è quello di fare in modo che due società o gruppi di persone concordino su ciò che l'entità vuole che l'altro faccia. Questa è una cosa contrattuale. O rispetti i tuoi obblighi contrattuali, vieni pagato e tutti sono felici o devi prepararti per un contenzioso.

Se i requisiti sono verificabili oggettivamente, non ci saranno contenziosi.

Se i requisiti sono flaccidi, rilascerai il prodotto, quindi il cliente dichiarerà di non aver rispettato i tuoi obblighi , risponderai che hai fatto tutto bene, e lui affermare che non l'hai fatto, e i tuoi avvocati sprecheranno mesi a sistemarsi. Se voglio convincermi con la tua azienda, farei proprio questo: abbozzare un sacco di requisiti soggettivi e affermare che non devo pagare per il tuo lavoro, perché il prodotto che hai fatto non è il prodotto I bisogno. Non ha una GUI facile: l'ho testato sul nostro dipendente disabile e non poteva farci niente. Non è abbastanza veloce, mentre ho esplicitamente specificato che voglio che sia veloce. Non è nemmeno facile da usare, anche se ho chiesto chiaramente di essere.

Un requisito funzionale riguarda cosa il sistema deve fare. Il termine "funzionale" deriva da "funzione" che significa qualcosa che richiede un input e produce un output.

Un requisito non funzionale riguarda come (bene) il sistema deve fai quello che fa Questi sono solitamente requisiti di qualità, come prestazioni, affidabilità o facilità d'uso, o requisiti tecnici generali che si applicano all'intero sistema (ad esempio, gli standard devono essere applicati, compatibilità del sistema operativo, limitazioni hardware).

Potresti anche essere interessato alla differenza tra le funzioni e requisiti non funzionali .

Il tuo requisito non dice affatto cosa fa il sistema, ma indica come il sistema deve farlo. È quindi senza dubbio un requisito non funzionale .

Modifica: Come puoi vedere nei commenti, sarebbe consigliabile riformulare il tuo requisito non funzionale per renderlo obiettivo, meno ambiguo e verificabile.