Sono confuso con ciò che è diverso tra chiarire e raccogliere. So che usare interviste, osservazioni o questionari può far emergere il requisito che vogliamo, ma come chiarire il requisito funzionale?
Sono confuso con ciò che è diverso tra chiarire e raccogliere. So che usare interviste, osservazioni o questionari può far emergere il requisito che vogliamo, ma come chiarire il requisito funzionale?
Raccogliere i requisiti significa solo questo: raccoglierli.
Chiarire i requisiti significa accertarsi che tali requisiti siano chiari e non ambigui. Avete bisogno di requisiti chiari e non ambigui, in modo che non vi siano controversie con il cliente sul fatto che sia stato fornito o meno qualcosa che è stato richiesto.
Un modo per chiarire i requisiti è scrivere dei test di accettazione. I test di accettazione sono test che, se superano, indicano che il requisito è stato soddisfatto.
// Acceptance Test
public void GetRandomNumber_ShouldReturn4()
{
var result = GetRandomNumber();
Assert.IsEqual(result, 4);
}
// Implementation
public int GetRandomNumber()
{
return 4; // Chosen by fair dice roll. Guaranteed to be random.
}
Se hai difficoltà con cose come scope creep, imprecisioni temporali e dispute sul completamento dei requisiti, un modo per affinare queste cose è scrivere una Specifica di progettazione del software, comprese le classi e le interfacce che occorrerebbe per adempiere requisiti. Questo può essere combinato con l'Ubiquitous Language di DDD per avere una chiara comprensione dell'ambito di un progetto (dal punto di vista degli sviluppatori e del cliente), e cosa serve per dichiarare il successo su ogni requisito.
Ulteriori letture
Requisiti chiarificatori
Leggi altre domande sui tag requirements software