Tecniche
I team di progetto possono utilizzare diverse tecniche per acquisire e gestire i requisiti. Gli elementi di lavoro di Microsoft Azure DevOps e i problemi di GitHub sono comunemente utilizzati dai team di progetto per facilitare la collaborazione sui requisiti. Inoltre, sono disponibili per i team strumenti specializzati nella gestione del backlog e della roadmap. I requisiti vengono acquisiti in questi strumenti o in un documento dei requisiti, in un formato di tipo descrizione o storia dell'utente.
Le storie dell'utente si concentrano su chi è l'utente, cosa desidera e perché vuole che il sistema esegua determinate operazioni.
Ad esempio, "Il venditore deve essere in grado di inviare uno sconto al cliente tramite e-mail".
I requisiti sono spesso classificati in un backlog mentre aspettano l'assegnazione della priorità in uno sprint o un'iterazione attiva del progetto per essere implementati. Si può considerare il backlog come una lista di idee che aspettano di essere implementate, mentre lo sprint o l'iterazione come un periodo di tempo o lavoro definito che è stato raggruppato affinché il team di progetto possa implementarlo nella soluzione.
Durante la pianificazione di uno sprint o un'iterazione, potrebbe essere chiesto di stabilire le priorità e stimare la quantità di lavoro per un elemento di lavoro o un problema nel backlog. I vari team utilizzano approcci diversi per stimare il livello di impegno. Alcuni applicano le ore, mentre altri utilizzano un riferimento, come la taglia della maglietta. In sostanza, per stimare un articolo, è possibile classificarlo come small, medium o large. Quindi, i team utilizzano le dimensioni per raggruppare gli articoli per l'implementazione in uno sprint o un'iterazione.
I requisiti devono poter essere facilmente implementabili e non troppo grandi, in modo da essere completati in un singolo sprint o un'iterazione. È possibile dividere requisiti grandi in requisiti più piccoli che potrebbero essere più facili da soddisfare. Alcune metodologie si riferiscono al requisito grande come epico, che identifica il requisito di alto livello prima che venga suddiviso in parti più piccole.
I requisiti sono spesso considerati come funzionali o non funzionali. I requisiti funzionali descrivono ciò che la soluzione deve fare o i comportamenti. I requisiti non funzionali descrivono di solito aspetti non comportamentali della soluzione, come i requisiti di prestazioni. Per descrivere completamente cosa ci si aspetta da una nuova soluzione, è necessario avere requisiti funzionali e non funzionali.
Requisiti funzionali
I requisiti funzionali devono definire il chi, il che cosa e il perché del requisito. Ad esempio, "Il rappresentante del servizio clienti deve essere in grado di cercare problemi simili di clienti che sono già stati risolti per trovare una soluzione al problema corrente del cliente" descrive un requisito funzionale di Microsoft Dynamics 365 Customer Service.
La maggior parte dei requisiti funzionali proviene dagli utenti della soluzione finalizzata.
I requisiti non funzionali si utilizzano per acquisire argomenti che generalmente interessano agli utenti e che sono importanti per il successo della soluzione. Questi tipi di requisiti riguardano di solito argomenti come le prestazioni della soluzione, la capacità, la privacy, la sicurezza e la conformità.
Ad esempio, "Il sistema deve gestire 2500 segnalazioni simultanee di problemi in entrata dei clienti durante le interruzioni" descrive un requisito non funzionale di Dynamics 365 Customer Service.
Requisiti non funzionali
La maggior parte dei requisiti non funzionali proviene dal reparto IT o di conformità a livello aziendale e non dagli utenti finali.
I requisiti non funzionali devono essere chiari su come misurare e determinare il successo della soluzione. Spesso, i requisiti non includono chiaramente i punti di inizio e fine delle misure per valutare con precisione il successo. È anche comune includere requisiti non funzionali che vanno oltre il proprio controllo, è importante identificare questi requisiti e ridurre i rischi con il cliente. Un esempio di questo scenario potrebbe essere il requisito di prestazioni inferiori al secondo per i dispositivi mobili sul campo.
I requisiti non funzionali sono in genere responsabilità dell'Architetto di soluzioni che determina come soddisfarli. Tuttavia, un consulente dovrebbe essere a conoscenza dei requisiti non funzionali della soluzione. In molti casi, potrebbe essere richiesto di implementare una modifica che supporti l'obiettivo del requisito non funzionale.
È importante prendersi il tempo necessario per garantire che i requisiti siano di alta qualità e rappresentino ciò che ci si è impegnati a fornire. In molti casi, questa garanzia può fare la differenza per il successo della distribuzione di Dynamics 365 dopo aver implementato i requisiti.