Tecnica di elicitazione dei requisiti per requisiti impliciti

Mostra loro ciò che stai pensando.

Puoi provare a scrivere la tua comprensione con parole tue, ma i prototipi sono i miei preferiti per questo. Ho perfezionato il design di siti Web utilizzando carta, forbici e nastro. Tutto ciò che consente al cliente di vedere rapidamente quello che hai in mente funzionerà. Ottieni la tua comprensione di fronte a loro il più velocemente possibile. Non provare nemmeno ad avere ragione la prima volta. Cerca di sbagliare il più rapidamente possibile.

Mostrare al cliente come hai sbagliato farà emergere i requisiti mancanti. Quindi fai di nuovo tutto.

Una possibile opzione è quella di camminare davvero un miglio nei loro panni. Chiedi loro di lasciarti fare il lavoro che vogliono fare con il vecchio software (o senza) per un giorno. Forse non è possibile fare effettivamente il lavoro, forse ci vuole uno skillset, un'istruzione o un permesso che non hai, ma poi vai ad osservarli.

Molte cose sono incredibilmente ovvie quando la si sperimenta. Ad esempio, ogni linea guida ti dirà quanto dovrebbe essere grande un pulsante ... ma una volta che sei in quel magazzino in quella specifica stazione e ti accorgi di avere un grosso coltello in una mano e un grande guanto sull'altro, sai che quel pulsante dovrà impiegare metà dello schermo per consentire alle persone di lavorare più facilmente, indipendentemente dagli standard del tuo framework. Probabilmente non avrai una persona che dice "quel pulsante 'Prossimo elemento' deve essere utilizzabile con una sola mano libera e quella mano ha un guanto di posta". Perché la gente seduta a una scrivania con te in una bella maglietta che discute le esigenze probabilmente non ha mai funzionato laggiù sul pavimento. Ma lo vedrai vedilo quando lo fai.

@CandiedOrange inchioda il più importante, ma ce ne sono altri ancora, soprattutto se questo è per un esame:)

Una cosa è costruire una rappresentazione più strutturata dei requisiti, uno schema di classe, stato o flusso di dati o un modello di dominio. Questo può aiutarti a vedere dove sono le lacune e puoi chiedere chiarimenti. Ci sono anche molte specifiche formali lingue come Z .

Un altro è osservare il loro processo attuale. Questo include cose come guardare i loro sistemi esistenti, contratti con i clienti, osservare letteralmente le persone che lavorano e persino guardare il loro materiale di marketing per assicurarsi che il nuovo sistema fornisca le funzionalità di cui hanno bisogno / stanno promettendo agli altri.

Come tecnica utile che ho raccolto per convincere la gente a pensare in modo più specifico, è cercare di trovare una funzionalità dubbia implicita nei requisiti attuali e quindi chiedere al cliente. "Quindi chiunque può davvero modificare il timecard di chiunque altro o in realtà abbiamo bisogno di più di un livello di accesso?"

Ecco una bella buona panoramica dal punto di vista accademico.