bug: deviazione dai requisiti e deviazione dalle aspettative

But if the expectations are not in requirements, then stakeholder could see a bug everywhere as he expected it to be like this or that..So how can I really know?

Sai quali sono i requisiti leggendo i requisiti. (Potrebbero esserci anche requisiti non dichiarati, cioè cose così ovvie che nessuno si è preso la briga di scriverli, ma questi possono essere problematici: vedi sotto.)

Sapete quali erano le aspettative dell'utente / state chiedendo all'utente.

Se un aspettativa insoddisfatta degli utenti è un "bug" è davvero una questione di discussione tra i portatori di interesse.

Sfortunatamente, molti fornitori / appaltatori meno scrupolosi di software giocheranno con la palla dura su ragionevoli aspettative degli utenti che non sono requisiti scritti. Ma il rovescio della medaglia è che alcuni clienti meno che scrupolosi sono pronti a giocare a giochi di cambiamento di costo / colpa facendo finta che le aspettative siano requisiti non dichiarati.

In generale, una deviazione dalle aspettative sarebbe considerata un errore solo se le aspettative erano ovvie e ragionevoli. Ad esempio, se l'applicazione è per la pianificazione degli appuntamenti medici, prendere chiaramente 10 minuti per fissare un appuntamento sarebbe irragionevole. Ma se i requisiti non specificavano un intervallo di tempo, non sarebbe una deviazione dai requisiti.

So che è un po 'vecchia scuola, ma (nel complesso) le incomprensioni su cosa deve fare qualcosa devono essere ordinate da uno dei due documenti:

• Specifica dei requisiti del software (Questo è ciò che pensiamo di aver chiesto)
• Specifica di progettazione software (questo è il modo in cui lo faremo)

Entrambi dovrebbero avere l'approvazione del cliente e l'acquisto.

Ma con sistemi di sviluppo più "flessibili" (Agile, Scrum, ecc.) il ciclo di vita formale sta scomparendo. Questo (IMHO) è un ritorno al "selvaggio west" dell'Ingegneria del software dei primi tempi.

Ciò ha portato alla legge di Andrew sulla gestione dei progetti:

We don't have time/budget/resources to do it right the first time, but we'll find the time/budget/resources to do it a second (and probably a third) time.

In un mondo ideale, i requisiti devono essere il più completi possibile e non ci sarebbe alcuna deviazione dalle aspettative, poiché tutte le aspettative sarebbero tradotte in requisiti.

Nel mondo reale, d'altra parte, i requisiti sono spesso incompleti, il che lascia spazio a aspettative non scritte. Esempi:

1. Un'applicazione impiega dieci minuti per eseguire il compito più semplice, rendendolo totalmente inutilizzabile (vedere la risposta di David Schwartz sopra).

2. Un'applicazione ha pulsanti blu, mentre lo stakeholder odia il blu e il suo colore preferito è il giallo.

3. Tutte le password dell'utente sono archiviate in testo normale e mostrate a tutti coloro che eseguono la procedura "Password dimenticata".

4. Il design visivo fa schifo.

5. L'applicazione invia informazioni sensibili allo sviluppatore. Lo sviluppatore ha anche un accesso backdoor all'applicazione, permettendogli di fare quello che vuole.

Hai notato che alcune aspettative sono tradotte molto facilmente in requisiti . Ad esempio, il primo può essere verificato con un semplice requisito non funzionale relativo alle prestazioni:

The loading of [...] performs 85% of the time below 500 ms. when tested on machine with the performances specified in appendix G part 2 and the load below 15% for the CPU, below 40% for memory and no active R/W disk operations.

Gli altri non hanno bisogno di uno, ma di diversi requisiti . Ad esempio, il terzo non può essere espresso come:

The system is secure.

o

Passwords are stored in a secure way.

poiché entrambi non sono i requisiti: non sono abbastanza precisi e sono soggetti a interpretazione; non possono essere testati oggettivamente. Ciò significa che è necessario un requisito relativo all'algoritmo di hashing e diversi requisiti su come la procedura "Forgot my password" funziona generando una password con un generatore di numeri pseudo-casuali crittograficamente sicuro, quindi inviandolo via email.

Inoltre, alcune aspettative sono vicine all'obiettività di altre. Almeno, molte persone sarebbero d'accordo sul fatto che il quinto esempio illustra qualcosa di dannoso: uno sviluppatore non deve avere un accesso completo alle informazioni sensibili , specialmente quando non lavora più al progetto. Lo stesso non è vero per il punto 4, e ancora di più per il punto 2: il colore preferito è qualcosa di personale e non può essere una ragionevole aspettativa non scritta per un progetto.

L'obiettività risponde alla tua domanda "[Il] stakeholder potrebbe vedere ovunque un bug come si aspettava che fosse così o così ... Come posso davvero saperlo?":

• Se la maggior parte delle persone ha la stessa aspettativa per lo stesso prodotto, allora potresti voler implementare l'aspettativa. Se hai salvato tutte le password in testo semplice, sta a te correggere questo e per sostenere il costo delle conseguenze. Se, d'altra parte, li hai hash con SHA512, ma non hai usato il sale, lo stakeholder non sarebbe stato in grado di dichiararlo come un bug solo perché si aspettava che fosse usato PBKDF2.

• Se diverse persone hanno opinioni diverse, lo stakeholder dovrebbe aver scritto requisiti più completi , dal momento che non è possibile conoscere il gusto dello stakeholder.

Nota: ricorda di fare la differenza tra aspettative di buon senso e aspettative di pratica comune .

Alcuni requisiti sono spesso omessi perché coprono una pratica comune, prevista da qualsiasi sviluppatore decente. Deviando da quelle pratiche, giustificandolo dal fatto che non ci sono requisiti, sarebbe poco professionale. Ad esempio, non vedo la necessità di specificare che un sito Web non deve avere SQL Injection, a meno che non lavori con programmatori molto inesperti.

Perché questi requisiti sono omessi? Perché sarebbe costoso descrivere tutto. Dobbiamo dire che un'applicazione web dovrebbe usare HTTP? Dobbiamo dire che deve usare un database? O che non si salvano file di lunghezza 1 GB in un RDBMS, a meno che non si usi la funzionalità FILESTREAM di Microsoft SQL Server?

• Esempio di aspettativa di buon senso: "Un sito web dovrebbe essere accessibile da qualsiasi luogo, non solo da localhost". Beh, sì, questo è quello che i siti web sono per.

• Esempio di un'aspettativa pratica comune: "Un sito web deve utilizzare HTML 4, HTML 5 o XHTML." Infatti, scritti da zero, i siti HTML 3 sono piuttosto rari quei giorni.

Il requisito è l'interfaccia tra l'aspettativa e il prodotto sviluppato: Expectation - > Requisito - > Prodotto

se un prodotto devia dalle aspettative, in realtà include due condizioni.

Deviazione tra requisito e prodotto : è un ovvio "bug".

Deviazione tra requisito e aspettativa : come definire se si tratta di un bug? Preferisco la risposta di MainMa: il requisito è spesso incompleto, quindi se la maggior parte delle persone ha la stessa aspettativa per lo stesso prodotto, allora si potrebbe desiderare di implementare l'aspettativa, anche se non è definita nei requisiti.

Aggiungo un caso: l'aspettativa è andata persa quando è stata trasferita al requisito. Questi bug sono definiti come un bug dall'analisi o un bug a livello di sistema.