La chiave per scrivere buoni requisiti è avere un test di accettazione chiaro e non ambiguo su ogni singolo requisito che non sia soggetto a interpretazione, in modo da poter dichiarare il successo.
Dal punto di vista del cliente, i requisiti sono abbastanza buoni quando dipingono chiaramente un'immagine di ciò che fa il software, di come appare e di quali obiettivi aziendali realizza. Di solito, ciò richiede casi d'uso, mockup e procedure dettagliate per l'interfaccia utente e rapporti di esempio.
Dal punto di vista dello sviluppatore, i requisiti sono sufficienti quando gli sviluppatori software comprendono chiaramente cosa devono fare per creare l'applicazione. Quindi, in aggiunta a ciò che il cliente vede, come sviluppatore mi piacerebbe anche vedere l'architettura e la struttura generale, le API e le interfacce, i singoli elementi strutturali, le funzioni aziendali e il modo in cui tutti parlano l'un l'altro, in modo sufficientemente dettagliato Posso iniziare a scrivere metodi e classi (ognuno dei quali ha le proprie specifiche, anche se è solo sotto forma di test di unità).
La quantità di dettagli necessaria per ottenere questo risultato varia da squadra a squadra. Ad esempio, il livello di rigore nelle specifiche dei requisiti per i team offshore è molto maggiore di un team di scrum interno ben affiatato.