come filtrare i requisiti 'must-have' dai requisiti 'nice-to-have' [duplicato]

Question

come filtrare i requisiti 'must-have' dai requisiti 'nice-to-have' [duplicato]

#1 da (5 voti)

3

Nella creazione di un software da zero, è necessario condurre una valutazione dettagliata dei bisogni e scoprire quali sono i bisogni dei dei nostri clienti / dei propri

.

Quando intervisti gli utenti finali, organizzi workshop o partecipi direttamente ai processi aziendali per i quali il software è scritto, ci sono molti requisiti che sono molto importanti, sono requisiti "da avere".

Nello stesso processo, i client chiamano alcune funzionalità, che sono correlate al software, ma non sembrano risolvere alcun problema, quindi diciamo "belle cose da avere"., ad es. avere la possibilità di cambiare il colore dell'interfaccia, o essere in grado di gestire alcuni processi che il software potrebbe fare senza la loro interferenza.

Ci dovrebbe essere qualche schema per gestire questo tipo di requisiti. Come distinguere tra questi 2 tipi di funzionalità? Come stimare una funzionalità aggiuntiva aggiunge valore al software o è solo un ampliamento del campo di applicazione del progetto?

Inoltre, come persuadere i clienti che le funzionalità "piacevoli da avere" sono in qualche modo utili, ma non proprio necessarie.

requirements client-relations requirements-management

posta saakian 15.02.2014 - 15:25

fonte

1 risposta

Leggi altre domande sui tag requirements client-relations requirements-management

Qual è il modo più pratico per aggiungere funzionalità a questo pezzo di codice? Qual è la differenza tra il profilo UML Data e il modello ER?

score 5 · Accepted Answer

Sono i clienti. Possono decidere cosa vogliono e cosa non vogliono. Il modo in cui li ottieni per dirti quello di cui non hanno veramente bisogno è di allegare le stime del tempo e del dollaro alle funzioni non necessarie. Capiranno rapidamente quali caratteristiche sono davvero importanti per loro.

Prima di firmare un contratto con un cliente che coinvolga denaro, è necessario conoscere lo scopo specifico del lavoro e quanto il cliente dovrà pagare per quel lavoro. Una volta che il contratto è stato firmato, è molto difficile ottenere delle modifiche all'ammontare di denaro che il cliente pagherà, quindi devi costruire qualcosa nel contratto che permetta loro di aggiungere funzionalità a un prezzo o limitare l'ambito in modo tale che non possano aggiungere funzionalità una volta concordato il prezzo.

Se non si conosce l'ambito del lavoro, il modo in cui lo si scopre è raccogliere i requisiti del cliente e quindi sviluppare una Specifica di progettazione software (o ciò che si chiama la "analisi dei bisogni") in modo che sia possibile mappare fuori quanto tempo ci vorrà per soddisfare ogni requisito. Caricalo per preparare l'analisi dei bisogni, su base oraria. Questo deve essere fatto prima un prezzo è concordato.

Costruisci i tuoi requisiti in modo che ogni requisito debba superare un test di accettazione specificato dal cliente. Se passa il loro test, dichiari che il requisito è stato completato. Questo impedisce loro di tornare e dire "Beh, so che è quello che ho detto che volevo, ma quello che volevo davvero è questo".