Requisito funzionale o non funzionale?

Mi chiedo quali siano i requisiti funzionali o non funzionali. Ho trovato molte definizioni diverse per quei termini e non posso assegnare alcuni dei miei requisiti alla categoria corretta.

Mi chiedo quali siano i requisiti che non sono connessi con alcune azioni o presentano alcune condizioni aggiuntive, ad esempio:

1. Nell'elenco dei dispositivi selezionati, il dispositivo può essere ripetuto.
2. Il database deve contenere almeno 100 articoli
3. La valuta di un certo valore deve essere in dollari USA.
4. Il dispositivo deve avere un nome e un valore di consumo energetico in Watt.

tali requisiti sono funzionali o non funzionali?

I requisiti funzionali definiscono cosa farà il sistema o l'applicazione, in particolare nel contesto di un'interazione esterna (con un utente o con un altro sistema).

Quando si effettua un nuovo ordine, il sistema deve visualizzare il costo totale e richiedere la conferma da parte dell'utente. Questo è un requisito funzionale; descrive una funzione del sistema.

Fare riferimento a Wikipedia: Requisiti funzionali per maggiori dettagli.

I requisiti non funzionali sono requisiti che non descrivono il comportamento di input / output del sistema. Si noti che stiamo ancora parlando di requisiti , non di dettagli di implementazione , quindi solo perché stiamo usando la frase "non funzionale" non significa che qualsiasi cosa sia un gioco corretto da inserire in quella sezione.

I tipi più comuni di requisiti non funzionali che vedrai riguardano il funzionamento del sistema (disponibilità, continuità, DR), le prestazioni (throughput, latenza, capacità di archiviazione) e la sicurezza (autenticazione, autorizzazione, controllo, privacy).

Queste sono tutte preoccupazioni trasversali che incidono su ogni "caratteristica", ma non sono in realtà caratteristiche stesse; sono più simili ai metadati delle funzionalità, che aiutano a descrivere non solo se il sistema fa quello che dovrebbe, ma anche quanto bene lo fa. Tuttavia, non esagerare con questa analogia: è solo un'analogia.

I requisiti non funzionali non sono soggettivi o ondulati, contrariamente a quanto sembrano suggerire alcune persone qui. In realtà, dovrebbero in realtà avere una metrica rigida collegata (ovvero un tempo di risposta non superiore a 100 ms). I requisiti NF non sono anche dettagli di implementazione o attività come "aggiornare il framework ORM" - nessun indizio su dove qualcuno avrebbe avuto quell'idea.

Maggiori dettagli su Wikipedia: Requisiti non funzionali .

Per affrontare in modo specifico gli esempi nella domanda:

1. Nell'elenco dei dispositivi selezionati, il dispositivo può essere ripetuto.

   • Chiaramente un requisito funzionale. Descrive l'aspetto dell'output del sistema.

2. Il database deve contenere almeno 100 articoli

   • Sembra una regola aziendale, quindi anche un requisito funzionale. Tuttavia, sembra incompleto. Qual è la ragione di questa regola? Cosa succederà / dovrebbe accadere se il database contiene meno di 100 elementi?

3. La valuta di un certo valore deve essere in dollari USA.

   • Requisito funzionale, ma in realtà non dichiarato correttamente. Una formulazione più utile sarebbe: il sistema deve supportare una valuta (USD). Ovviamente questo sarebbe modificato se fosse necessario supportare più di una valuta e quindi il requisito dovrebbe includere informazioni sulle conversioni di valuta e così via.

4. Il dispositivo deve avere un nome e un valore di consumo energetico in Watt.

   • Non proprio alcun tipo di requisito, è più simile a una specifica tecnica. Un requisito funzionale sarebbe indicato poiché la potenza nominale è considerata in Watt. Se esiste più di una UOM, quindi come per la valuta, i requisiti funzionali dovrebbero avere sezioni sulle conversioni di unità, dove / come sono configurate, ecc. (Se applicabile).

Aaronaught ha già un'ottima risposta, ma poiché c'erano altre risposte, ora rimosse, che erano totalmente sbagliate su ciò che è un requisito non funzionale, penso che sarebbe utile aggiungere alcune spiegazioni per evitare gli errori su ciò che un requisito non funzionale è.

Un requisito non funzionale è "una qualità o proprietà che il prodotto deve avere" ¹. James Taylor afferma che un requisito non funzionale "[...] è [nondimeno] un requisito ed è importante per il cliente, a volte anche più importante di un requisito funzionale" . Dà quindi due esempi: il logo del prodotto e l'accuratezza e l'affidabilità dell'attrezzatura. Questi due esempi mostrano molto bene che:

• I requisiti non funzionali non sono un jibber-jabber di marketing come: "Internet è importante al giorno d'oggi e vogliamo un sito Web".
• I requisiti non funzionali riguardano i clienti, poiché possono avere un forte impatto sulla loro produttività e sulla capacità stessa di utilizzare il prodotto.
• I requisiti non funzionali sono totalmente obiettivi.

L'ultimo punto è essenziale. Se il requisito è soggettivo, non ha nulla a che fare nell'elenco dei requisiti. Sarebbe impossibile costruire test di validazione da qualcosa di soggettivo . L'unico scopo dell'elenco dei requisiti è quello di elencare le aspettative non ambigue del cliente. "Voglio che questo quadrato sia rosso" è un requisito. "Voglio che questo quadrato abbia un bel colore" è un desiderio che richiede una spiegazione.

Ricorda che l'elenco dei requisiti è come un contratto (e nella maggior parte dei casi fa parte di un contratto). È firmato dal cliente e dalla società di sviluppo e, in caso di controversia, verrà utilizzato legalmente per determinare se hai svolto correttamente il tuo lavoro. Che cosa succede se ti ordino un prodotto software, specifica che "il prodotto deve essere eccezionale" e rifiuta di pagare al termine del prodotto, perché per me ciò che hai effettivamente fatto non è eccezionale prodotto ?

Quindi, vediamo alcuni esempi.

  1. Il prodotto software risponde all'utente finale.

Questo non è un requisito. Non funzionale. Non non funzionale. Non è solo un requisito. Affatto. Ha valore zero. Non è possibile verificare se il sistema software soddisfa questo requisito durante i test di convalida. Né tu - il dipartimento QA, né il cliente.

  2. Il ricaricamento delle statistiche utente esegue il 90% delle volte al di sotto di 100 ms. quando testato sulla macchina con le prestazioni specificate nell'appendice G parte 2 e il carico inferiore al 10% per la CPU, inferiore al 50% per la memoria e nessuna operazione di disco R / W attiva.

È un requisito. Se l'appendice G parte 2 è abbastanza precisa, posso prendere la macchina con l'hardware simile ed eseguire il test di validazione nel dipartimento di controllo qualità e otterrò sempre un risultato binario: superato o fallito.

È un requisito funzionale? No. Non specifica cosa deve fare il sistema. Probabilmente prima esistevano requisiti funzionali, che specificavano che l'applicazione software doveva essere in grado di ricaricare le statistiche degli utenti.

È un requisito non funzionale? È. Specifica una proprietà che deve avere un prodotto, ovvero il tempo di risposta massimo / medio, data la soglia percentuale.

  3. L'applicazione è scritta in C #.

È un requisito? Non lo sappiamo davvero senza contesto. Potrebbe essere un desiderio dello sviluppatore principale, che, inserendo questo requisito, desidera evitare in seguito una discussione con i suoi colleghi sulla lingua da utilizzare. Potrebbe anche essere un requisito basato su hardware / software, elementi legacy o di compatibilità. Non lo sappiamo.

  4. La base di codice C # del prodotto segue le Regole minime consigliate di Microsoft e le Regole di globalizzazione di Microsoft.

Questa è una cosa strana Personalmente, preferirei non definirlo un requisito e inserirlo in un documento separato che specifica gli standard e le migliori pratiche.

  5. La finestra principale dell'applicazione ha un bordo blu (# 00f) 10px con cerchi rosa (#fcc) riempiti, quei cerchi posizionati sul bordo interno del bordo e con un diametro di 3px, separati da 20px l'uno dall'altro.

È un requisito e non funzionale. Specifica qualcosa che possiamo testare durante il test di validazione e specifica una proprietà del prodotto, non ciò che il prodotto è destinato a fare.

  6. Il sistema di localizzazione del veicolo misura la velocità con una precisione di ± 0,016 mph.

Anche un requisito non funzionale. Fornisce una soglia misurabile della precisione del sistema. Non dice cosa deve fare il sistema, ma dice quanto preciso sta facendo il suo lavoro. Ma aspetta? Dice che il sistema di localizzazione del veicolo misura la velocità, no? Quindi è anche un requisito funzionale? Bene, no, poiché mettiamo l'accento sulla precisione della misurazione, non sul fatto che la misurazione sia stata eseguita.

  7. Il sistema di localizzazione del veicolo misura la velocità del veicolo.

Ora è un requisito funzionale. Non dice come funziona il sistema, ma cosa sta facendo. Attraverso requisiti funzionali, potremmo apprendere che il sistema di localizzazione del veicolo misura la velocità, la potenza della batteria, la pressione di non so cosa e se le luci sono accese o meno.

  8. Le pagine del sito Web richiedono 850 ms. caricare.

Questo non è un requisito. Cerca di essere uno, ma è totalmente non valido. Come valuteresti questo? Quali pagine? Tutti? Testato attraverso una rete locale da 1 Gbps su una macchina client quad-core e un server a otto core con SSD utilizzati al 2% o tramite un modem di un laptop vecchio e scadente mentre il sito Web è ospitato da un piccolo server utilizzato al 99% ? Cosa si intende per "caricare"? Significa scaricare la pagina? Scaricarlo e visualizzarlo? Invio della richiesta POST con alcuni dati di grandi dimensioni, quindi caricamento della risposta e visualizzazione?

Per concludere, un requisito non funzionale è sempre un requisito, il che significa che descrive qualcosa che è totalmente obiettivo e può essere verificato attraverso un test di validazione automatizzato o manuale, ma invece di dire cosa sta facendo il sistema, spiega come il sistema sta facendo qualcosa o come è il sistema stesso .

^{¹ Gestione dei progetti informatici: applicazione delle strategie di gestione dei progetti alle iniziative di software, hardware e integrazione, James Taylor, ISBN: 0814408117.}

Un requisito funzionale descrive il risultato dell'interazione con il sistema (cosa fa il sistema in determinate situazioni), mentre il requisito non funzionale di solito si riferisce a specifiche di prestazioni, capacità, tempo di risposta, ecc ... cose che non rappresentano funzionalità, un processo nel sistema o il risultato di un'interazione.

Detto questo, il requisito non funzionale che stai descrivendo è in realtà un requisito funzionale con una specifica tecnica (che in realtà lo renderebbe un cattivo requisito). Un esempio di requisito non funzionale per il tuo caso potrebbe essere qualcosa del genere:

- L'interfaccia utente non deve essere bloccata mentre è in esecuzione l'animazione dei dadi.

I requisiti utente sono in genere requisiti UI specifici, che a seconda del contesto sarebbero funzionali o non funzionali, mentre i requisiti di sistema (capacità utente simultanea, ad esempio) sono generalmente non funzionali.

Solo per aggiungere ad alcune buone risposte esistenti che i requisiti non funzionali sono talvolta chiamati "ilicità" - qualità che il sistema deve possedere in aggiunta alla sua semplice funzionalità. Le "ilicità" comprendono disponibilità, usabilità, sicurezza, flessibilità e un'estetica ancora più soggettiva.

Alcuni di questi sono molto difficili da specificare e valutare. Tuttavia, contano. Se ti stai iscrivendo a loro contrattualmente, allora vorrai evitare le versioni senza senso ondulate a mano, ad esempio "Il sistema deve essere sicuro". Il problema con il tentativo di inchiodare tali requisiti è che le persone tendono a gravitare sulle cose che sono facilmente misurabili, piuttosto che sulle cose che contano (e i requisiti possono essere scritti da persone che non hanno alcuna base nelle specialità pertinenti ). Il risultato finale è che generalmente si finisce con sistemi che non sono né sicuri, utilizzabili né flessibili (la disponibilità non è così difficile da specificare e misurare, anche se causa ancora molti mal di testa).

Ci sono differenze culturali qui tra persone che si occupano di contratti e cose formali, e persone che si occupano di analisi, architettura, ricerca più generali ecc. Un requisito vago e ondulato è ancora un requisito per quanto riguarda quest'ultimo, perché esprime cose che contano per il cliente, anche se simpatizzano completamente con la gente contrattuale che non è un requisito contrattuale utile fino a quando non sarà esplorato in dettaglio e accuratamente inchiodato.

Un ultimo punto: se non puoi (ancora) trovare una misura oggettiva di un "ilicità", ciò non significa che il cliente non ne abbia bisogno. Vago! = Non necessario. Tuttavia, può significare che dobbiamo sviluppare modi migliori per misurare tali cose, ottenere e perfezionare i requisiti non funzionali in modo incrementale o contrattare in modi (Agili ecc.) Che possano funzionare senza misure obiettive iniziali per tutto.

Questi commenti sono tutti molto buoni ma sono troppo cotti e non offrono un modello chiaro con cui lavorare. Non sarebbe chiaro specificarlo come:

A mio avviso, un requisito funzionale è ciò che l'utente prova durante l'utilizzo dell'applicazione. È un requisito che deve essere soddisfatto quando uno sviluppatore tenta di implementarlo da zero, apportare miglioramenti o modifiche. Ad esempio: l'utente dovrebbe accedere. Supponiamo che se si aggiunge anche un nuovo modo per eseguire l'applicazione tramite un prompt dei comandi, l'utente deve comunque effettuare l'accesso.

Un requisito non funzionale si verifica sotto il cofano. L'utente non ne è a conoscenza, ma deve essere presente ma è implementato. Ad esempio: l'applicazione deve essere sviluppata in C #. Se è sviluppato in qualsiasi altra lingua, l'utente non se ne accorgerà. Ma questo può essere un requisito perché si basa sul codice esistente. Un altro esempio potrebbe essere che deve essere installato su un determinato server. Lo spostamento dei server non verrebbe notato dall'utente.

Funzionale o non funzionale? Non direi nessuno dei due. La maggior parte, se non tutti gli esempi elencati, mi sembrano regole di business (specificando i vincoli relativi al processo e le regole decisionali che i processi di sistema devono seguire).

Sono qualcosa di cui molti ingegneri dimenticano o di cui non sono a conoscenza, in quanto le regole aziendali vengono in genere raccolte come parte dell'analisi aziendale (e spesso incorporate nelle specifiche dei requisiti funzionali piuttosto che referenziate esternamente).

Un requisito funzionale è in genere qualcosa che il sistema può o farà. Può essere espresso come risultato di un'azione (di un risultato negativo). Un requisito non obbligatorio è qualcosa di cui il cliente / utente finale non si preoccupa e non influisce sul risultato, ad esempio
Windows avrà un bordo blu con punti rosa. - Il programma sarà scritto in Java
- Tutto a che fare con standard di codifica, metodi e processo.

Attenzione però che i requisiti non funzionali possono essere trasformati in requisiti funzionali dai clienti. esempi potrebbero essere: il programma sarà scritto in Erlang perché il cliente legge un articolo di rivista e lo vuole scritto in Erlang. - Il programma deve utilizzare DB 2. poiché il cliente lo eseguirà sui suoi sistemi DB 2 esistenti, ha anni di esperienza e un team IT che ha familiarità con quella piattaforma.
- Il codice sorgente deve superare tutte le raccomandazioni MISRA.

In sintesi: se il cliente se ne preoccupa, è un requisito funzionale, altrimenti è un requisito non funzionale o forse nemmeno un requisito.

penso che i requisiti funzionali siano una cosa necessaria che descriva il sistema e il suo comportamento, ma i requisiti non funzionali al sistema non sono necessari e non raccolti durante le negoziazioni per la progettazione del sistema sono solo il risultato del sistema come la velocità di copertura della qualità , sicurezza, manutenibilità ecc. dal sistema costruito.