Il processo di raccolta dei requisiti

# Che cos'è un requisito

Nel campo della UX, un requisito è tutto ciò che mira a far diventare funzionale e usabile il nostro prodotto, come può ad esempio essere una feature.

Deve essere definito ponendo l'utente al centro del processo di analisi, deve risultare comprensibile a chiunque lo legga, quindi chiaro e mai ambiguo.

E' sempre buona norma documentare i requisiti, sebbene questi siano soggetti a cambiamenti nel tempo. Il mantenimento di tale documentazione deve essere una responsabilità condivisa all'interno del team, poiché il processo di formulazione, scrittura, validazione è l'unico metodo che ci assicura, grazie alle varie iterazioni, che il prodotto finale rispecchi quanto risiede in partenza nella testa del cliente e si avvicini all'idea che l'utente ha del software; in mancanza di ciò si rischia di trattare con superficialità molti aspetti del prodotto, la cui importanza viene rilevata solo in stadi avanzati del ciclo di sviluppo o addirittura a lavoro ultimato.

projectcartoon

Questa famosa illustrazione chiarisce in maniera esemplare cosa avviene quando i requisiti non vengono fissati e lasciati all'interpretazione delle singole persone che lavorano al progetto.

# Tecniche di raccolta

I requisiti nascono grazie al processo di Design Thinking, dalle idee e dalle ipotesi formulate sulla base degli input che ci vengono forniti dal confronto con gli stakeholders (committente, membri del team, utenti) e dalle analisi comparative sul progetto, tra cui:

Brainstorming
Interviste agli stakeholders
Competitive Analysis
User Research
Studio della documentazione
Ricerche e approfondimenti personali

# Tipologie di Requisito

Possiamo vedere i requisiti basandoci su un modello piramidale: in cima abbiamo i requisiti business, requisiti ad alto livello, che descrivono lo scopo del progetto, il punto di vista degli sponsor e del cliente, gli obiettivi economici e aziendali. Abbiamo poi i requisiti utente, che descrivono gli obiettivi e il comportamento dell'utente all'interno dell'applicazione e i bisogni del mondo reale che lo portano ad utilizzarla. Infine a basso livello abbiamo i requisiti di sistema, che possono presentare caratteristiche tecniche ma che devono sempre risultare comprensibili a chiunque sia coinvolto nel progetto.

# Requisiti Business

Un requisito business non identifica un qualcosa che il prodotto deve fare, ma un processo, un obiettivo da soddisfare o il modo in cui raggiungerlo.

Uno UX designers deve collaborare a formalizzare tali requisiti o identificarli in prima persona insieme al cliente quando non sono presenti figure specializzate nell'analisi business.

Le soluzioni user-centric che si vanno a progettare devono conciliarsi con tali obiettivi ed essere sempre mirate al loro raggiungimento.

# Requisiti Utente

Un requisito utente è frutto diretto del processo di UX e dei deliverables che produciamo. In qualità di designer il nostro compito sarà quello di identificare ad esempio i requisiti di sistema e trascriverli in un linguaggio comprensibile a tutti e privo di dettagli tecnici. Possiamo quindi dare per vera l'assunzione che ogni requisito di sistema è anche un requisito utente.

# Requisiti di Sistema

I requisiti di sistema come abbiamo detto devono essere privi di dettagli tecnici particolari, l'onere di portarli ad un livello ancora più basso verrà lasciato poi al team di sviluppo, se riterrà opportuno farlo per un utilizzo interno; ciò non vuol dire che il designer non debba avere conoscenza (anche superficiale) dei linguaggi di programmazione, dei framework, delle librerie e delle api che sono utilizzate. Sulla base della sua conoscenza deve essere in grado di scrivere una documentazione che faccio da ponte tra gli stakeholders.

Possiamo ulteriormente suddividere i requisiti di sistema in funzionali e non funzionali.

# Requisiti funzionali

Identificano una funzionalità o una capacità del prodotto.

E’ bene identificare le funzionalità primarie e quelle secondarie e raccogliere una serie di funzionalità opzionali. Alcuni esempi:

Login alla piattaforma.
Aggiunta di un task ad una lista.
Inserimento di un prodotto in un carrello.

# Requisiti non funzionali

Descrivono il funzionamento e il comportamento del prodotto sotto svariati aspetti, quali possono essere performance, usabilità, interfaccia, look & feel, sicurezza. Ad esempio: