7.  I requisiti

Sintesi del capitolo

In questo capitolo vengono descritti gli obiettivi del documento di specifica dei requisiti di prodotto, la cui produzione costituisce la fase iniziale di qualsiasi processo di progettazione. L’attività di definizione dei requisiti è scomposta in tre fasi principali. Nella prima, di esplorazione, i requisiti vengono raccolti con modalità diverse (interviste individuali, questionari, focus group, osservazioni sul campo, suggerimenti spontanei degli utenti). Nella seconda, di organizzazione, le osservazioni così raccolte vengono organizzate in una forma coerente, risolvendo eventuali conflitti, nel documento di specifica dei requisiti. Viene proposta una scaletta generale del documento dei requisiti, nel quale rivestono un ruolo particolarmente importante la descrizione degli scenari d’uso principali del prodotto, e la descrizione di tutti i casi d’uso. Nella terza fase, il documento così prodotto è sottoposto a revisione da parte di tutti gli stakeholder del sistema, e approvato dal committente.  

Che cosa sono i requisiti di prodotto

Tutti i processi di progettazione bene organizzati dovrebbero iniziare con la stesura di un documento di requisiti.

Un requisito (dal latino requisitus, richiesto) è una proprietà richiesta, oppure auspicabile, del prodotto. Il documento dei requisiti ha allora lo scopo di accogliere in forma organica una descrizione di tutte le proprietà desiderate. Dalla sua formulazione dovrebbe essere chiaro se un requisito esprime una proprietà obbligatoria, oppure soltanto suggerita o auspicabile. Per esempio, per un sito web di commercio elettronico potremmo identificare, fra gli altri,  i seguenti quattro requisiti:

·      Il sito deve permettere all’utente di inserire nel carrello d’acquisto i prodotti di cui sta valutando l’acquisto. Il carrello deve poter contenere almeno 15 prodotti contemporaneamente.

·      Ogni scheda prodotto contenuta nel catalogo deve contenere una fotografia a colori del prodotto, il suo nome, il nome del produttore, il prezzo e una descrizione sintetica ma completa, 5 righe di testo al massimo.

·      L’intero processo di acquisto di un prodotto dovrebbe richiedere al massimo 5 minuti.

 

Nel terzo esempio, l’uso del verbo dovrebbe segnala chiaramente che il requisito è auspicabile, ma non obbligatorio. Come si vede dagli esempi, i requisiti possono essere di vario tipo. Alcuni, detti requisiti funzionali (functional requirements), descrivono le funzioni che il sistema deve realizzare (come nel primo esempio). Altri, detti requisiti non funzionali, descrivono proprietà che il prodotto dovrà possedere (come negli altri esempi). Lo scopo della definizione dei requisiti è individuarli e descriverli nel modo più specifico e meno ambiguo possibile.  Lo standard ISO 13407 suggerisce che, per identificare i requisiti rilevanti, in un processo di progettazione human-centred, si considerino i seguenti aspetti:

·      le prestazioni richieste al nuovo sistema in relazione agli obiettivi operativi ed economico/finanziari;

·      i requisiti normativi o legislativi rilevanti, compresi quelli relativi alla sicurezza e alla salute;

·      la comunicazione e la cooperazione fra gli utenti e gli altri attori rilevanti;

·      le attività degli utenti, inclusa la ripartizione dei compiti, il loro benessere e le loro motivazioni;

·      le prestazioni dei diversi compiti;

·      la progettazione dei flussi di  lavoro e dell’organizzazione;

·      la gestione del cambiamento indotto dal nuovo sistema, incluse le attività di addestramento e il personale coinvolto;

·      la fattibilità delle diverse operazioni, comprese quelle di  manutenzione;

·      La progettazione dei posti di lavoro e la interfaccia uomo-computer.

 

I requisiti vengono prodotti da persone che lavorano in stretto contatto con il committente per individuarne i bisogni in relazione al sistema da realizzare (o da migliorare, se si tratta di una riprogettazione). Possono essere stesi direttamente dai progettisti, o da persone che non necessariamente saranno coinvolte nel progetto successivo.

È importante non confondere l’attività di stesura dei requisiti con l’attività di progettazione. Quando specifichiamo i requisiti di un prodotto, non stiamo progettando, ma stiamo ponendo dei vincoli all’attività di progettazione, che seguirà. In sostanza, lo scopo del documento è di indicare che cosa deve essere realizzato e perché, non come deve essere realizzato.

Il processo di definizione dei requisiti

La fase di definizione dei requisiti può essere suddivisa in tre attività fondamentali, che possiamo chiamare esplorazione, organizzazione e revisione (Figura 1).

 

Figura 1.  Il processo di definizione dei requisiti

Nell’esplorazione, le persone incaricate di produrre il documento dei requisiti raccolgono il maggior numero possibile d’informazioni sugli obiettivi e sulle necessità riguardo al sistema da costruire. Abbiamo usato il termine “esplorazione” per segnalare che, nella pratica, spesso questi obiettivi e necessità sono noti allo stesso committente in forma piuttosto vaga. I consulenti avranno quindi il compito importante e delicato di “esplorare” i diversi aspetti del problema, per mettere a fuoco o scoprire bisogni e priorità (in inglese si usano i termini elicitation o discovery).

Come indicato nella Figura 1, le informazioni vengono raccolte da fonti diverse. In primo luogo, dal committente, cioè colui che ha avviato il progetto e che ne costituisce il riferimento principale. In secondo luogo, dalle interviste con gli stakeholder del prodotto, cioè tutti coloro che, in un modo o nell’altro, hanno qualche interesse nel prodotto, o la cui attività sarà influenzata, direttamente o indirettamente, da esso.[1] Infine, dall’analisi della concorrenza, cioè di quei prodotti con i quali il prodotto in costruzione dovrà confrontarsi e competere. Se si tratta di un progetto di miglioramento di un prodotto esistente, informazioni importanti saranno ricavate anche dall’analisi dei suoi pregi e difetti.

Durante quest’attività, vengono raccolti appunti e materiale informativo vario, che dovranno successivamente essere riesaminati, selezionati e organizzati. Questo è lo scopo della successiva attività di organizzazione (o stesura dei requisiti), indicata sempre in Figura 1. L’obiettivo principale di questa fase è costruire un documento di specifica dei requisiti, condiviso e approvato dal committente. Questo sarà il riferimento principale per tutte le attività successive del progetto. Lo scopo di questo documento è di descrivere, nella forma più completa possibile, le richieste del committente e i vincoli che dovranno essere rispettati nelle fasi successive del progetto. Si analizza il materiale raccolto nella fase di esplorazione, lo si riordina, si risolvono eventuali contraddizioni (le persone intervistate potrebbero avere idee molto diverse su ciò che occorre fare), e si produce una prima bozza del documento dei requisiti. Il redattore dovrà ricorrere a tutta la sua esperienza e competenza, per produrre un documento che tenga conto, per quanto possibile, dei punti di vista di tutti gli intervistati, ma che li integri in una proposta organica e coerente e che, soprattutto, sia in accordo con le priorità indicate dal committente. È lui infatti che, in quanto referente principale del progetto, avrà l’ultima parola, in caso di dubbi o conflitti.

Nella fase di revisione e approvazione, la bozza del documento dei requisiti così prodotta verrà poi presentata al committente per la sua approvazione. Di solito, sarà necessario effettuare diversi aggiustamenti e revisioni del documento, prima che questo possa essere considerato sufficientemente consolidato e stabile per procedere alla successiva fase di progettazione. In un processo iterativo, come già più volte ricordato, il documento dei requisiti non potrà mai, comunque, considerarsi finale: in ogni momento successivo alcuni aspetti potranno essere rivisti e modificati, sulla base delle nuove informazioni acquisite in corso di progetto.

La fase di esplorazione

La fase di esplorazione, nella quale vengono raccolti i requisiti, presenta spesso notevoli difficoltà. I problemi sono sostanzialmente di tre tipi:[2]

·       Problemi di ambito. Generalmente, i “contorni” del sistema da progettare non sono ben definiti, ed esiste sempre il rischio di ampliare eccessivamente il campo di esplorazione. D’altro canto, restringendo troppo i temi da approfondire si rischia di tralasciare aspetti che potrebbero rivelarsi importanti nelle fasi successive. Inoltre, nelle conversazioni con gli stakeholder si è spesso tentati di abbozzare delle soluzioni di progetto. Questo è sbagliato: in questa fase ci si deve limitare alla sola raccolta dei requisiti, lasciando le attività di progettazione alle fasi successive, quando tutti i requisiti saranno stati individuati e organizzati in un insieme coerente. 

·       Problemi di comprensione. Questi avvengono a vari livelli. Da un lato, gli utenti hanno spesso una comprensione solo parziale dei loro bisogni, e una conoscenza piuttosto limitata delle possibilità offerte dalla tecnologia. Dall’altro, chi raccoglie i requisiti ha spesso una conoscenza limitata del dominio del problema, e utilizza un linguaggio differente da quello degli utenti e degli altri stakeholder. Ogni interlocutore tende a tralasciare gli aspetti che per lui sono ovvi, ma che potrebbero non esserlo affatto per interlocutori differenti.

·       Problemi di conflitto. Stakeholder diversi possono avere punti di vista diversi sul sistema che dovrà essere progettato. Questi punti di vista potrebbero essere fra loro incompatibili: questi conflitti dovranno essere fatti emergere con chiarezza, e  in qualche modo risolti nel documento dei requisiti finale.

·       Problemi di volatilità. I requisiti evolvono nel tempo. Infatti, il contesto del sistema può mutare anche molto rapidamente e in modo inaspettato. Questi cambiamenti possono riguardare le condizioni di mercato, ricambio del management o ristrutturazioni dell’organizzazione committente, acquisizioni o vendite societarie, evoluzioni della tecnologia, e così via. Tutti questi fatti possono modificare in modo rilevante le priorità dei diversi  requisiti, o addirittura modificarli completamente nel corso del progetto.

Le tecniche principali che possono essere utilizzate, nella fase di esplorazione, per la raccolta dei requisiti sono riassunte nella tabella di Figura 2, e descritte brevemente nei paragrafi che seguono.

Interviste individuali

La tecnica normalmente più usata è quella delle interviste individuali con il committente e i principali stakeholder del prodotto, perché permette di analizzare i singoli problemi in profondità. Gli intervistatori formulano le loro domande in colloqui individuali (faccia a faccia o telefonici) con ciascuno stakeholder, e raccolgono le risposte, annotando esigenze, suggerimenti, desideri e lamentele. Per ottenere la massima sincerità, di solito si garantisce agli intervistati che le loro opinioni verranno riportate solo in forma anonima.

La scelta di chi intervistare va fatta con cura. Occorre prevedere un numero di interviste compatibile con le risorse e il tempo disponibili, ma senza tralasciare nessuna persona che possa avere qualcosa d’importante da dire sul prodotto in progettazione. Dovranno pertanto essere intervistati rappresentanti di ciascuna categoria di stakeholder. Poiché il committente è il referente principale del progetto, le sue indicazioni dovranno avere la massima attenzione. Sarà lui che stabilirà gli obiettivi principali, i tempi di realizzazione e il budget. Sarà lui che indicherà le persone da intervistare e sarà lui che revisionerà e approverà il documento dei requisiti finale. In caso di conflitto fra proposte alternative, sarà lui a decidere quale dovrà essere preferita.

Le interviste individuali possono essere più o meno strutturate. Le interviste non strutturate sono di carattere esplorativo, e assomigliano a delle conversazioni sugli argomenti d’interesse. L’intervistatore pone domande aperte, lasciando all’interlocutore la decisione se rispondere in modo breve o approfondito. È utile effettuare queste interviste sulla base di un canovaccio preparato in anticipo, in modo da essere sicuri di non tralasciare alcun aspetto rilevante. L’intervistatore potrà comunque orientare il colloquio diversamente da quanto pianificato, per esplorare eventuali aspetti non previsti inizialmente che emergessero nella conversazione. Le interviste strutturate prevedono, invece, un insieme di domande predefinite, come avviene nei questionari di cui tratteremo più oltre. A differenza dei questionari, esse sono comunque realizzate da un intervistatore, in colloqui individuali con gli intervistati. Le interviste strutturate sono utili soprattutto quando gli obiettivi del colloquio siano stati bene identificati, e sia possibile definire un insieme di domande molto specifiche, che richiedono risposte precise. Di solito queste domande sono poste in forma identica a tutti gli intervistati; in questo modo, le risposte possono essere sottoposte ad analisi statistiche.  Le interviste semi-strutturate contengono sia domande libere, con carattere esplorativo, sia domande specifiche.

Condurre bene un’intervista può non essere facile e richiede esperienza. Occorre evitare di influenzare l’intervistato, formulando le domande in modo che non contengano implicitamente già la risposta. È necessario, inoltre, concentrarsi sui problemi e non sulle soluzioni: si dovrà sempre ricordare che l’obiettivo è quello di identificare i requisiti, e non di effettuare scelte di progetto. Queste dovranno essere fatte in seguito, a fronte di un quadro completo e organico dei vincoli esistenti. In ogni caso, l’intervistatore dovrà evitare di usare termini tecnici, cercando di parlare nel linguaggio dell’intervistato. In molti casi ci si accorgerà ben presto che è necessario chiarire bene il significato di alcuni termini, che possono essere usati dagli intervistati con accezioni particolari. Ogni organizzazione sviluppa col tempo un proprio gergo, che può creare fraintendimenti con interlocutori esterni. Può essere quindi conveniente approfittare delle interviste per definire un sintetico glossario. Cioè una lista dei termini più importanti utilizzati nel progetto, con le loro definizioni in relazione allo specifico contesto. Questo glossario, allegato ai requisiti, permette di stabilire una base di conoscenza comune fra gli stakeholder del prodotto e il gruppo di progetto.

Tecnica	Serve per	Vantaggi	Svantaggi
Questionari	Rispondere a domande specifiche.	Si possono raggiungere molte persone con poco sforzo.	Vanno progettati con grande accuratezza, in caso contrario le risposte potrebbero risultare poco informative. Il tasso di risposta può essere basso.
Interviste individuali	Esplorare determinati aspetti del problema e determinati punti di vista.	L’intervistatore può controllare il corso dell’intervista, orientandola verso quei temi sui quali l’intervistato è in grado di fornire i contributi più utili.	Richiedono molto tempo. Gli intervistati potrebbero evitare di esprimersi con franchezza su alcuni aspetti delicati.
Focus group	Mettere a fuoco un determinato argomento, sul quale possono esserci diversi punti di vista.	Fanno emergere le aree di consenso e di conflitto. Possono far emergere soluzioni condivise dal gruppo.	La loro conduzione richiede esperienza. Possono emergere figure dominanti che monopolizzano la discussione.
Osservazioni sul campo	Comprendere il contesto delle attività dell’utente.	Permettono di ottenere una consapevolezza sull’uso reale del prodotto che le altre tecniche non danno.	Possono essere difficili da effettuare e richiedere molto tempo e risorse.
Suggerimenti spontanei degli utenti	Individuare specifiche necessità di miglioramento di un prodotto.	Hanno bassi costi di raccolta. Possono essere molto specifici.	Hanno normalmente carattere episodico.
Analisi della concorrenza e delle best practices	Individuare le soluzioni migliori adottate nel settore di interesse	Evitare di “reinventare la ruota” e ottenere vantaggio competitivo	L’analisi di solito è costosa (tempo e risorse)

Figura 2.  Le principali tecniche utilizzate nella fase di esplorazione dei requisiti

Questionari

I questionari permettono di raccogliere informazioni in forma strutturata, elaborabili con metodi statistici. Essi possono essere distribuiti ai destinatari in vari modi. Per esempio, si possono predisporre dei questionari compilabili online, generando delle pagine web contenenti le domande del questionario. È così possibile raggiungere una popolazione potenzialmente molto ampia di utenti, anche se, di solito, il tasso di risposta (redemption) è piuttosto basso.  Esistono numerosi strumenti software (alcuni anche gratuiti, reperibili in rete), che permettono, da un lato, di costruire facilmente il questionario e, dall’altro, di elaborare i risultati e produrne una visione di sintesi attraverso grafici e diagrammi.

Una tecnica molto usata nei questionari destinati a raccogliere le opinioni degli utenti è la cosiddetta scala di Likert.[3] Il questionario è composto da una serie di affermazioni, collegate alle opinioni su cui si vuole indagare, per ciascuna delle quali sono possibili cinque risposte: completamente d’accordo, d’accordo, incerto, in disaccordo, in completo disaccordo. A ciascuna risposta è associato un numero compreso fra 1 e 5. Con questi valori si potrà calcolare la media delle risposte a ciascun gruppo di affermazioni correlate a uno stesso argomento.

Focus group

I focus group sono interviste di gruppo, che hanno lo scopo di mettere a fuoco uno specifico argomento e di far emergere i diversi punti di vista dei partecipanti o, a volte, un punto di vista condiviso fra tutti. Sono normalmente condotti da un animatore che guida la discussione e un osservatore che esamina le dinamiche di relazione del gruppo e prende appunti. La conduzione di un focus group non è compito banale e richiede esperienza. È necessario infatti evitare che il gruppo “sfugga di mano”. Quando emergerà il leader naturale, tenderà a monopolizzare la discussione e a trascinare il gruppo sulle sue posizioni. Il conduttore dovrà evitare che l'incontro diventi un’occasione di sfogo di malumori e critiche poco attinenti al tema, o di promozione di scopi personali.  Occorre fare in modo che tutti possano esprimere le loro idee e abbiano adeguato spazio nella discussione e che non sorgano conflitti fra i conduttori e i membri del gruppo, che potrebbero danneggiare lo svolgimento successivo del progetto.

Osservazioni sul campo

Non sempre gli utenti sono in grado di spiegare in dettaglio quali sono le modalità di uso desiderate per il prodotto nella loro attività quotidiana. Potrebbero anche avere un’immagine distorta di come si comportano nelle varie situazioni d’uso reali. Questo non deve stupire: normalmente un utente non ha interesse a conoscere in dettaglio la natura e la frequenza dei compiti che svolge quotidianamente, li svolge e basta. Uno studio sul campo per apprendere come gli utenti si comportano nella realtà può quindi essere molto istruttivo e riservare alcune sorprese. Purtroppo questo non è facile, può essere molto costoso, considerando anche la possibile varietà delle diverse tipologie di utenti. Gli studi sul campo vengono fatti con i metodi della etnografia, che abbiamo discusso nel Capitolo 4.

Suggerimenti spontanei degli utenti

Queste informazioni sono preziose per una corretta evoluzione del prodotto e dovrebbero sempre essere sistematicamente raccolte e classificate. Una fonte molto importante d’informazioni di questo tipo è costituita dai forum di discussione relativi ai vari prodotti, che di solito esistono sul Web. È possibile, inoltre, attivare un sito sul quale gli utenti segnalano spontaneamente miglioramenti desiderabili, e “votano”, con tecniche ormai abituali sul Web, i suggerimenti proposti.

Analisi della concorrenza e delle best practice

Un’altra attività importante nella fase di esplorazione dei requisiti è l’analisi dei prodotti concorrenti, cioè di quei prodotti con i quali il nostro prodotto dovrà confrontarsi e competere.  L’analisi della concorrenza potrà essere più o meno ampia, in funzione del numero e della complessità dei prodotti esaminati e del livello di approfondimento dell’esame. Per certi settori, può essere molto complessa e costosa. Si dovrà esaminare un certo numero di prodotti, per individuarne le caratteristiche più importanti e, soprattutto, i punti di forza e di debolezza: ciò permetterà di meglio contraddistinguere il prodotto in costruzione in rapporto ad essi e definirne, come si dice, la sua value proposition, cioè il valore specifico e distintivo che dovrà fornire ai suoi utenti.  Inoltre, quest’analisi permetterà d’individuare le pratiche migliori adottate dai prodotti del settore, dalle quali trarre spunti per la formulazione dei requisiti. È utile effettuare quest’analisi proprio all’inizio del progetto; infatti, durante le interviste di raccolta dei requisiti si potranno ottenere utili commenti sulle soluzioni adottate da altri e sulla loro applicabilità nel contesto corrente.

Scenari d’uso

Una tecnica molto utile per aiutarci a immaginare un nuovo prodotto, e a individuarne correttamente i requisiti, è quella d’ipotizzarne dei possibili scenari d’uso. Uno scenario d’uso è una narrazione, in linguaggio comune, di una possibile storia dell’uso del sistema da parte di uno specifico utente, fittizio ma in qualche modo tipico, e descritto in modo molto realistico. L’esempio che segue riporta un possibile scenario d’uso del sito Web di un cinema multisala.

Marco è uno studente universitario. È appassionato di cinema, anche se le sue possibilità economiche sono molto limitate. Sceglie i film da vedere con molta cura e preferisce vederli dalle prime file. Però gli capita spesso che il posto gli sia assegnato d’autorità dal computer della biglietteria, senza possibilità di scelta. Questo succede anche nel multisala vicino a casa sua. Per questo motivo, quando ha saputo che il cinema ha un nuovo sito Internet che permette, agli utenti registrati, di scegliere personalmente il posto, si è subito registrato. Ora, quando vuole andare al cinema, Marco si collega al sito e procede velocemente con l’operazione di prenotazione che è accessibile direttamente dalla home page. Inserisce nome utente e password e il sistema autorizza l’operazione fornendo come risposta le diverse opzioni di scelta. Marco ora può scegliere tra i titoli dei film in programmazione, il giorno della settimana e l’ora. A questo punto gli viene presentata la mappa della sala cinematografica, nella quale sono indicati i posti liberi (in verde) e quelli già prenotati (in rosso). Marco finalmente può scegliere il posto che preferisce facendo clic sulla figura e, dopo averlo confermato, avrà un resoconto dell’operazione, che gli sarà anche inviato con un messaggio di posta elettronica. La sera, almeno 15 minuti prima dell’inizio della proiezione, Marco si presenta alle casse del multisala con un documento d’identità. La cassiera procede a stampare i biglietti prenotati, che Marco paga. A questo punto Marco potrà accomodarsi nella sala cinematografica e vedere la proiezione del film direttamente dalla poltrona prescelta.

L’impiego degli scenari d’uso è molto utile nella progettazione di un prodotto. Durante la definizione dei requisiti, serve principalmente come mezzo di comunicazione con i diversi stakeholder e, in seguito, con i progettisti e gli sviluppatori. L’ideazione di storie d’uso tipiche e concrete è, infatti, un modo molto efficace per collocare il prodotto, ancora da progettare, nei suoi possibili contesti d’uso reali. Ognuno di noi, infatti, tende ad assumere dei “sistemi di riferimento” che considera ovvi e che quindi non ritiene necessario esplicitare o spiegare. Poichè i sistemi di riferimento dei nostri interlocutori non sono necessariamente identici ai nostri, è facile che nascano fraintendimenti ed equivoci che, nella progettazione di un prodotto complesso, possono essere molto dannosi.  Equivoci nella fase di definizione dei requisiti produrranno un prodotto con caratteristiche diverse da quelle desiderate: è bene che emergano e siano chiariti al più presto. Gli scenari d’uso sono uno strumento molto efficace per questo scopo.

Inoltre, quando progettiamo un prodotto, siamo portati inevitabilmente a considerare noi stessi come utenti tipici: tendiamo quindi a modellare il prodotto sui nostri bisogni, abitudini e preferenze. Questo è sbagliato, perché gli utenti “veri” del prodotto avranno normalmente bisogni, abitudini e preferenze diverse. D’altro canto, è molto facile cadere in questa trappola: scrivere uno scenario vissuto da personaggi dotati di una loro specifica identità, ci aiuta a considerare un prodotto in modo più oggettivo.  Pertanto, è molto importante che i protagonisti di uno scenario siano persone concrete, anche se fittizie, che rappresentano in qualche modo degli “utenti archetipi” del sistema. Devono essere dotati di una precisa identità; altrimenti, se pensiamo agli utenti come semplici ruoli astratti (per esempio, “studente universitario”), il rischio di mancare di concretezza e di perdere di vista le esigenze degli utenti reali è molto alto.

Ai questi utenti archetipi che le cui storie raccontiamo negli scenari d’uso si dà spesso il nome di personae (il plurale della parola latina persona). Una persona non dovrebbe essere inventata, ma creata a partire da una ricerca etnografica (Capitolo 4), come sintesi di varie caratteristiche presenti negli utenti reali, e descritta in un profilo che ne elenca obiettivi, competenze, comportamenti, preferenze, ambiente sociale, stile di vita. In una parola, tutto ciò che si ritiene rilevante per caratterizzarne il rapporto con il prodotto che dovrà essere progettato.   La Figura 3 mostra un esempio di alcune personae rappresentate su supporti di cartone. Queste rappresentazioni, tenute sulle scrivanie dei progettisti e accompagnate dal loro profilo, contribuiscono a ricordare costantemente a chi il progetto è destinato.

Figura 3.  Sagome di cartone rappresentanti  le personae di uno scenario[4]

Come si vede nell’esempio del cinema, è opportuno che, nella formulazione di uno scenario d’uso, sia riportata una storia completa, che non si limiti, quindi, alla pura interazione con il sistema, ma che ne consideri il contesto complessivo. In questo modo è facile che emergano dei requisiti impliciti, che potrebbero altrimenti essere facilmente trascurati. Così, la storia di Marco ce ne descrive la motivazione principale (la possibilità di scegliere il posto al cinema) e ci mostra le azioni compiute da Marco dopo aver completato la transazione al computer. Tutto questo aiuta il redattore dei requisiti a non trascurare aspetti importanti e a porre la giusta enfasi sugli aspetti chiave. Anche i progettisti ricaveranno utili informazioni dall’esame degli scenari d’uso. Per esempio, chi, in seguito, progetterà il sistema, comprenderà meglio il motivo per cui le funzioni per la selezione del posto a sedere debbano essere particolarmente flessibili e usabili.

Naturalmente, la storia deve “mettere in scena” situazioni tipiche. Per esempio, lo scenario appena visto potrebbe essere giustificato da un’indagine presso gli spettatori che abbia mostrato che la scelta del posto al cinema è importante per un numero rilevante di persone, e non solo per l’ipotetico utente Marco.  Durante le interviste, si potrà chiedere agli intervistati d’immaginare gli scenari d’uso che ritengono più tipici. Dall’approfondimento di questi scenari potranno emergere requisiti che altrimenti sarebbero trascurati. A volte, intervistato e intervistatore discuteranno scenari alternativi. Si potranno chiedere, per esempio, se nel caso del cinema multisala l’affollamento del sabato sera possa creare delle difficoltà nel ritiro dei biglietti prenotati, e come si possano evitare code. Queste analisi, che a volte, come in questo caso, non coinvolgono direttamente le funzioni del prodotto, potrebbero suggerire soluzioni alternative più convenienti.

La storia di Marco è piuttosto semplice, perché coinvolge un solo caso d’uso del sistema: l’acquisto del biglietto. Altri scenari, più complessi, possono coinvolgere più casi d’uso, come lo scenario relativo ai sistemi d’intelligenza ambientale visto nel Capitolo 2, o il seguente:

Marco, studente universitario, ha sempre con sé il suo netbook. Salito sul treno per rientrare a casa dalle lezioni in università, apre il suo netbook per rivedere gli appunti presi a lezione. La carica della batteria gli permette di lavorare per tutta la durata del tragitto. Grazie alle dimensioni dello schermo e della tastiera, Marco riesce a leggere e a scrivere agevolmente, tenendo il netbook sulle ginocchia: ciò gli permette di concludere la sistemazione degli appunti della lezione di Diritto durante il viaggio. Arrivato a casa, Marco collega il netbook alla corrente, per ricaricare la batteria mentre corregge gli appunti di Psicologia. Conclusi anche questi, prima di cena si connette al forum del corso e pubblica i suoi appunti in rete, per metterli a disposizione dei suoi compagni di corso.

Come indicato dalle frasi sottolineate, questo scenario coinvolge tre casi d’uso del netbook: Correggi gli appunti, Ricarica la batteria, Pubblica sul forum.

Lo scenario seguente, ancora più complesso, è tratto da un documento dei requisiti per un sistema di gestione delle cartelle cliniche.[5] Anche qui, le frasi che identificano i casi d’uso del sistema sono sottolineate.

Andrea è un medico pneumologo all’ospedale …omissis… di Milano. La sua attività lavorativa si suddivide tra ambulatorio e reparto. Andrea in ambulatorio ha ogni giorno n appuntamenti prefissati e attraverso un archivio dell’ambulatorio recupera le cartelle cliniche dei pazienti che hanno appuntamento quel giorno, così può iniziare a visitarli nell’ordine di arrivo.

La visita può essere una prima visita o una visita di controllo. Nel primo caso Andrea raccoglie la storia clinica e scrive l’ anamnesi del paziente e in base alle patologie e sintomi rilevati cerca di capire quale problema affligge il paziente. Se il caso in questione è semplice o richiede esami che possono essere effettuati direttamente in ambulatorio in modo da poter visualizzare immediatamente i risultati Andrea può prescrivere fin da subito la terapia più adatta alla circostanza. Se il caso è più complesso e richiede esami più specifici (molte volte si effettuano in altri ambulatori o strutture) allora il medico prescrive gli esami che il paziente deve fare e gli fissa un nuovo appuntamento in cui potrà vedere gli esiti di tali esami appena richiesti.

Se la visita è un controllo, Andrea legge la storia clinica del paziente, valuta i documenti portati dal paziente (valori degli esami che aveva richiesto) e segue le indicazioni che aveva segnato sulla cartella clinica nella visita precedente. Anche in questo caso, se il caso in questione lo permette prescrive la terapia da seguire oppure fissa un nuovo appuntamento.

Andrea, come detto in precedenza, oltre all’ambulatorio lavora anche nel reparto di pneumologia dell’ospedale. Ogni giorno effettua un giro visite dei pazienti ricoverati. In tal modo visita ogni paziente, vede la diagnosi d’ingresso e gli esami effettuati dal paziente. Se ritiene opportuno stabilisce altri esami diagnostici e prescrive, cambia, o conferma la terapia. Se la clinica del paziente e i valori degli esami lo permettono Andrea può decidere anche di dimettere il paziente. Un caso particolare sono le urgenze e le emergenze. Qui il medico deve intervenire prontamente e cercare di stabilizzare il paziente. In questa fase la diagnosi è poco accurata e ci si basa più sulla clinica manifestata dal paziente. Altra attività che Andrea può svolgere sono le visite a parere, in questo caso il medico effettua consulenze in altri reparti dell’ospedale che hanno richiesto il suo intervento.

Gli scenari d’uso possono essere molti utili, ma scegliere quelli realmente significativi da inserire nel documento dei requisiti non è facile. Il rischio maggiore è quello di scadere nell’aneddotica, raccontando storie poco rilevanti per la comprensione dei requisiti del prodotto, che quindi non saranno di alcuna utilità nelle successive fasi di progettazione. Nel caso di prodotti di nuova concezione, destinati a innovare i comportamenti degli utenti, si realizzano a volte degli scenari d’uso con delle riprese video.  Un esempio molto famoso, è il video del Knowledge Navigator, realizzato dalla Apple nel 1987 (Figura 4). Esso mostrava un possibile scenario d’uso di un personal computer del futuro (il “futuro”, allora, era collocato nell’anno 2010) basato sul concetto di agente. Nel video, un professore universitario parlava con un aiutante sintetico, rappresentato sul monitor  con sembianze umane, per raccogliere, in rete o facendosi aiutare da altri agenti remoti, i dati necessari per la stesura di un articolo scientifico.[6]

Figura 4.   Knowledge Navigator (Apple, 1987)

 

I casi d’uso

Nel Capitolo 5 è stata introdotta la nozione di caso d’uso. La descrizione dei casi d’uso del sistema costituisce un capitolo molto importante del documento di specifica dei requisiti. Pertanto, le prossime pagine saranno dedicate ad approfondire questo argomento.

Come abbiamo già visto, un caso d’uso (use case) può essere definito come un insieme di interazioni finalizzate a uno scopo utile, fra uno o più attori e il sistema. Esso ha un nome che, come abbiamo già visto, di solito è composto da un verbo, alla terza persona singolare o all’infinito,  e da un complemento, oppure da una frase che descrive sinteticamente lo scopo dell’interazione. Per esempio, in un sito web di e-commerce:

·      Acquista prodotto

·      Modifica il profilo utente

·      Ricercare un prodotto nel catalogo

·      Inserire un nuovo prodotto in catalogo

·      Modificare i dati di un prodotto.

 

Un caso d’uso viene invocato (cioè iniziato) da un attore per un particolare scopo e si conclude con successo quando tale scopo è raggiunto. Ogni attore non è una persona concreta, come negli scenari che abbiamo appena descritto, ma rappresenta un particolare ruolo nell’interazione con il sistema (vedi Capitolo 4). Per esempio, nel nostro sistema di e-commerce, potremmo avere tre attori, denominati Utente, Utente registrato e Amministratore del sistema. Ciascuno di questi attori invocherà casi d’uso specifici per il suo ruolo. Per esempio, l’Amministratore del sistema potrà Inserire un nuovo prodotto nel catalogo, mentre  l’Utente potrà soltanto Ricercare un prodotto nel catalogo, senza poterne modificare la descrizione. Se un caso d’uso coinvolge più attori, quello che persegue lo scopo che il caso d’uso deve soddisfare sarà considerato l’attore principale. Solitamente, ma non sempre, esso è quello che dà inizio al caso d’uso con la sua invocazione.

Diagramma dei casi d’uso

Nel documento dei requisiti, è consigliabile aggiungere all’elenco dei casi d’uso un diagramma riassuntivo, detto diagramma dei casi d’uso (use case diagram), che mostra le relazioni fra gli attori e i casi d’uso del sistema (Figura 5).

Figura 5.  Un diagramma dei casi d’uso

 

In questi diagrammi, gli attori sono rappresentati con omini stilizzati e i casi d’uso con ellissi. Il nome dell’attore viene indicato sotto l’omino e quello del caso d’uso dentro l’ellissi (Figura 6).

Figura 6.  Rappresentazione grafica di attori e casi d’uso

 

Gli attori coinvolti in un caso d’uso non devono necessariamente essere umani: possono anche essere dei sistemi con i quali il caso d’uso interagisce, per inviare o ricevere dati, o per richiedere dei servizi. Così, in Figura 5, il caso d’uso Acquista Prodotto coinvolge l’attore Sistema bancario, per gestire il pagamento attraverso carta di credito. Anche gli attori non umani sono tradizionalmente rappresentati con degli omini stilizzati: per indicare che non si tratta di persone in carne e ossa, nel diagramma dei casi d’uso viene allora convenzionalmente riportata, sotto il nome dell’attore, la dicitura convenzionale <<sistema>>.

L’associazione fra un attore e un caso d’uso è rappresentata da un segmento che li congiunge e può indicare una (o più) situazioni fra le seguenti:

·       l’attore esegue il caso d’uso;

·       l’attore fornisce informazioni al caso d’uso;

·       l’attore riceve informazioni dal caso d’uso.

Figura 7.  Rappresentazione della relazione fra un attore e un caso d’uso

 

A volte, al posto dei segmenti, si utilizzano delle frecce per indicare che l’attore esegue (o, come si dice, invoca) il caso d’uso:

Figura 8.  Rappresentazione con un arco orientato

Si noti che la direzione della freccia non specifica la direzione del flusso dei dati (che possono fluire in un senso o nell’altro), come si potrebbe supporre per analogia con altri tipi di diagrammi d’uso comune. Per evitare possibili fraintendimenti, si consiglia quindi di limitare l’uso delle frecce ai soli casi in cui possano sussistere delle ambiguità su chi invoca che cosa. Nel diagramma di Figura 5, poiché il caso d’uso Acquista prodotto è associato a due attori, è stata usata la notazione a freccia per indicare che è l’utente umano, e non il sistema, che lo invoca. Negli altri casi, non sussistendo ambiguità, sono stati usati dei segmenti non orientati.

Un diagramma che rappresenta tutti i casi d’uso di un sistema si chiama diagramma di contesto del sistema, perché indica i “confini” dello stesso e tutti gli attori che lo utilizzano. In questo caso, il sistema si indica con un riquadro che circonda i casi d’uso  e ne riporta il nome, come nel nostro esempio.

 

Descrizione dei casi d’uso

Nel documento dei requisiti, a ogni caso d’uso mostrato nel diagramma dovrebbe essere associata una descrizione, per far comprendere al lettore di che cosa si tratta. Essa dovrebbe essere espressa in un linguaggio semplice e informale, comprensibile a chiunque. Infatti, come abbiamo visto, il documento dei requisiti viene utilizzato non solo dai progettisti del sistema, ma anche dagli stakeholder che contribuiscono alla loro stesura. Questi, nella grande maggioranza dei casi, non hanno le competenze tecniche necessarie per leggere delle descrizioni in linguaggi troppo formalizzati. Si usa quindi il linguaggio naturale, avendo l’accorgimento di utilizzarlo nel modo meno ambiguo possibile e senza ridondanze.

 

Anche se non sono state definite delle regole standard, si è consolidata la prassi di descrivere un caso d’uso specificandone i diversi scenari d’uso. Questi scenari, a differenza di quelli esemplificati nella sezione precedente, non fanno riferimento a utenti concreti, con nome e cognome, che operano in specifici contesti, ma agli attori identificati nel diagramma dei casi d’uso, in situazioni generiche, senza riferimento ad alcun contesto specifico. Si tratta, per così dire, di scenari d’uso “astratti” e ridotti ai minimi termini, che servono esclusivamente a chiarire il significato che il redattore del documento dei requisiti attribuisce ai vari casi d’uso. Alcuni di questi scenari permettono di raggiungere lo scopo, altri portano alla conclusione del caso d’uso senza che lo scopo sia raggiunto. Per esempio, nel caso di Acquista prodotto, la carta di credito potrebbe non essere valida, e il caso d’uso si concluderebbe senza alcun acquisto. Questi scenari alternativi presentano delle differenze, ma sono accomunati dal fatto che l’utente ha sempre lo stesso scopo, nel nostro caso, acquistare un prodotto. Può darsi che l’acquisto non vada a buon fine, ma l’intento rimane.

 

La forma più comune della descrizione di un caso d’uso è esemplificato nella Figura 9, che fa riferimento al solito Acquista prodotto del sito web di e-commerce. Viene descritto prima lo scenario principale di successo, detto anche corso d’azione base, cioè quello che è ritenuto più frequente o importante, e che si conclude con il successo del caso d’uso: l’utente raggiunge il suo scopo. Esso descrive il flusso principale degli eventi d’interazione, espresso come sequenza di passi numerati, ciascuno dei quali corrisponde a un’interazione fra uno o  più attori e il sistema.

 

Figura 9.  Descrizione del caso d’uso Acquista prodotto

 

Seguono poi gli altri scenari, detti scenari alternativi. Essi sono descritti come estensioni di quello principale, cioè specificando solo le differenze con esso, senza ripetere tutto, per non appesantire troppo la descrizione.

 

Per indicare un’estensione si scrive la condizione che determina il verificarsi di una sequenza d’interazioni alternativa rispetto a quella dello scenario principale, specificando poi le differenze. Prima di tutto si scrive il numero del passo in cui si può verificare la condizione, con una breve descrizione della stessa; quindi si aggiungono dei passi numerati espressi nello stesso stile dello scenario principale. Alla fine si indica da quale passo si rientra nel flusso di eventi base. Nel nostro esempio, le estensioni sono tre, descritte come alternative, rispettivamente, dei passi 3, 5 e 6, corrispondenti alle tre condizioni Il cliente è preregistrato, Il cliente non accetta e rinuncia all’acquisto, Il sistema non autorizza l’acquisto.

 

Ogni passo di uno scenario dovrebbe essere espresso con una frase semplice, che faccia chiaramente capire chi lo sta eseguendo. Non si dovrebbero mai indicare i dettagli delle azioni di un attore, ma il loro scopo. Inoltre, non si dovrebbero mai descrivere i particolari dell’interfaccia utente: bisogna sempre ricordare che si stanno specificando i requisiti di un sistema, e che le scelte di come realizzarlo devono essere lasciate ai progettisti, che interverranno nelle fasi successive. Per lo stesso motivo, il sistema viene visto come una “scatola nera” e il suo funzionamento interno non viene considerato. In sostanza, un caso d’uso specifica chi (l’attore o gli attori), che cosa (l’interazione) e perché (lo scopo), senza entrare nel merito del funzionamento interno del sistema.

Se un caso d’uso ne richiama un altro, il nome di quest’ultimo viene sottolineato. Si usa la sottolineatura, perché suggerisce un collegamento ipertestuale, e chiunque lo può capire. Così, nella Figura 9, il primo passo richiama il caso d’uso Ricerca nel catalogo il prodotto da acquistare, che viene descritto a parte, con la stessa tecnica. Si dice allora che questo caso d’uso è incluso nel precedente.

L’inclusione può essere utile per esprimere con un singolo passo una sequenza di passi più elementari, che renderebbe pesante la descrizione dello scenario, oppure, più spesso, per raccogliere “a fattor comune” una sequenza di passi che si ripetono più volte nello stesso o in diversi casi d’uso.

Nella descrizione dei casi d’uso non è mai consigliabile scendere a un livello di dettaglio troppo basso, decomponendo i casi in sottocasi e questi in sotto-sottocasi. Nel documento dei requisiti è conveniente mantenersi a un livello ancora piuttosto generale. Ciò che interessa è dare al lettore un’immagine abbastanza chiara dei diversi casi d’uso, che permetta di comprendere con ragionevole precisione e senza ambiguità ciò che il sistema deve fare e non come deve farlo. Le descrizioni troppo lunghe e dettagliate finiscono per non essere neppure lette, il che le renderebbe ben poco utili. Sarà poi compito delle successive attività di progettazione decomporre ogni caso d’uso nei compiti  che lo compongono, e questi nelle azioni elementari che l’utente dovrà effettuare.

Alistair Cockburn, autore di un libro sui casi d’uso, dà le seguenti indicazioni:[7]

Molti si sentono colpevoli se lo scenario principale di un caso d’uso è breve, così lo allungano per arrivare a quindici, o anche trentacinque righe. Personalmente, io non ho mai scritto uno scenario principale più lungo di nove passi. Non che il nove sia un numero magico; il fatto è che, quando ho individuato i sotto-goal a un giusto livello e ho eliminato i dettagli che riguardano la progettazione, mi restano sempre meno di nove passi. A volte, lo scenario principale di un caso d’uso può essere anche di soli tre passi.

Il valore maggiore di un caso d’uso non è nello scenario principale, ma nei comportamenti alternativi. Lo scenario principale può occupare da un quarto a un decimo della lunghezza totale di un caso d’uso, perché ci possono essere molte alternative da descrivere. Se lo scenario principale fosse lungo trentacinque passi, l’intero caso d’uso occuperebbe dieci pagine, e sarebbe troppo lungo da leggere e da comprendere. Se lo scenario principale contiene da tre a nove passi, la descrizione complessiva potrebbe essere di solo due o tre pagine, il che è più che sufficiente.

Se potete evitare di includere troppi dettagli dell’interfaccia utente, i casi d’uso saranno molto più facili da leggere. E i casi d’uso leggibili possono in effetti venire letti. Casi d’uso lunghi e illeggibili vengono soltanto firmati – di solito con sgradevoli conseguenze sul progetto, alcuni mesi più tardi. 

Non bisogna confondere gli scenari d’uso introdotti a pag. 6 con i casi d’uso: sono due cose diverse, che perseguono obiettivi differenti. Gli scenari d’uso che abbiamo introdotto in precedenza hanno lo scopo di illustrare situazioni tipiche di uso del sistema, per farne comprendere la portata e fare emergere eventuali requisiti impliciti. Sono storie tipiche molto concrete dell’uso del sistema, raccontate con particolari che permettano di comprenderne le motivazioni e il contesto.  Spesso raccontano situazioni che coinvolgono più casi d’uso. Anche quando lo scenario riguarda un singolo caso d’uso, come la prenotazione del biglietto del cinema  (pag.6), esso ne descrive una specifica istanza, e lo arricchisce d’informazioni aggiuntive. Nell’esempio, ci venivano descritte le motivazioni di Marco a effettuare la prenotazione online, e le sue azioni dopo la prenotazione, fuori dal sistema: il ritiro dei biglietti alla cassa, il pagamento, e così via.

La descrizione dei casi d’uso costituisce un passo logicamente successivo alla creazione degli scenari d’uso. In questo passo, s’identificano tutte le interazioni che, a un certo livello di astrazione e dal punto di vista dei vari attori coinvolti, dovranno avere luogo con il sistema, e li si descrive cercando di tener conto delle principali alternative. La descrizione di un caso d’uso non fa riferimento a personaggi concreti, ma a ruoli astratti incarnati dai vari attori, e contiene solo informazioni sull’interazione che questi hanno con il sistema, senza alcuna informazione aggiuntiva sul contesto. Sono, per così dire, collezioni di scenari ridotti ai minimi termini, che hanno lo scopo di fissare gli aspetti principali del flusso dell’interazione con il sistema, che dovranno poi essere ulteriormente sviluppati nella fase di progettazione.

Generalizzazione, inclusione, estensione di casi d’uso

Durante l’organizzazione del documento dei requisiti, per effettuare la descrizione dei casi d’uso del sistema conviene partire dalla formulazione di un primo elenco, che verrà via via modificato per raggiungere un livello di dettaglio soddisfacente. Se i casi d’uso risultano troppo dettagliati, si passa a un livello di astrazione maggiore; se sono troppo generali, li si decompone ulteriormente. Così, in un supermercato online, Fa la spesa è troppo generale, e lo si decompone, per esempio, in Ricerca prodotto e Acquista prodotto.   Al contrario, Fornisce i dati della carta di credito potrebbe non essere considerato un caso d’uso a sé stante, perché troppo dettagliato, ma soltanto un passo di Acquista prodotto. Non esistono regole fisse per determinare il livello di astrazione corretto: sarà la sensibilità dell’estensore del documento a guidarlo nella scelta. Il criterio, come già detto, è quello di ottenere una descrizione sufficientemente dettagliata da essere utile per far capire di che cosa si parla, ma non così dettagliata da scoraggiarne la lettura. I casi d’uso così definiti saranno raccolti nel diagramma dei casi d’uso del sistema, per avere una visione generale, prima di procedere alle singole descrizioni.

 

Alcuni casi d’uso possono rivelarsi casi particolari di altri casi d’uso. Per esempio, in un negozio online che vende libri e CD musicali, i due casi d’uso Acquista libro e Acquista CD potrebbero essere considerati casi particolari del caso d’uso più generale Acquista prodotto. Allora, si dice che Acquista prodotto è una generalizzazione di ciascuno degli altri due casi d’uso. Al contrario, si può dire che Acquista libro (o Acquista CD) è una specializzazione di Acquista prodotto.

 

La generalizzazione può essere rappresentata graficamente nel diagramma mediante una freccia con la punta a triangolo, come nella Figura 10. La stessa notazione grafica può essere usata anche per rappresentare la relazione di generalizzazione fra attori. Per esempio, sempre in Figura 10, Cliente è indicato come una generalizzazione di Cliente privato e di Cliente società. In pratica, si è deciso di differenziare i clienti in due categorie (persone fisiche e persone giuridiche) perché il sistema dovrà trattarle in modo differente.

 

Figura 10.       Rappresentazione grafica della generalizzazione fra attori e fra casi d’uso

 

Quando un caso d’uso ne utilizza un altro, incorporandone il comportamento, si dice che lo include. Se un caso d’uso è incluso più volte, conviene dargli un nome e descriverlo separatamente. Questo permette di non duplicarne la descrizione nel documento dei requisiti.

 

Per rappresentare graficamente l’inclusione, si traccia una freccia tratteggiata dal caso d’uso includente al caso d’uso incluso, con la etichetta <<include>>. Per esempio, in Figura 11 Acquista prodotto e Verifica stato ordini includono entrambi il caso d’uso Autenticazione. Infatti, per effettuare entrambe le operazioni l’utente dovrà fornire le proprie credenziali d’accesso al sistema, ed essere da questo riconosciuto. Autenticazione sarà quindi descritto separatamente e richiamato nella descrizione dei casi d’uso che lo includono, sottolineandone il nome nei passi che lo invocano, come abbiamo visto nell’esempio in Figura 9.

Figura 11.       Rappresentazione grafica dell'inclusione fra casi d’uso

 

Infine, si dice che un caso d’uso estende un altro caso d’uso quando il suo comportamento può (ma non necessariamente deve) essere richiamato all’interno del primo, come una sua variante. Si noti che il caso d’uso esteso è definito indipendentemente dal caso d’uso che lo estende.

 

La estensione viene rappresentata graficamente come in Figura 12, dove il caso d’uso Help on line estende i casi d’uso Acquista prodotto e Verifica stato ordini.  Questo significa che Help on line può essere richiamato, in qualche scenario d’uso, dagli altri due casi d’uso menzionati.

 

Figura 12.       Rappresentazione grafica dell’estensione di casi d’uso

 

Queste notazioni grafiche possono aiutare a precisare meglio le relazioni fra i casi d’uso all’interno dei diagrammi. È tuttavia consigliabile non farne un uso eccessivo: notazioni troppo formali spaventano e allontanano i lettori non tecnici: è preferibile un documento di requisiti un po’ meno preciso, ma letto approfonditamente e condiviso dai vari stakeholder, a un documento perfetto, ma che nessuno ha realmente compreso. 

Il documento dei requisiti

Siamo ora in grado, a conclusione di questo capitolo, di individuare una possibile struttura del documento dei requisiti. Esso dovrebbe contenere, prima di ogni requisito specifico relativo al sistema da realizzare, un’approfondita analisi dell’utente e delle sue necessità. In particolare, dovrebbe coprire i seguenti temi:

·      Analisi degli utenti: a quali categorie di utenti è destinato il prodotto? Quali sono le loro caratteristiche? Quali categorie vanno considerate prioritariamente?

·      Analisi dei bisogni: quali sono le necessità di ciascuna categoria di utenti? Quali sono prioritari?

·      Analisi del contesto d’uso: quali saranno i diversi contesti d’uso del prodotto da parte delle diverse categorie di utenti? Quali sono prioritari?

 

Queste analisi dovrebbero essere corredate dalla descrizione di alcuni scenari d’uso tipici, per far comprendere meglio al lettore lo scopo del prodotto. Gli scenari sono particolarmente importanti per i prodotti di nuova concezione, per i quali non esistono esperienze d’uso consolidate.

Dopo questa prima parte generale, che fornisce le motivazioni del sistema da progettare e lo colloca nel suo contesto, i requisiti dovrebbero proseguire con la descrizione dei diversi casi d’uso del sistema. Si dovrebbe inserire il diagramma dei casi d’uso, con i diversi attori individuati nella precedente analisi degli utenti, e descrivere ogni singolo caso d’uso con le tecniche esemplificate più sopra.

Una possibile struttura del documento dei requisiti è schematizzata in Figura 13.

Figura 13.     Una possibile struttura del documento dei requisiti

 

Le diverse sezioni possono essere redatte sulla base delle indicazioni che seguono.

Generalità

·       Scopo del prodotto. Descrive la natura del prodotto oggetto del documento di requisiti. Specifica sinteticamente gli obiettivi del prodotto (quelli generali e quelli più specifici),  distinguendo quelli principali da quelli secondari, e stabilendone le priorità.

·       Situazione attuale. Specifica se il progetto riguarda un prodotto di nuova realizzazione, o se si tratta di un miglioramento di un prodotto esistente. In questo secondo caso, elenca i principali punti di forza e di debolezza del prodotto attuale.

·       Caratteristiche degli utenti. Specifica a quali categorie di utenti è destinato il prodotto. Descrive il profilo di ciascuna categoria: competenze, abilità, esperienze, corsi di addestramento seguiti, caratteristiche psico-fisiche, abitudini, preferenze. Specifica gli obiettivi di ciascuna categoria di utenti in rapporto al prodotto e i diversi ruoli rivestiti nei suoi confronti. In questa sezione s’identificano le classi di attori che verranno utilizzate nella successiva descrizione dei casi d’uso.

·       Contesti d’uso. Descrive i diversi contesti e ambienti d’uso per le diverse categorie di utenti descritte in precedenza. Questi possono includere eventuali standard adottati, il contesto normativo (per esempio, leggi e regolamenti), le caratteristiche dell’ambiente tecnologico, l’ambiente organizzativo (per esempio, struttura organizzativa, procedure di lavoro, consuetudini consolidate) e le caratteristiche dell’ambiente fisico, se rilevanti.

·       Scenari d’uso. Descrive sinteticamente gli scenari d’uso tipici e significativi, che mettano in luce gli aspetti più importanti del prodotto, collocati nel loro contesto.

·       Fattibilità tecnologica. Indica le tecnologie che dovranno essere utilizzate nella realizzazione del prodotto, e che lo rendono fattibile.

Posizionamento

·       Analisi della concorrenza. Identifica i principali prodotti concorrenti. Per ciascuno, riporta una scheda descrittiva, con la storia, le caratteristiche rilevanti e i principali motivi di successo e d’insuccesso. Include immagini e riferimenti come opportuno. Questa sezione può essere espressa in forma sintetica, allegando eventuale materiale di dettaglio in appendice.

·       Posizionamento competitivo. Specifica quali saranno i punti di forza e gli eventuali punti di debolezza del prodotto in rapporto ai prodotti concorrenti più sopra indicati.

Casi d’uso

·       Diagramma dei casi d’uso. Fornisce una visione di sintesi dei casi d’uso del prodotto. Gli  attori rappresentati nel diagramma devono corrispondere alle tipologie di utenti descritte nella sezione Generalità.

·       Descrizione dei casi d’uso. Descrive ogni caso d’uso in forma verbale, specificando per ciascuno lo scenario principale di successo e gli scenari alternativi.

Altri requisiti

·       Requisiti per l’esperienza utente. Descrive i requisiti relativi all’interfaccia utente e, più generale, alla user experience. Contiene esempi o figure ove necessario. Specifica  come si dovrà valutare, durante il progetto, il soddisfacimento di questi requisiti.

·       Requisiti prestazionali. Esprime i requisiti relativi alle prestazioni del sistema, anche relativamente alle risorse necessarie per il suo utilizzo.

·       Altri requisiti. Questa sezione, che può anche essere estesa e suddivisa in ulteriori sezioni, contiene ogni altro requisito, in funzione della natura del prodotto o servizio in esame.

Allegati

·      Glossario. Definisce gli eventuali termini tecnici o gergali, specifici dell’organizzazione o del prodotto, utilizzati nel documento.

·      Altri allegati. Come necessario.

·      Riferimenti. Contiene ogni riferimento a pubblicazioni o a materiale di supporto utile  per un migliore comprensione del documento.

Ripasso ed esercizi

1.     Che cosa s’intende con il termine “requisiti di prodotto”?

2.     Che cosa s’intende per stakeholder di un prodotto?

3.     Quali sono i principali metodi di raccolta dei requisiti?

4.    Che cosa s’intende per "analisi dell’utente" in un processo di progettazione human-centred? Abbozza, come esempio, l’analisi dell’utente per il sito web di una biblioteca universitaria.

5.    Che cosa s’intende per "analisi dei bisogni"? Per chiarire meglio il concetto, scrivi anche una sintetica analisi dei bisogni relativi al progetto dell’ascensore di casa tua.

6.    Che cosa s’intende per "analisi del contesto"? Spiega il concetto anche con semplici esempi.

7.     Che cosa sono e a che cosa servono gli scenari d'uso? Quali sono le caratteristiche di un buon scenario d'uso?

8.     Qual è la differenza fra casi e scenari d’uso?

9.     Scrivi tre scenari d’uso relativi all’ascensore di casa tua.

10.  Costruisci il diagramma dei casi d’uso dell’ascensore di casa tua, e scrivi la descrizione di ogni singolo caso d’uso.

11.  Costruisci il diagramma dei casi d’uso di una macchina erogatrice di bibite, considerando i diversi attori coinvolti, e descrivi i diversi casi d’uso con le modalità illustrate in questo capitolo.

Approfondimenti e ricerche

1.     Sulle tecniche di raccolta dei requisiti esiste molta letteratura, anche in rete. Si cerchino, per esempio, le parole “requirements elicitation”, “requirements analysis”, “requirements engineering”. Una visione più ampia di quella del presente libro, ma ancora abbastanza sintetica, si può trovare nel classico testo di J.Preece, Y.Rogers e H.Sharp, Interaction Design (Second Edition), John Wiley&Sons, 2007.

2.     Guarda il classico video della Apple (1987) che mostra uno scenario d’uso del Knowledge Navigator, citato all’inizio di questo capitolo. In rete ne esistono numerose copie, per esempio in www.youtube.com.

3.     Anche la letteratura sui casi d’uso è vasta, ma prevalentemente orientata alla progettazione di sistemi a oggetti, e non all’interaction design. Inoltre, differenti autori interpretano il concetto in modi non sempre identici. Per questo, per approfondire la nozione di caso d’uso occorre una certa cautela, altrimenti si rischia di confondere le idee. A chi volesse farlo, si consiglia vivamente di iniziare dall’articolo di Alistair Cockburn, Use cases, ten years later, originalmente pubblicato nel 2002 e disponibile in rete, breve  ma molto utile. Si potrà poi cercare ulteriore materiale, preferibilmente legato all’interaction design. (Per esempio, in http://www.guuui.com/issues/02_04.php).

4.     Per indicazioni su come costruire le personae per gli scenari d’uso, si può vedere il blog di S.Mulder: http://www.practicalpersonas.com/persona_value/ , e la sua presentazione su www.slideshare.com: The User is Always Right – Making Personas Work for Your Site, in http://www.slideshare.net/MulderMedia/the-user-is-always-right-making-personas-work-for-your-site , con interessanti esempi.