D: I team di QA si concentrano e i requisiti funzionali, mentre il team di sviluppo si concentra principalmente sulle specifiche funzionali, anche se devono avere una comprensione dei requisiti funzionali?
I due sono strettamente correlati. Per piccoli sforzi, i requisiti possono essere sviluppati a un livello di dettaglio in cui possono anche essere utilizzati come specifiche. In generale, i Requisiti funzionali sono la dichiarazione incentrata sul cliente di ciò che un sistema dovrebbe fare. Specifiche funzionali sono una descrizione più dettagliata dei Requisiti funzionali . Ad esempio:
- Rqmt: il cliente deve essere in grado di modificare la temperatura limite superiore di allarme
- Spec: Selezionando la voce parameter :: alarms :: temperature verrà visualizzato un modulo a comparsa che consente all'utente di immettere un valore compreso tra 50 e 100 per il limite di allarme.
Le specifiche funzionali sono ancora nel regno di descrivere cosa fa un sistema, non come lo fa. Per questo motivo, i team di controllo qualità dovrebbero essere interessati alle Specifiche funzionali per diversi motivi, tra cui:
- Il team addetto al controllo qualità deve garantire che siano state esaminate le revisioni appropriate per determinare che le Specifiche funzionali siano coerenti con i requisiti e che siano complete.
- Ciascuna Specifiche funzionali è testabile, quindi il team addetto al controllo qualità deve assicurarsi che i test siano definiti e che il prodotto software passi tali test.
D: Presumo che il QA possa firmare il prodotto finché i requisiti funzionali sono soddisfatti, indipendentemente dal fatto che le specifiche funzionali siano seguite o meno. La mia ipotesi è corretta?
Indipendentemente dal fatto che il QA effettui una firma su un prodotto che devia dalla specifica dipende in parte dal processo seguito quando sono state prese le decisioni per apportare modifiche. Se il team di sviluppo seguiva i processi di cambiamento, il QA non avrebbe avuto problemi. (Nota: questi processi dovrebbero assicurare che si verifichino comunicazioni appropriate su questi cambiamenti). Tuttavia, se un team di sviluppo decolla autonomamente, vi sono molti rischi che, anche se i loro sforzi soddisfano i requisiti, i loro sforzi possono essere rifiutati dal QA, da altre unità aziendali nella loro organizzazione e persino dagli utenti finali.
Questo non vuol dire che un team di sviluppo sia vincolato dalle specifiche. È OK per un team di sviluppo fornire qualcosa che si discosti dalle specifiche originali . Tuttavia, prendendo le decisioni per implementare qualcosa di diverso, ciò che è nelle specifiche dovrebbe essere fatto unilateralmente. Le organizzazioni mature avranno alcuni processi di controllo delle modifiche definiti per adattarsi ai cambiamenti. Il controllo qualità assicurerà che tali processi vengano seguiti.