Mapping dei requisiti
Durante la raccolta dei requisiti, un passaggio importante da eseguire consiste nel mappare il requisito alle funzionalità dell'app Dynamics 365. Questa attività è diversa da quella che si eseguirebbe con un software personalizzato o con Microsoft Power Platform per soli progetti in cui la logica dei processi aziendali predefinita non esiste come nelle app Dynamics 365. In Microsoft Dynamics 365 Sales, ad esempio, è già implementato il monitoraggio delle opportunità di vendita, quindi non è necessario creare tale logica. L'attività di mapping consiste nell'esaminare ogni requisito e nel considerare il modo in cui implementarlo. Il mapping si traduce comunemente in una delle categorie seguenti che si applicano al requisito:
Preconfigurato: il requisito, da abilitare o che richiede una configurazione minima, è integrato nell'app Dynamics 365. Il monitoraggio delle opportunità di vendita è un buon esempio di questa categoria.
Configurazione: l'app Dynamics 365 non supporta la configurazione per impostazione predefinita, ma aggiungendo alcune colonne alle tabelle o alcune tabelle personalizzate e probabilmente un po' di automazione, è possibile implementare il requisito. Il requisito, ad esempio, potrebbe essere quello di tenere traccia dell'importo di una commissione su ogni opportunità. È possibile implementare tale requisito con una configurazione senza codice o con uso limitato di codice e probabilmente con un po' di automazione per automatizzare i calcoli.
Personalizzato: l'app Dynamics 365 non supporta la personalizzazione, che è comunque possibile ottenere includendo alcune risorse per sviluppatori di codice per creare una logica o un componente personalizzato. Uno sviluppatore di codice del team, ad esempio, può creare un file Microsoft Power Apps Component Framework per implementare uno strumento di configurazione del prodotto personalizzato nel modulo delle opportunità.
Soluzione partner: molte soluzioni dei partner funzionano con le app Dynamics 365. Uno strumento di configurazione del prodotto, ad esempio, potrebbe provenire da una soluzione partner anziché da una creazione personalizzata.
Questi esempi descrivono categorie che è possibile usare, ma i team non si limitano solo a queste.
Se combinate con il livello di attività e priorità, è possibile usare queste categorie per completare un'analisi corrispondenza-scarto. Un'analisi corrispondenza-scarto è un processo di valutazione dell'adeguatezza di una soluzione per il problema da risolvere. Nelle categorie precedenti, le capacità predefinite sono considerate un "adattamento". Questo aspetto è importante in un'applicazione aziendale come Dynamics 365 perché significa che è possibile adattare ciò che fa l'app. Se la percentuale di "corrispondenza" è bassa, l'app potrebbe non essere un buon punto di partenza per creare la soluzione.
In genere, requisiti che rientrano in forti categorie di tipo configurazione o personalizzato devono essere esaminati per determinare se sono disponibili opzioni per spostarli in categorie più in linea con le funzionalità di tipo preconfigurato, con alcune configurazioni per soddisfare i requisiti unici. Non è raro che i requisiti vengano inizialmente mappati alla categoria di tipo personalizzato perché un cliente ritiene che il comportamento da seguire sia quello del sistema precedente senza rendersi conto che Dynamics 365 differisce leggermente nel supporto preconfigurato. Collaborare con il cliente per negoziare questi requisiti spostandoli verso le funzionalità di tipo preconfigurato può essere vantaggioso.
Un altro vantaggio dell'esercizio di mapping è quello di valutare la fattibilità di un requisito. I motivi comuni per cui i requisiti non sono fattibili includono:
Un numero minimo di persone userà la funzionalità.
La funzionalità non è tecnicamente possibile.
Normative o leggi vietano la funzionalità o il processo.
La valutazione di come verrà implementato un requisito presenta anche il vantaggio di individuare dove potrebbe essere necessario un modello di verifica per identificare le modalità di implementazione. I modelli di verifica implicano in genere la creazione di un esempio della possibile soluzione di un problema, ma non si comportano come una funzionalità pronta per la produzione, sebbene siano sufficienti per valutare se la verifica è valida. Tale verifica può essere applicata anche alla valutazione delle soluzioni dei partner per determinare se risolverebbero il problema. Microsoft AppSource è un sito utile per trovare le soluzioni dei partner.
Indipendentemente dal fatto che si esegua il mapping in modo informale o formale nell'ambito della metodologia di progetto, ottimizzare i requisiti e comprendere meglio il livello di impegno necessario per implementarli possono essere attività preziose.