Perché è importante includere la definizione di successo / fallimento nelle specifiche?

Why it's important? Can you write any examples of those definitions?

Quando specifichi un requisito, è importante che soddisfi determinate qualità, come la coesione (si occupi solo di una singola cosa), completo (non mancano le informazioni necessarie per soddisfare il risultato desiderato), tracciabile (è documentato e può essere tracciato attraverso la progettazione, l'implementazione e la manutenzione in entrambe le direzioni), aggiornato, fattibile (può essere effettivamente implementato), non ambiguo (più persone che lo leggono avranno la stessa idea del risultato desiderato) e verificabile ( può essere testato e facilmente visibile se il requisito è completo).

Definire i criteri di successo o fallimento per un requisito consente di essere completo, tracciabile, fattibile, non ambiguo e verificabile. Come puoi sapere se il requisito può essere soddisfatto ora o in futuro? Come puoi sapere quando hai implementato la funzionalità o l'aspetto del sistema? Come puoi indicare moduli specifici a qualsiasi livello che implementano il requisito, sia in una rappresentazione del progetto o dell'implementazione?

Questo è in qualche modo correlato al concetto di "definizione di fatto" nel community agile , anche.

Can anybody provide examples of good requirements specification?

Puoi trovare molte informazioni sui requisiti, inclusi gli esempi, in Requisiti software e < a href="http://rads.stackoverflow.com/amzn/click/0735622671"> Ulteriori informazioni sui requisiti software: problemi spinosi e consigli pratici . Inoltre, Impatto sui processi del sito di Wiegers fornisce una serie di chicche , come esempi di documenti e modelli.

"Completa" implica "non ha bisogno di un altro paio di ore / giorni / settimane / mesi per occuparsene finché non è perfetto". È difficile sapere quando passare alla prossima cosa nella pila se non sai mai quando hai finito - il che richiede di sapere esattamente cosa è "fatto". (E passare alla prossima cosa è una buona cosa perché è così che finisci a consegnare ciò che hai promesso).

In realtà è molto difficile descrivere esattamente cosa è necessario per qualcosa essere "completo" - ma avere una lista di successo (se non lo fa non è completo) e un fallimento (se fa così fallisce ) è un buon modo per arrivarci.

Un buon requisito è qualcosa che è per sua stessa natura Testabile . Il requisito stesso definisce la propria metrica di successo o fallimento, il requisito è stato soddisfatto o meno?

Potrebbero esserci 1 ... n casi di test per un singolo requisito ma se il requisito è ambiguo, soggettivo o congiuntivo (combinando più requisiti usando le congiunzioni), allora non è più Testabile .

Success o Failure sono attributi che verrebbero applicati a un caso di test per un requisito e non al requisito stesso.

The System shall display an error alert to the user if the credential job queue contains 80% or more un-audited documents.

Abbiamo appena iniziato a usare scrum, quindi questa idea di avere una definizione di fatto è nuova per noi, ma è stata molto utile. Per un solo esempio, avevamo una storia utente per ottenere una compilazione compilabile. Sembra chiaro cosa significhi, ma avere una definizione scritta ci ha davvero aiutato. Una parte di questa definizione era avere un altro sviluppatore che lo verificasse dal controllo del codice sorgente e verificarlo compilato senza errori o avvisi da una build pulita. Ciò ha riscontrato un problema in cui ho dimenticato di aggiungere alcuni file nel controllo del codice sorgente, quindi è stato creato sulla mia macchina ma non su altri.

Altre cose che sono venute fuori erano quelle che dovrebbero essere incluse nella build per essere chiamate "fatte". Possiamo lasciare temporaneamente i moduli con molti errori di compilazione che richiedono molto tempo per riconciliarsi? Ciò ha portato a una discussione su ciò di cui abbiamo davvero bisogno a questo punto del nostro ciclo di sviluppo. Senza questa discussione, potremmo o aspettare troppo a lungo per una build "perfetta", o chiamare erroneamente una build eseguita che è completamente inutilizzabile dal resto del team.

In altre parole, una definizione di successo fa sì che tutti sappiamo cosa aspettarsi e cosa non aspettarsi quando abbiamo finito. Se fa la differenza in qualcosa di così semplice come compilare una build all'inizio di un progetto, questo renderà molto più una differenza sui requisiti che il cliente si preoccupa veramente.