Durante l’analisi spesso la confusione tra i due domini causa problemi, questo perché spesso chi fa l’analista non è un vero analista, (nel peggiore dei casi è uno sviluppatore) e quindi tende sempre a vedere la soluzione prima del problema.
Il buon analista invece conosce la distinzione e durante la raccolta dei requisiti non cade nella trappola di “sbirciare alla possibile soluzione”. Prendiamo un esempio: l’utente o comunque la persona che stiamo intervistando per l’elicitazione dei requisiti dice:
“Quando inserisco un Nuovo Candidato voglio avere una combo per scegliere il valore di XXX”.
Prendere questo come requisito è probabilmente sbagliato, sia perché si parla già di interfaccia utente, ma soprattutto può incorrere in problemi dovuti ad un’analisi insufficiente. Supponiamo infatti che XXX sia “il comune di residenza”…. in questo caso avremmo una combo con tutti i comuni italiani.. una situazione tipicamente difficile da gestire nella UI e sicuramente non usabile.
L’analista dovrebbe quindi chiedere alla persona il perché stia parlando proprio di una combo, questo perché la Combo fa parte del dominio della soluzione, quindi è necessario capire il vero requisito che si nasconde in questa possibile soluzione. Il vantaggio è che in questo modo capiamo realmente le ragioni che portano alla “combo”.
nel vecchio sistema avevamo una casella di testo e perdevamo un sacco di tempo per errori di digitazione,una combo impedisce di mettere valori non validi per cui non avremo più gente che abita a Molano :)
Ora siamo più vicini al vero requisito, che potrebbe essere
L’inserimento del comune di residenza deve essere effettuato tramite la scelta tra X valori possibili e non tramite inserimento libero, perché questo ha creato problemi con il vecchio sistema.
Ora l’analista deve andare più a fondo e chiedere ad esempio: dato che è possibile che ci siano nuovi comuni che vengono creati nel tempo, o comunque supponendo che la lista comuni sia errata, non è proprio possibile per l’utente inserire un valore libero? Si potrebbe magari scoprire che in realtà quello che si vuole è solamente un avvertimento che dica all’utente “Il comune XXX non è presente nell’archivio, verificare errori di digitazione”, ma che sia comunque possibile poi andare avanti. A questo punto il requisito diventa
E’ necessario che prima dell’inserimento dei dati a sistema sia fatto un errore per il controllo di eventuali errori di digitazione per campi specifici.
A questo punto possiamo spostarci nel dominio della soluzione e trovare una soluzione migliore della combobox inizialmente citata, come ad esempio una texbox Ajax che alla digitazione di tre lettere presenta la lista dei comuni compatibili. L’utente può scrivere però quello che vuole, ed alla perdita del focus, se il comune non è in archivio appare un messaggio di “attenzione comune non presente nell’archivio” e l’utente è poi libero di seguire o meno il consiglio.
Evitare di scambiare la soluzione per il problema è quindi fondamentale quando si raccolgono i requisiti.
alk.