Miglioramento dei requisiti
In un mondo ideale tutti i requisiti sono perfetti e implementabili, ma nella realtà alcuni di essi dovranno essere rifiniti, consolidati o rimossi in modo da ottenere una solida serie di requisiti. Valutando ogni requisito è possibile cercare aree di miglioramento.
Nel processo di valutazione, provare a porsi le seguenti domande:
I requisiti sono chiari e completi?
Esistono lacune note da colmare che però non sono state acquisite nei requisiti?
Sono state incluse tutte le esigenze normative e di conformità?
Questo requisito è un duplicato di un altro e andrebbe consolidato?
Il requisito include componenti che non rientrano nell'ambito?
Il requisito include una progettazione/implementazione specifica?
Il requisito specifica in che modo il sistema legacy ha gestito il problema ma non descrive il problema aziendale effettivo?
I requisiti hanno lo scopo di spiegare il problema da risolvere, non come risolverlo. La risoluzione del problema avviene esaminando tutti i requisiti e mappandoli a una soluzione come parte del processo di progettazione. Gli utenti che forniscono i requisiti non dovrebbero aver bisogno di sapere come verrà risolto il problema quando forniscono il loro input.
Esempio: include specifiche di progettazione
Questo esempio descrive un requisito che include specifiche di progettazione.
Il responsabile dell'account del cliente riceverà una notifica tramite e-mail da un flusso di Microsoft Power Automate attivato dalla creazione di un nuovo caso in Dynamics 365 quando il responsabile è il proprietario della riga dell'account in Microsoft Dataverse.
Questo requisito avrebbe potuto essere più semplicemente formulato come: Il responsabile dell'account del cliente desidera ricevere una notifica quando il cliente apre un nuovo caso.
Quando possibile, cercare di circoscrivere un requisito a cosa, chi e perché ed evitare di includere le procedure previste nella nuova soluzione. Elevando la discussione alle esigenze aziendali, si otterrà una comprensione più chiara del problema da risolvere. In molti casi potrebbe essere disponibile un modo migliore per implementare il requisito rispetto a come fatto nel sistema legacy.
Esempio: dettagli mancanti
Questo esempio descrive un requisito a cui mancano dettagli.
Gli account non avranno un limite di credito elevato durante il primo anno come clienti.
Così come formulato, questo requisito non è implementabile perché non si conosce il limite e cosa si intende per elevato. Inoltre, questo aspetto renderebbe il requisito non verificabile. Il vero requisito per un limite potrebbe essere semplice, come un valore reale di 2 milioni di USD, oppure più complesso, come un limite per ciascuna area geografica. In quest'ultimo caso aumenta la complessità generale del requisito. Sebbene questo esempio sia semplice, è facile immaginare che, se si trattasse di un requisito più complesso, la mancanza di chiarezza potrebbe avere un impatto sull'ambito e sulle risorse del progetto.