Quando interrompere la decomposizione funzionale e avviare la progettazione dell'algoritmo

1

In tutta la mia esperienza, scomporre i requisiti funzionali dall'alto verso il basso attraverso una gerarchia e utilizzare con successo quella gerarchia come base per costruire e implementare alcuni sistemi piuttosto interessanti dal basso verso l'alto, mi fa vergognare di ammettere che non ho una garanzia metodo per garantire che tutti i livelli nella gerarchia della decomposizione funzionale siano in quel luogo perfetto per decomporre ulteriormente.

La domanda è: quali sono i flag tangibili o gli indicatori oi segnali da utilizzare che confermano che la scomposizione funzionale di una data foglia è completa e corretta in modo che possa iniziare la progettazione dell'algoritmo.

    
posta Tai Paul 15.01.2015 - 04:04
fonte

2 risposte

3

Continuare a scomporre i requisiti funzionali in requisiti più piccoli fino a quando non sarà possibile scrivere un test chiaro, specifico e misurabile per ogni piccolo requisito in modo che, quando il test viene eseguito e superato, sia il cliente sia i team di sviluppo / QA possano dichiarare inequivocabilmente che il requisito è stato rispettato.

    
risposta data 15.01.2015 - 05:19
fonte
1

Un requisito descrive qualcosa a cui un software deve conformarsi, indipendentemente da come è scritto il software. Esempio: " In qualità di addetto alle vendite, devo registrare l'ordine del cliente ".

Si decompongono i requisiti in requisiti a grana più fine, purché questi descrivano ancora il problema e non la soluzione. Esempio: " In qualità di addetto alle vendite, per registrare l'ordine del cliente, devo trovare i record dei clienti esistenti e, se necessario, creare un nuovo record del cliente con identità e indirizzo ".

Non appena inizi a descrivere la soluzione, hai avviato il design . Esempio: " Ho bisogno di inserire il nome nel campo del cliente, e se il nome non è noto, appare un pop up per registrare un nuovo cliente ". Qui descrivi una soluzione e non un requisito: il tuo software potrebbe risolvere il problema in un altro modo, se lo avessi voluto.

Lo slittamento dal mondo problematico nel mondo delle soluzioni non è sempre così ovvio. Come regola generale, dovresti come te stesso: "Potrebbe essere fatto in modo diverso?". Se sì, ci sono possibilità che tu sia già nel design.

    
risposta data 07.02.2017 - 17:03
fonte

Leggi altre domande sui tag