Come trasferisco un cliente dai prototipi dell'interfaccia utente a un insieme di requisiti reali?

Alcune altre cose di cui potresti aver bisogno sono:

• Casi di utilizzo o descrizioni del flusso di lavoro: solo perché sai come appare uno schermo, sai come viene gestito l'input errato? Sai come passare tra gli schermi in TUTTI i casi? Puoi anche includere la gestione degli errori qui.

• Descrizione di sistema di alto livello: Qualcosa che spiega che l'intero sistema a cui sono destinati questi 25 schermi e che cosa fanno.

• Modello dati: è possibile dedurre un modello di dati da queste schermate? Esiste un modello di dati che deve essere utilizzato o sei libero di progettare il tuo per portare a termine il lavoro?

• Requisiti tecnici: le tecnologie specifiche che devono essere utilizzate a causa della licenza o per motivi di integrazione?

• Requisiti di prestazione: se c'è una schermata di ricerca, c'è un'aspettativa di ciò che può essere cercato e quanto dovrebbe essere veloce la risposta? Che dire delle risposte per altri tipi di azioni? Possono o dovrebbero essere alcuni di loro asincroni (l'utente invia un lavoro e torna più tardi)?

• Requisiti di sicurezza: l'applicazione memorizza dati potenzialmente sensibili / personali e, in caso affermativo, quali tipi di dati e cosa deve essere fatto per mantenerlo sicuro? Hai bisogno di rispettare un certo livello di conformità (come la conformità PCI per i pagamenti con carta di credito)?

Inoltre, c'è qualche conoscenza speciale del dominio aziendale che potresti aver bisogno di loro per assisterti? Alcuni settori come l'assicurazione, le banche, i registri sanitari, ecc. Hanno una logica aziendale complessa. Tali progetti non dovrebbero essere tentati senza l'aiuto di un analista di business che conosce quel dominio. Ma se si tratta solo di un carrello / sito di informazioni per i widget generici, potrebbe non essere necessario un membro del team di questo tipo.

Come convincere le persone a capire che i mimi dell'interfaccia utente non sono sufficienti per creare un programma funzionante:

Lo gestirò con un'analogia. Dal momento che sono un po 'pazzo, sto seguendo questa strada.

"Fai finta di nulla sulle macchine, mi passi qualche foto di una Ferrari, una coppia dall'esterno e una dall'interno dell'auto (presa dal posto di guida in modo da poter vedere i comandi dell'auto). mi chiedi di costruirti una Ferrari, torno con una cosa che assomiglia alle immagini e ha tutti i controlli, ma sfortunatamente quei controlli non sono collegati a niente perché (dato che non so nulla delle auto) non lo faccio sapere cosa dovrebbero fare quei controlli. Non posso nemmeno fare un'ipotesi perché non so nemmeno cosa debbano fare le macchine, quindi abbiamo una conversazione come questa:

"Che cosa fa una Ferrari?" "Mi permette di spostarmi da un punto all'altro velocemente." "OK, quindi cosa fa questa cosa circolare?" "Oh, questo è il volante: girandolo, puoi cambiare in che direzione le ruote si trovano all'esterno del punto della vettura, e questo cambierà il modo in cui l'auto si muoverà". "OK, e che mi dici di questa cosa del pedale?" "Quello è il pedale dell'acceleratore, che fa andare il motore più veloce e che fa andare la macchina più veloce". ... qualche minuto dopo ... "Ok, quindi di che tipo di motore ha bisogno? Ho fatto delle ricerche e ho trovato dei motori per i golf cart e alcuni per le auto sportive, che dovrei usare?" ... ecc ... "

Quindi puoi spiegare l'analogia. Passando agli sviluppatori, le schermate di schermate dicono solo loro com'è, non cosa fa. Gli sviluppatori devono sapere quale problema risolve il programma o come verrà usato (come sapere che cosa fa una macchina, rende più facile progettare la macchina e fare ipotesi plausibili su ciò che le cose dovrebbero fare). Hanno bisogno di sapere che tipo di cose dovrebbero usare (cioè il motore del carrello da golf rispetto al motore dell'auto sportiva) e quali altre esigenze non-UI ci sono (la macchina dovrebbe andare veloce).

Cose che vorrei chiedere:

Descrizione del problema generale / di alto livello

Usa casi / storie utente

Requisiti di prestazione

Tecnologie / piattaforma richieste (Windows, Linux, Web)

Tutto FrustratedWithForms ha nella sua risposta

Qualcosa nell'effetto dell'80% dello sforzo di sviluppo va al 20% dei casi di utilizzo marginale. Gli screenshot non ti diranno dei casi d'uso, quindi sarai al buio per l'80% del tuo sviluppo attivo.

È positivo che tu stia cercando di capire di più e cercando di comunicare quanto sia importante che il cliente sia più coinvolto nei requisiti del progetto, tuttavia se non lo fanno, allora stanno creando il progetto per fallimento, e non è colpa tua.

La maggior parte dei progetti software fallisce perché il client non è coinvolto abbastanza nel processo di sviluppo del software. Questo non è un nuovo problema e certamente non è un mistero il motivo per cui i progetti software falliscono, ma si verificano continuamente nel settore a causa di situazioni come questa.

Non puoi semplicemente lanciare un filo di informazioni su un muro e aspettarti di recuperare tutte le tue speranze e i tuoi sogni sotto forma di un pacchetto software. Lo sviluppo del software non funziona in questo modo. Che tu sia un negozio Agile o Waterfall, è necessaria una solida direzione del cliente per il successo o il fallimento di un progetto.

Una cosa che la gente sembra dimenticare di chiedere, è a cosa servono i dati dopo che è stata inserita? Hai bisogno di rapporti? È necessario generare una bolla di accompagnamento e inviarla al magazzino per la spedizione, ecc. Se i dati vengono utilizzati per prendere decisioni sulla gestione e la creazione di rapporti, è necessario modificare la struttura del database. Può anche aggiungere una notevole quantità di tempo allo sviluppo a seconda della complessità dei report.

Devi anche assicurarti che ci sia un percorso per ogni possibile decisione. Quindi se qualcosa richiede l'approvazione della gestione, allora cosa fai se non è approvato e cosa fai se è approvato. Se non è approvato o non approvato nel tempo X, allora cosa succede? Se selezionano un prodotto ed è esaurito, cosa succede all'ordine? Quegli tipi di domande.

Devi anche sapere se ci sono limiti specifici su quali dati devono essere inseriti in ogni campo. Ci sono valori richiesti Da dove vieni ad ottenerli? Come saranno aggiornati? Devi sapere come gestire gli errori. Devi sapere se il database deve avere un controllo o se devi essere in grado di ricreare i dati da una prospettiva storica (torna a quei rapporti fastidiosi).

Un'altra cosa che vedo succedere è che le applicazioni possono essere progettate per arrivare al rilascio senza considerare come verranno mantenuti i dati in seguito. Hai bisogno di una pagina di amministrazione per assicurarti che possano aggiornare i loro elenchi dei valori richiesti? È necessario inviare dati avanti e indietro ad altri sistemi. Come hai intenzione di ottenere i dati iniziali nel database?

Personalmente, chiederei un incontro di mezza giornata con il cliente per illustrare il design dell'interfaccia utente e i loro obiettivi e assicurarsi che tutto fosse allineato.

Inizia semplice. Fagli capire che con le informazioni che ti sono state date, nessuna di queste schermate farebbe nulla . Nessun dettaglio sui casi d'uso, cattivo comportamento di input e così via. Semplicemente non funzionerà. Spiegare una generalizzazione schietta è più facile che spiegare i dettagli, perché il punto non può perdersi. Cercare di fornire loro una giustificazione più complicata del motivo per cui i mockup dello schermo non sono sufficienti offre loro la possibilità di cavillare le definizioni invece di riconoscere il problema. Chiedigli di immaginare che lo sviluppatore di back-end non parla inglese (o in qualsiasi lingua siano presentati gli schermi). Quindi chiedi quanto è diversa questa situazione per uno sviluppatore che ha nessuna conoscenza dei propri processi aziendali. Poi costruisci l'esempio più realistico di te stesso, che ha una certa conoscenza, ma è giustificato nel credere che non sia appropriato per decidere la loro logica di business per loro.

Le persone che non hanno sviluppato software non sanno cosa devono sapere gli sviluppatori software. Non ci si può aspettare che producano specifiche dei requisiti e utilizzino i casi da soli. È necessario applicare tecniche di richieste di elicitazione per ottenere le informazioni che è necessario conoscere. Lavora con il cliente (e auspicabilmente un campione di utenti di vari ruoli) per determinare ciò di cui ha bisogno o desidera. Tecniche comuni per questo sono le interviste e / o l'osservazione degli utenti, l'identificazione dei casi d'uso e delle storie degli utenti e la prototipazione.

Raccomando vivamente di applicare tecniche di sviluppo iterative e incrementali in questo caso, dal momento che si hanno requisiti vaghi, incompleti o poco chiari. Guarda le varie metodologie agili insieme al modello a spirale per affrontare la pianificazione del ciclo di vita.

Inizia ottenendo l'obiettivo aziendale che guida lo sviluppo di questo software. Intervista al cliente e agli utenti e, se puoi, guardali al lavoro. Cerca di determinare quale problema stanno cercando di risolvere. Scopri quali strumenti stanno attualmente utilizzando e come li usano in modo da poter migliorare il loro modo attuale di fare le cose. Approfitta di questa opportunità per imparare il dominio e il suo linguaggio: diventerà infinitamente più facile comunicare se gli sviluppatori di software e i client / utenti parlano tutti la stessa lingua (e non si aspettano che il cliente / gli utenti parlino in termini di software). p>

Dopo aver compreso quali sono gli obiettivi, puoi iniziare a lavorare con i modelli di progettazione dell'interfaccia utente che hai e "decodificare" i casi e le storie degli utenti da loro in base al modo in cui i vari schermi si adattano. Il formato della trama dell'utente probabilmente funzionerebbe bene per affrontare un pubblico non tecnico. Il formato di As a <user type>, I want to <action> so that <reason> funziona in termini di acquisizione di sviluppatori e clienti / utenti che parlano la stessa lingua. Una volta che puoi iniziare a leggere le storie degli utenti, adotterei un approccio di prototipazione allo sviluppo.

Penso che mi avvicinerei a questo con l'uso della prototipazione. Potresti accostarti a un evolutivo prototipazione o prospettiva di prototipazione a perdere , ma prima considererei un approccio di prototipazione evolutiva. Inizia con le storie degli utenti che ti sono più comode e che hai convalidato e inizia a implementarle. Mentre li implementa, ricevi feedback dal cliente e sviluppi nuovi user story, casi d'uso e risoluzione di equivoci.

Inoltre, non pensare a questo come a "implementare un'interfaccia utente con le funzionalità sottostanti". Invece, pensalo come fette verticali sottili. Non implementare tutta l'interfaccia utente contemporaneamente e quindi preoccuparsi delle funzionalità. Al contrario, utilizzare i modelli di interfaccia utente per identificare funzionalità e altri requisiti, quindi implementare una sezione verticale dall'interfaccia utente alla logica aziendale e all'archiviazione dei dati. Ripeti questo per ogni fetta verticale. Dovresti anche sentirti libero di dare suggerimenti per migliorare l'interfaccia utente in base ai requisiti e ai principi di usabilità.

Consiglierei di leggere due libri di Karl Wiegers - Requisiti software e Ulteriori informazioni sui requisiti software . Penso che questi ti aiuteranno con l'ingegneria dei requisiti e le migliori pratiche in questo settore.

Bene, questo è un riferimento iniziale imbarazzante, ma Wikipedia potrebbe essere un posto per te e gli utenti per iniziare su. Il fatto che ci sia una voce su questa roba potrebbe aiutare a convincerli che si tratta di un problema reale, non di essere un dolore.

Più specificamente, sei semplicemente sconcertato su cosa fa l'applicazione, anche dopo aver esaminato i modelli? In tal caso, ammettilo e prova a spiegare che non hai idea di quali dati debba essere visualizzato da ciascun modulo o da dove verrebbero provengono da altri schermi o dati esterni?

Se hai un'idea di qualche , prova a trovare esempi di cose che non sai come fare ("l'elenco di modelli da selezionare sarà un elenco globale o uno qualsiasi dei da parte dell'utente, o qualcos'altro? Se non è da utente dovrei consentire a due persone di modificarlo in una volta? Che cosa dovrebbe mostrare l'interfaccia utente se qualcun altro lo sta modificando? C'è una schermata per questo? Una volta che qualcuno ha usato un modello per qualsiasi i template sono usati per e poi il template viene modificato se il cambiamento viene propagato alla cosa che hanno fatto con il template? ").

Metti in chiaro che con il tuo attuale livello di conoscenza dovrai rispondere a domande circa ogni 90 secondi per il resto del ciclo di sviluppo e che gran parte del tempo non sarai in grado di continuare a lavorare finché non avrai una risposta . L'obiettivo dovrebbe essere quello di chiarire perché avere un qualche tipo di processo renderà tutto più facile. Ricorda anche che Q.A. avrà bisogno delle stesse informazioni che hai, quindi sarà più facile scrivere tutto in modo che sia disponibile per tutti e nessuno dimenticherà nulla.

Potrebbe essere utile ricordare che parte del codice che scrivi influisce su più di uno schermo alla volta, quindi se hai il maggior numero di risposte possibile, potrebbe rendere più facile scrivere quel codice in modo appropriato e non dover cambiare più tardi.

Se ancora non puoi ottenere i requisiti e davvero non sai come procedere, invia email ogni volta che hai bisogno di maggiori informazioni (es. requisiti), e se non puoi continuare a lavorare senza quell'informazione, dichiarare chiaramente che, sfortunatamente, non si è in grado di continuare a lavorare, perché il codice che si deve scrivere sarà molto diverso a seconda della / e risposta / e alla / e domanda / e. Non lamentarti, solo molto professionalmente fagli sapere che non puoi scrivere il programma finché non sai cosa dovrebbe fare.

È necessario conoscere i limiti e gli intervalli per ciascun campo nell'applicazione. Ad esempio, se il campo è un numero di telefono, si aspetta che tu gestisca +1? Quali campi sono richiesti? Cosa vogliono fare l'applicazione se l'utente digita "abc" nel campo numero di telefono? Le 25 schermate sono tutte nell'ordine in cui tutti gli utenti devono procedere?

Altrimenti, crea semplicemente tutto come campi di testo e il gioco è fatto! Vuoi scommettere che andrà avanti come un palloncino principale?