Modellazione dei requisiti utente

Microsoft Visual Studio Ultimate consente di comprendere, illustrare e presentare le necessità degli utenti tramite l'ausilio di diagrammi sulle attività e sul ruolo giocato dal sistema nel raggiungimento dei relativi obiettivi.Un modello requisiti è un set di tali diagrammi, ognuno dei quali è incentrato su un aspetto diverso delle necessità degli utenti.

Per una dimostrazione video, vedere lo screencast sulla modellazione del dominio aziendale.

Un modello requisiti consente di:

• Concentrarsi sul comportamento esterno del sistema, separatamente dalla progettazione interna.

• Descrivere le necessità di utenti e parti interessate con molta meno ambiguità rispetto al linguaggio naturale.

• Definire un glossario di termini coerente che possa essere utilizzato da utenti, sviluppatori e tester.

• Ridurre gap e incoerenze nei requisiti.

• Ridurre il lavoro necessario per rispondere alle modifiche dei requisiti.

• Pianificare l'ordine in cui verranno sviluppate le funzionalità.

• Utilizzare i modelli come base per i test di sistema, evidenziando una chiara relazione tra test e requisiti.Quando i requisiti vengono modificati, questa relazione consente di aggiornare i test correttamente,garantendo in tal modo che il sistema soddisfi i nuovi requisiti.

Un modello requisiti offre un vantaggio maggiore se viene utilizzato per concentrare le discussioni con gli utenti o i relativi rappresentanti e se viene riesaminato all'inizio di ogni iterazione.Non è necessario completarlo in dettaglio prima di scrivere il codice.Un'applicazione parzialmente funzionante, anche se molto semplificata, crea in genere una base di discussione dei requisiti con gli utenti molto più stimolante.Il modello consente di riepilogare in modo efficace i risultati di tali discussioni.Per ulteriori informazioni, vedere Utilizzo di modelli nel processo di sviluppo.

[!NOTA]

In questi argomenti con "sistema" si intende il sistema o l'applicazione che si sta sviluppando.Potrebbe trattarsi di una raccolta di grandi dimensioni di molti componenti software e hardware, di una singola applicazione o di un componente software all'interno di un sistema più grande.In ogni caso, il modello requisiti descrive il comportamento visibile dall'esterno del sistema, sia tramite un'interfaccia utente che tramite un'API.

Attività comuni

È possibile creare molte visualizzazioni diverse dei requisiti degli utenti.Ogni visualizzazione fornisce un determinato tipo di informazioni.Quando si creano queste visualizzazioni, è consigliabile spostarsi frequentemente dall'una all'altra.È possibile iniziare da qualsiasi visualizzazione.

Si noti che la maggior parte dei tipi di diagrammi può essere utilizzata per altri scopi.Per una panoramica dei tipi di diagrammi, vedere Sviluppo di modelli per la progettazione software.Per le informazioni di base sulla creazione dei diagrammi, vedere Procedura: modificare modelli e diagrammi UML.

Descrizione del modo in cui viene utilizzato il sistema

Creare diagrammi casi di utilizzo per descrivere chi utilizza il sistema e le relative attività svolte.Un caso di utilizzo rappresenta un obiettivo di un utente del sistema e la procedura eseguita per il raggiungimento dell'obiettivo.

Si consideri ad esempio un sistema di vendita di pasti online che deve consentire ai clienti di scegliere elementi da un menu e ai ristoranti di aggiornare il menu.È possibile riepilogare tale condizione in un diagramma caso di utilizzo:

È inoltre possibile illustrare come un caso di utilizzo sia costituito da casi più piccoli.Ad esempio, l'ordinazione di un pasto fa parte del processo di acquisto di un pasto, che comprende anche il pagamento e la consegna:

È inoltre possibile illustrare i casi di utilizzo inclusi nell'ambito del sistema che si sta sviluppando.Ad esempio, il sistema raffigurato nell'illustrazione non fa parte del caso di utilizzo Consegna pasto.In questo modo è possibile impostare il contesto per il lavoro di sviluppo.In un diagramma caso di utilizzo i contenitori del sottosistema possono essere utilizzati per rappresentare il sistema o i relativi componenti.

Consente inoltre al team di discutere cosa includere nelle versioni successive.Ad esempio, è possibile discutere se nella versione iniziale del sistema Pagamento pasto viene incluso direttamente tra il ristorante e il cliente, anziché passare per il sistema.In tal caso, è possibile spostare Pagamento pasto all'esterno del rettangolo del Sistema Dinner Now per la versione iniziale.

Un diagramma caso di utilizzo fornisce solo un riepilogo dei casi di utilizzo.Per fornire descrizioni più dettagliate, è possibile collegare i casi di utilizzo nel diagramma a documenti separati e ad altri diagrammi.Per informazioni su come eseguire questa operazione, vedere Procedura: collegare un caso di utilizzo a documenti e diagrammi.

La creazione di un diagramma caso di utilizzo consente al team di:

• Concentrarsi sulle attività che gli utenti prevedono di eseguire con il sistema, senza farsi distrarre dai dettagli dell'implementazione.

• Discutere l'ambito del sistema o le specifiche versioni del sistema.

Per ulteriori informazioni, consultare gli argomenti seguenti:

Definizione dei termini utilizzati per descrivere i requisiti

È possibile utilizzare i diagrammi classi UML per sviluppare un vocabolario coerente dei concetti aziendali utilizzati per gli scopi seguenti:

• Dagli utenti stessi per presentare l'azienda in cui utilizzare il sistema.

• Per descrivere le necessità degli utenti, ad esempio nelle descrizioni di casi di utilizzo, regole business e storie utente.

• I tipi di informazioni scambiate mediante l'API del sistema o l'interfaccia utente.

• Descrizioni di test di sistema o di accettazione.

Quando utilizzato per questo scopo, il contenuto di un diagramma classi UML viene denominato diagramma classi concettuali.È noto anche come modello di dominio o modello di classe di analisi.

In un diagramma classi concettuali, vengono illustrate solo le classi necessarie nelle descrizioni dei requisiti, senza illustrare alcun dettaglio della progettazione interna del sistema.Nel diagramma non viene illustrato alcun dettaglio della progettazione interna del sistema.Nelle classi concettuali non vengono in genere rappresentate operazioni o interfacce.

Si provi ad esempio a creare le classi concettuali per il sistema Dinner Now:

Un diagramma classi concettuali fornisce il vocabolario di termini utilizzati in tutto il modello requisiti.Ad esempio, nella descrizione dettagliata del caso di utilizzo Ordinazione pasto, è possibile scrivere:

Il cliente sceglie un Menu da cui creare un Ordine, quindi crea gli Elementi ordine nell' Ordine selezionando gli Elementi menu dal Menu.

Si noti come i termini utilizzati nella descrizione sono nomi di classi del modello.Il diagramma rimuove le ambiguità dalle relazioni tra le classi.Ad esempio, mostra chiaramente che a ogni Ordine è associato un solo Menu.

I malintesi sui requisiti degli utenti possono frequentemente essere attribuiti ai malintesi sui significati dettagliati delle parole.Ad esempio, la maggior parte dei ristoranti avrà una comprensione condivisa dei termini Menu e Ordine, ma la differenza tra un elemento di un Ordine e un elemento di un Menu risulta meno chiara.Quando i requisiti vengono discussi con le parti interessate dell'azienda, è importante esporre tali differenze.Il diagramma classi è uno strumento utile per chiarire i termini e le relative relazioni.

Il modello di classi concettuali può formare il vocabolario di base con cui può essere descritta la logica di business del sistema.Ma le classi nel software sono in genere molto più complesse del modello concettuale, perché l'implementazione deve considerare problemi quali prestazioni, distribuzione, flessibilità e altri fattori.Spesso in un unico sistema sono presenti diverse implementazioni di una classe concettuale.

Gli Ordini ad esempio potrebbero essere rappresentati in XML, SQL, HTML e C# in diverse parti del sistema e in diverse interfacce tra le parti.L'associazione tra un Ordine e un Menu potrebbe essere rappresentata in molti modi diversi, ad esempio con riferimenti all'interno del codice C#, con relazioni in un database o con ID a riferimenti incrociati nel codice XML.Nonostante queste variazioni, il modello concettuale fornisce informazioni importanti che sono reali in ogni parte del software.Il diagramma classi nell'esempio indica che in ogni implementazione ci sarà solo un Menu associato a ogni Ordine.

La creazione di un diagramma classi dei requisiti consente al team di:

• Definire e standardizzare i termini di base utilizzati nelle discussioni sulle necessità degli utenti.

• Chiarire le relazioni tra tali termini.

Per ulteriori informazioni, consultare gli argomenti seguenti:

In un diagramma classi concettuale non è in genere utile posizionare le frecce sulle associazioni per rappresentare l'esplorabilità.Ciò è dovuto al fatto che il diagramma non rappresenta un'implementazione.Le associazioni rappresentano le relazioni tra oggetti reali.Nell'estensione di Visual Studio seguente le frecce sono non direzionali per impostazione predefinita: Esempio: funzionalità di modellazione di un dominio UML.

Visualizzazione delle regole business

Una regola business è un requisito che non è associato a un particolare caso di utilizzo e deve essere osservata in tutto il sistema.

Molte regole business sono vincoli sulle relazioni tra le classi concettuali.È possibile scrivere le regole businessstatiche come commenti associati alle relative classi di un diagramma classi concettuali.Ad esempio:

Le regole business dinamiche vincolano le sequenze di eventi consentite.È possibile ad esempio utilizzare una diagramma di attività o di sequenza per indicare che un utente deve effettuare l'accesso prima di eseguire le altre operazioni nel sistema.

Tuttavia, molte regole dinamiche possono essere illustrate più efficacemente e genericamente sostituendole con le regole statiche.Ad esempio, è possibile aggiungere un attributo booleano 'Connesso' in una classe del modello di classi concettuali.L'attributo Connesso viene aggiunto come postcondizione della registrazione nel caso di utilizzo e come precondizione della maggior parte degli altri casi di utilizzo.Questo approccio consente di evitare di definire tutte le combinazioni possibili di sequenze di eventi.Inoltre, è più flessibile quando è necessario aggiungere nuovi casi di utilizzo al modello.

Si noti che la scelta in questo caso verte sul modo in cui definire i requisiti ed è indipendente dal modo in cui vengono implementati i requisiti nel codice programma.

Per ulteriori informazioni, consultare gli argomenti seguenti:

Descrizione dei requisiti di qualità del servizio

Sono disponibili diverse categorie di requisito di qualità del servizio,tra cui:

• Prestazioni

• Sicurezza

• Usabilità

• Affidabilità

• Efficienza

È possibile includere alcuni di questi requisiti nelle descrizioni di specifici casi di utilizzo.Gli altri requisiti non sono specifici dei casi di utilizzo e vengono scritti più efficacemente in un documento separato.Quando possibile, è utile rispettare il vocabolario definito dal modello requisiti.Si noti che nell'esempio seguente le parole principali utilizzate nel requisito sono i titoli di attori, casi di utilizzo e classi delle illustrazioni precedenti:

Se un Ristorante elimina un Elemento menu mentre un Cliente ordina un pasto, tutti gli Elementi ordine che fanno riferimento all'Elemento menu verranno visualizzati in rosso.

Per ulteriori informazioni, consultare gli argomenti seguenti:

Visualizzazione del flusso di lavoro tra gli utenti e il sistema

È possibile utilizzare un diagramma di attività per mostrare il flusso di lavoro tra diversi casi di utilizzo.In genere è utile iniziare un modello requisiti creando un diagramma di attività che illustri le attività principali eseguite dagli utenti, sia con il sistema che all'esterno.

Ad esempio:

È possibile creare diagrammi casi di utilizzo e diagrammi di attività per mostrare visualizzazioni diverse delle stesse informazioni.Il diagramma caso di utilizzo è più efficace in quanto mostra l'annidamento delle azioni più piccole all'interno dell'attività più grande, ma non mostra il flusso di lavoro.Ad esempio:

Si noti che è possibile utilizzare i diagrammi di attività anche per rappresentare gli algoritmi all'interno del software, ma quando si utilizzano i diagrammi per il processo aziendale, l'attenzione viene incentrata sulle azioni visibili all'esterno del sistema.

Per ulteriori informazioni, consultare gli argomenti seguenti:

Visualizzazione delle interazioni tra gli utenti e il sistema

È possibile utilizzare un diagramma di sequenza per mostrare l'interscambio di messaggi tra il sistema e gli attori esterni o tra le parti del sistema.In questo modo vengono visualizzati i passaggi di un caso di utilizzo che mostra molto chiaramente la sequenza di interazioni.I diagrammi di sequenza sono particolarmente utili nelle situazioni in cui sono presenti molte parti che interagiscono tra di loro in un caso di utilizzo e inoltre qualora il sistema disponga di un'API.

Ad esempio:

Un vantaggio dei diagrammi di sequenza è dato dal fatto che è semplice visualizzare i messaggi che entrano nel sistema che si sta costruendo.Per progettare il sistema, è possibile sostituire la singola linea di vita del sistema con una linea di vita separata per ognuno dei componenti e mostrare quindi le interazioni tra di essi in risposta a ogni messaggio in arrivo.

Per ulteriori informazioni, consultare gli argomenti seguenti:

Utilizzo di un modello per ridurre le incoerenze

La creazione di un modello comporta generalmente una riduzione significativa di incoerenze e ambiguità nei requisiti degli utenti.Le diverse parti interessate danno in genere diverse interpretazioni del mondo aziendale in cui viene utilizzato il sistema.Pertanto la prima attività è risolvere queste differenze tra i clienti.

Molte domande sul dominio aziendale sorgeranno naturalmente durante la creazione di un modello.Ponendo agli utenti alcune domande specifiche, si ridurrà la necessità di modifiche in una fase successiva del progetto.Di seguito sono riportate alcune domande specifiche da porre innanzitutto a se stessi e quindi alle parti interessate all'interno dell'azienda se la risposta è poco chiara:

• Per ogni classe del modello requisiti, chiedere "Quale caso di utilizzo crea istanze di questa classe?". In un servizio di ordinazione pasti online, ad esempio, si potrebbe chiedere "Quale caso di utilizzo crea istanze della classe Menu ristorante?". Questa domanda porta ad esaminare in che modo un nuovo ristorante si iscrive al servizio e fornisce il proprio menu.È possibile porre domande simili sugli elementi che creano o modificano gli attributi e le associazioni.

• Per ogni caso di utilizzo del modello requisiti, provare a descrivere il risultato o la postcondizione con le parole fornite dai diagrammi classi.In genere è utile mostrare l'effetto di un caso di utilizzo delineando alcuni cenni sulle istanze delle classi prima e dopo il verificarsi del caso di utilizzo.Se ad esempio la postcondizione del caso di utilizzo indica che "un elemento menu viene aggiunto all'ordine cliente", delineare istanze delle classi Ordine ed Elemento menu.Mostrare gli effetti del caso di utilizzo, ad esempio un nuovo collegamento o un nuovo oggetto, in un colore diverso o in un nuovo disegno.Questi elementi avviano in genere discussioni su quali informazioni sono necessarie nel modello.Sebbene le classi di requisiti non riguardano direttamente l'implementazione, esse descrivono le informazioni che il sistema dovrà archiviare e trasmettere.

• Porre domande sui vincoli su attributi e associazioni, soprattutto sui vincoli che riguardano più attributi o associazioni.

• Porre domande sulle sequenze valide e non valide dei casi di utilizzo, creando diagrammi di sequenza o di attività per illustrarle.

Esaminando le relazioni tra le visualizzazioni fornite dai diversi diagrammi, è possibile comprendere rapidamente i concetti principali utilizzati dagli utenti, consentendo loro di capire ciò di cui hanno bisogno dal sistema.È inoltre possibile ottenere una migliore comprensione dei requisiti di cui le parti interessate sono meno sicure.È possibile iniziare a sviluppare tali funzionalità, almeno in formato semplice nella fase iniziale del progetto, in modo da poter essere sperimentate dagli utenti.

Vedere anche

Concetti

Procedura: modificare modelli e diagrammi UML

Sviluppo di test da un modello

Utilizzo di modelli nel processo di sviluppo

Modellazione dell'architettura di un sistema software

Altre risorse

Esempio di estensione di Visual Studio: funzionalità di modellazione di un dominio UML

Esempio di estensione di Visual Studio: colorazione di elementi UML per stereotipo

Esempio di estensione di Visual Studio: collegamento di elementi UML a diagrammi, file e altri elementi

Esempio di estensione di Visual Studio: allineamento di forme in un diagramma UML

Video: modellazione del dominio aziendale