Sviluppare requisiti

I requisiti descrivono ciò che le parti interessate si aspettano dal prodotto. Esprimere i requisiti in termini che consentano una semplice discussione con le parti interessate all'interno dell'azienda, usando vocaboli e concetti in uso nel dominio aziendale. I requisiti non devono mettere in discussione l'implementazione né dipenderne. I requisiti non includono solo le aspettative degli utenti relativamente a comportamento e qualità del servizio, ma anche vincoli legali e standard commerciali.

Creando i requisiti in TFS è possibile ottenere i vantaggi seguenti:

• Verificare che i requisiti siano stati soddisfatti collegandoli a test case.

• Monitorare lo stato dell'implementazione dei requisiti collegandoli a elementi di lavoro attività.

• Strutturare i requisiti in requisiti globali e più dettagliati, in modo che sia possibile gestirli più facilmente e che le informazioni possano essere riepilogate in report sullo stato.

• Modellare i requisiti in Visual Studio Ultimate, collegando gli elementi del modello ai requisiti in Team Foundation Server.

La finalità di questo argomento non è quella di replicare gli abbondanti volumi di documentazione disponibili in materia di determinazione dei requisiti. Vengono invece analizzati gli aspetti importanti per l'uso degli strumenti di Visual Studio in modo conforme a CMMI. Per altre informazioni su CMMI, vedere Informazioni generali su CMMI.

Le attività descritte in questo argomento, analogamente a qualsiasi attività di sviluppo, non devono essere eseguite in base a un ordine rigido. Sviluppare un modello di dominio mentre si scrivono scenari, in quanto un'attività consentirà di migliorare l'altra. Sviluppare gli scenari quando si avvicina il momento della relativa codifica. Usare l'esperienza con codice scritto e dimostrato in scenari che devono essere ancora implementati.

Quando sviluppare i requisiti

TFS supporta il funzionamento iterativo e questa pratica è particolarmente efficace quando le iterazioni iniziali vengono usate per ottenere commenti e suggerimenti da parte di potenziali utenti e di altre parti interessate. Questi commenti e suggerimenti possono essere usati per migliorare i requisiti stabiliti per le iterazioni future. In questo modo, l'installazione finale del prodotto risulta molto più efficace rispetto a un prodotto sviluppato nello stesso periodo senza alcuna valutazione da parte degli utenti. Se il progetto è un componente tra tanti di un programma di dimensioni più ampie, l'integrazione con gli altri componenti nelle fasi iniziali consente ai progettisti del programma di migliorare il prodotto globale.

È necessario trovare il giusto bilanciamento tra flessibilità e necessità di definire impegni rigorosi per il cliente o i partner nei progetti paralleli.

In misura controllata, pertanto, i requisiti vengono sviluppati e perfezionati nel corso di tutto il progetto. Poiché è probabile che i requisiti dettagliati cambino durante il progetto, la loro completa definizione prima dell'implementazione appropriata comporta con ogni probabilità uno sforzo inutile.

• Durante l'iterazione 0, sviluppare un set di requisiti per descrivere le funzionalità principali, con una quantità di dettagli sufficiente a formare un piano del prodotto. Il piano del prodotto assegna i requisiti alle iterazioni e stabilisce quale requisito verrà soddisfatto alla fine di ogni iterazione. Creare un modello di dominio dei concetti e delle attività principali e definire il vocabolario che verrà usato per tali concetti sia nella discussione con gli utenti che nell'implementazione. Determinare requisiti ampi che coprano ogni funzionalità, ad esempio sicurezza e altri requisiti di qualità del servizio.

• In prossimità o in corrispondenza dell'inizio di ogni iterazione, sviluppare i requisiti per tali funzionalità in modo più dettagliato. Determinare i passaggi che verranno seguiti dagli utenti, definendoli con l'aiuto di diagrammi di attività o di sequenza. Definire ciò che si verifica in casi eccezionali.

• Verificare il più spesso possibile tutti i requisiti implementati. I requisiti pervasivi, ad esempio quelli relativi alla sicurezza, devono essere verificati con test estesi per ogni nuova funzionalità. Se possibile, automatizzare i test, in quanto i test automatici possono essere eseguiti continuamente.

Gestione delle modifiche dei requisiti

Le linee guida seguenti consentono di attuare un processo incrementale eseguendone nel contempo il monitoraggio per soddisfare i requisiti CMMI.

• Non modificare i requisiti impostati per un'iterazione. Nel raro caso di un cambiamento improvviso delle circostanze, potrebbe essere necessario annullare un'iterazione, rivedere il piano del prodotto e avviare una nuova iterazione.

• Verificare se sono presenti incertezze nei requisiti. Provare a modificare il piano in modo che l'esperienza utente con le iterazioni iniziali generi informazioni in grado di ridurre le incertezze.

• Usare elementi di lavoro richiesta modifiche per registrare le richieste di modifica del comportamento che sono già state implementate, a meno che il miglioramento richiesto non faccia già parte del piano. Collegare ogni richiesta modifiche agli elementi di lavoro dei requisiti appropriati.

• Rivedere le richieste modifiche quando si rivede il prodotto prima di ogni iterazione. Esaminare l'impatto della richiesta su utenti e progetti dipendenti e stimare il costo relativo alle modifiche nel codice. Se viene accettata una richiesta di modifica, aggiornare il requisito.

• Aggiornare i test per adattarli a ogni modifica dei requisiti.

• Stabilire una data limite (ad esempio, dopo l'iterazione 2 o 3) dopo la quale le modifiche dei requisiti devono essere motivate da una giustificazione più che valida. Se il progetto è per un cliente pagante, si tratta della data in cui il cliente deve approvare un set di base di requisiti e passare dal pagamento orario a un prezzo fisso.

• Usare elementi di lavoro bug per registrare il comportamento implementato non conforme ai requisiti espliciti o impliciti. Quando appropriato, creare un nuovo test che avrebbe consentito di intercettare il bug.

Scrivere una dichiarazione della visione

Discutere una dichiarazione della visione con il team e visualizzarla sul portale Web del progetto per Team Foundation Server.

Una dichiarazione della visione è un breve riepilogo dei vantaggi offerti dal prodotto. Che cosa saranno in grado di fare gli utenti, in più rispetto al passato? La dichiarazione della visione consente di chiarire l'ambito del prodotto.

Se il prodotto esiste già, scrivere una dichiarazione della visione per la versione corrente. Che cosa saranno in grado di fare gli utenti del prodotto, in più rispetto al passato?

Scrivere scenari

Collaborare con il cliente e le altre parti interessate per creare scenari e immetterli come elementi di lavoro dei requisiti, con il campo Tipo di requisito impostato su Scenario.

Uno scenario o un caso di utilizzo è un resoconto che descrive una sequenza di eventi, illustra in che modo viene realizzato un particolare obiettivo e in genere comporta l'interazione tra persone o organizzazioni e computer.

Assegnare allo scenario un titolo descrittivo che lo distingua chiaramente dagli altri quando viene visualizzato in un elenco. Assicurarsi che vengano indicati l'attore o gli attori principali e che l'obiettivo sia chiaro. Un titolo appropriato potrebbe, ad esempio, essere il seguente:

Il cliente acquista un pasto.

È possibile scrivere uno scenario adottando i formati seguenti. Talvolta può essere utile usare più di un formato:

• Una o due frasi nella descrizione dell'elemento di lavoro:

  Un cliente ordina un pasto in un sito Web e paga con una carta di credito. L'ordine viene passato a un ristorante, che prepara e consegna il pasto.

• Passaggi numerati nella descrizione dell'elemento di lavoro:

  Un cliente visita il sito Web e crea un ordine per un pasto. Il sito Web reindirizza il cliente a un sito per il pagamento. L'ordine viene aggiunto all'elenco di lavoro del ristorante. Il ristorante prepara e consegna il pasto.

• Storyboard. Uno storyboard è essenzialmente una striscia di vignette in cui è raccontata la storia. Per disegnarlo, è possibile usare PowerPoint. Collegare il file dello storyboard all'elemento di lavoro requisito o caricare il file nel portale del team e aggiungere un collegamento ipertestuale all'elemento di lavoro.

  Uno storyboard è particolarmente utile per illustrare le interazioni dell'utente. Per uno scenario aziendale, tuttavia, è consigliabile usare uno stile schizzo che faccia chiaramente capire che non si tratta del progetto finale per l'interfaccia utente.

• Documenti dei requisiti. I documenti dei requisiti offrono la libertà di fornire il livello appropriato di dettaglio per ogni requisito. Se si decide di usare i documenti, creare un documento di Word per ogni requisito e allegare il documento all'elemento di lavoro requisito o caricare il file nel portale del team e aggiungere un collegamento ipertestuale all'elemento di lavoro.

• Diagramma di sequenza UML (Unified Markup Language). Un diagramma di sequenza è particolarmente utile in caso di interazione di diverse parti. Per l'ordine di un pasto è ad esempio necessaria l'interazione tra cliente, sito Web DinnerNow, sistema di pagamento e ristorante, in base a una sequenza specifica. Disegnare il diagramma di sequenza in un modello UML, archiviarlo in Team Foundation Server e immettere un collegamento nell'elemento di lavoro requisito. Per altre informazioni, vedere Diagrammi di sequenza UML: linee guida.

Scenari specifici

Iniziare scrivendo scenari specifici che seguono un particolare set di attori attraverso una sequenza specifica. Ad esempio, "Carlos ordina una pizza e il pane all'aglio nel sito Web DinnerNow. Il sito Web reindirizza Carlos al servizio di pagamento della Woodgrove Bank. Fourth Coffee prepara la pizza e la consegna".

Scenari specifici consentono di visualizzare il sistema in uso e sono particolarmente utili quando si esplora per la prima volta una funzionalità.

Può inoltre essere utile creare personaggi a cui viene assegnato un nome e che descrivono il background e altre attività di persone e organizzazioni. Carlos ha il sonno difficile e usa un Internet café, Wendy vive in una zona residenziale sorvegliata, Sanjay ordina i pasti per la moglie al lavoro, Contoso gestisce una catena di 2.000 ristoranti sparsi in tutto il mondo, Fourth Coffee è gestito da una coppia che fa le consegne in bicicletta.

Scenari più generici scritti in termini di "un cliente", "una voce di menu" e così via possono essere più comodi ma portano con meno probabilità all'individuazione di funzionalità utili.

Livelli di dettaglio

Nell'iterazione 0 scrivere alcuni scenari importanti in modo dettagliato, ma presentare la maggior parte degli scenari solo a grandi linee. Quando si affronta un'iterazione in cui deve essere implementato, completamente o in parte, uno scenario specifico, aggiungere maggiori dettagli.

Quando si prende in considerazione per la prima volta uno scenario, può essere utile descrivere il contesto aziendale, inclusi gli aspetti in cui il prodotto non è coinvolto. Descrivere ad esempio il metodo di consegna di DinnerNow: ogni ristorante organizza le proprie consegne oppure il servizio di consegna è gestito da DinnerNow? Le risposte a tali domande forniscono un contesto utile per il team di sviluppo.

Gli scenari più dettagliati sviluppati all'inizio di un'iterazione possono descrivere le interazioni dell'interfaccia utente, mentre gli storyboard possono mostrare il layout dell'interfaccia utente.

Organizzazione degli scenari

È possibile organizzare gli scenari usando i metodi seguenti:

• Disegnare diagrammi casi di utilizzo in cui ogni scenario viene rappresentato come un caso di utilizzo. Questo metodo è consigliato in quanto semplifica notevolmente la presentazione e la discussione degli scenari. Per altre informazioni, vedere Diagrammi casi di utilizzo UML: linee guida.

  • Collegare ogni caso di utilizzo all'elemento di lavoro che definisce lo scenario. Per altre informazioni, vedere Collegare elementi di modello ed elementi di lavoro.

  • Disegnare relazioni di estensione per mostrare che uno scenario costituisce una variazione di un altro. Ad esempio, "Il cliente specifica indirizzi di pagamento e di consegna distinti" è un'estensione del caso di utilizzo di base "Il cliente effettua un ordine". Le estensioni sono particolarmente utili per separare scenari che verranno implementati in un'iterazione successiva.

  • Disegnare relazioni di inclusione per separare una procedura come "Il cliente effettua l'accesso", comune a diversi casi di utilizzo.

  • Disegnare relazioni di generalizzazione tra scenari generali come "Il cliente paga" e varianti specifiche come "Il cliente paga tramite carta di credito".

• Creare collegamenti padre-figlio tra gli elementi di lavoro dello scenario. È possibile visualizzare la gerarchia in Team Explorer. Per altre informazioni, vedere Organizzazione requisiti in un piano del prodotto.

Modellare il dominio aziendale

Creare un modello UML che descriva le attività e i concetti principali coinvolti nell'uso del prodotto. Usare i termini definiti in questo modello come "linguaggio universale", negli scenari, nelle discussioni con le parti interessate, nell'interfaccia utente e in tutti i manuali dell'utente, nonché nel codice stesso.

Molti requisiti non vengono dichiarati in modo esplicito dal cliente e la comprensione dei requisiti impliciti dipende da una comprensione del dominio aziendale, ovvero del contesto in cui verrà usato il prodotto. Parte del lavoro di raccolta dei requisiti in un dominio non familiare consiste, pertanto, nell'acquisire una conoscenza di tale contesto. Dopo essere stata acquisita, una conoscenza di questo tipo può essere usata in più di un progetto.

Salvare il modello nel controllo della versione.

Per altre informazioni, vedere Modellare i requisiti utente.

Modellazione dei comportamenti

Disegnare i diagrammi di attività per riepilogare gli scenari. Usare le corsie per raggruppare le azioni eseguite da diversi attori. Per altre informazioni, vedere Diagrammi di attività UML: linee guida.

Sebbene uno scenario descriva in genere una sequenza specifica di eventi, un diagramma di attività illustra tutte le possibilità. Disegnando un diagramma di attività si può essere portati a pensare alle sequenze alternative e a chiedere ai clienti aziendali cosa avverrebbe in tali casi.

La figura seguente illustra un semplice esempio di digramma di attività.

Nei casi in cui lo scambio di messaggi è importante, potrebbe essere preferibile usare un diagramma di sequenza che includa una linea di vita per ogni attore e ogni componente principale del prodotto.

I diagrammi casi di utilizzo consentono di riepilogare i diversi flussi di attività supportati dal prodotto. Ogni nodo nel diagramma rappresenta una serie di interazioni tra gli utenti e l'applicazione alla ricerca di un obiettivo utente specifico. È anche possibile scomporre sequenze comuni ed estensioni facoltative in nodi di casi di utilizzo separati. Per altre informazioni, vedere Diagrammi casi di utilizzo UML: linee guida.

La figura seguente illustra un semplice esempio di digramma di caso di utilizzo.

Modellazione dei concetti

Disegnare i diagrammi classi di dominio per descrivere le entità importanti e le relative relazioni menzionate negli scenari. Nel modello DinnerNow sono ad esempio presenti le entità relative a ristorante, menu, ordine, voce di menu e così via. Per altre informazioni, vedere Diagrammi classi UML: linee guida.

Etichettare i ruoli (estremità) delle relazioni con nomi e cardinalità.

In un diagramma classi di dominio in genere non si collegano le operazioni alle classi. Nel modello di dominio i diagrammi di attività descrivono il comportamento. L'assegnazione di responsabilità per la programmazione di classi fa parte del lavoro di sviluppo.

La figura seguente illustra un semplice esempio di un digramma di classi.

Vincoli statici

Aggiungere ai diagrammi classi i vincoli che regolano gli attributi e le relazioni. Le voci di un ordine devono ad esempio provenire tutte dallo stesso ristorante. Questi tipi di regole sono importanti per la progettazione del prodotto.

Coerenza del modello

Assicurarsi che il modello e gli scenari siano coerenti. Uno degli scopi più importanti di un modello è quello di risolvere le ambiguità.

• Nelle descrizioni degli scenari vengono usati i termini definiti nel modello e tali descrizioni sono coerenti con le relazioni definite. Se il modello definisce le voci di menu, gli scenari non devono riferirsi allo stesso elemento sotto forma di prodotti. Se il diagramma classi mostra che una voce di menu appartiene esattamente a un menu, negli scenari non si deve parlare di condivisione di una voce tra i menu.

• Ogni scenario descrive una serie di passaggi consentiti dai diagrammi di attività.

• Gli scenari o le attività descrivono in che modo le classi e le relazioni nel diagramma classi vengono create ed eliminate in modo permanente. Quale scenario, ad esempio, comporta la creazione di una voce di menu? Quando un ordine viene eliminato in modo permanente?

Sviluppare requisiti di qualità del servizio

Creare elementi di lavoro che specificano i requisiti di qualità del servizio. Impostare il campo Tipo di requisito su Qualità del servizio.

La qualità del servizio o i requisiti non funzionali includono prestazioni, usabilità, affidabilità, disponibilità, integrità dei dati, sicurezza, accessibilità, praticità e semplicità di aggiornamento, comodità di distribuzione, manutenibilità, progettazione e adeguatezza.

Considerare ognuna di queste categorie per ogni scenario.

Il titolo di ogni requisito di qualità del servizio deve racchiuderne la definizione presentando un contesto, un'azione e una misura. È ad esempio possibile creare il requisito seguente: "Durante una ricerca nel catalogo, restituire i risultati della ricerca in meno di tre secondi".

È inoltre utile acquisire un numero maggiore di dettagli volti a illustrare i motivi per cui il requisito è necessario. Descrivere i motivi dell'importanza del requisito e della necessità del livello di servizio. Fornire contesto e giustificazione. Questa spiegazione potrebbe includere informazioni utili sulla gestione dei rischi, ad esempio dati di un'indagine di mercato, un gruppo di studio dei clienti, uno studio di usabilità, report/ticket del supporto tecnico o un altro tipo di evidenza aneddotica.

Collegare il requisito di qualità del servizio a qualsiasi scenario (elemento di lavoro requisito) interessato dalla qualità del servizio. Il collegamento di elementi di lavoro correlati consente agli utenti di Team Foundation Server di tenere traccia di requisiti dipendenti. Le query e i report possono illustrare in che modo i requisiti di qualità del servizio influiscono sui requisiti funzionali acquisiti come scenari.

Rivedere i requisiti

Dopo avere scritto o aggiornato i requisiti, è necessario che le parti interessate li rivedano per garantire che tutte le interazioni degli utenti con il prodotto siano descritte in modo adeguato. Tra le parti interessate comuni possono essere inclusi un esperto in materia, un business analyst e un progettista dell'esperienza utente. Gli scenari vengono inoltre rivisti per garantire che possano essere implementati nel progetto senza creare confusione o problemi. Se vengono rilevati problemi, è necessario correggere gli scenari in modo da renderli validi a conclusione di questa attività.

Creare un elemento di lavoro revisione per tenere traccia della revisione. Questo elemento fornisce una prova importante per una valutazione SCAMPI (Standard CMMI Appraisal Method for Process Improvement) e può costituire una buona fonte di informazioni per l'analisi futura delle cause radice.

Rivedere ogni scenario prestando attenzione alle caratteristiche seguenti:

• Lo scenario è scritto nel contesto delle attività che gli utenti devono eseguire, di ciò che già sanno e di come prevedono di interagire con il prodotto.

• Lo scenario delinea un problema e non viene oscurato dalle soluzioni proposte per il problema.

• Vengono identificate tutte le interazioni rilevanti degli utenti con il prodotto.

• L'esperto in materia, il business analyst e il progettista dell'esperienza utente rivedono ogni scenario nel contesto del progetto per verificare che tutti gli scenari possano essere implementati correttamente. Se uno scenario non è valido, viene revisionato in modo da renderlo valido.

• Lo scenario può essere implementato con le tecniche, gli strumenti e le risorse disponibili e rispettando il budget e la pianificazione.

• Lo scenario prevede una sola interpretazione di semplice comprensione.

• Lo scenario non è in conflitto con un altro scenario.

• Lo scenario è testabile.

Convalida

Pianificare la distribuzione di versioni beta del prodotto nell'ambiente di lavoro prima del rilascio della versione finale. Pianificare l'aggiornamento dei requisiti, in base ai commenti e suggerimenti delle parti interessate relativi a tale distribuzione.

La convalida garantisce che il prodotto sia appropriato per l'uso desiderato nell'ambiente operativo. In MSF per CMMI la convalida viene ottenuta illustrando il software funzionante alle parti interessate alla fine di ogni iterazione nel corso del progetto. La pianificazione viene definita in modo tale che eventuali problematiche sottoposte agli sviluppatori in seguito alle dimostrazioni preliminari possano essere trattate nel piano delle rimanenti iterazioni.

Per ottenere una reale convalida, il prodotto non deve essere eseguito solo in un contesto dimostrativo o simulato. Se possibile, deve essere testato in condizioni reali.

Controllo e modifica dei requisiti

Lo scenario e i requisiti di qualità del servizio, da cui scaturisce la maggior parte delle attività di sviluppo, possono essere controllati in base alla query per i requisiti del cliente. Se si preferisce visualizzare tutti i requisiti, è possibile scrivere una query che restituisca tutti gli elementi di lavoro del tipo di elemento di lavoro requisito. Impostare le colonne del risultato in modo che venga mostrato il percorso di iterazione.

Il team deve creare la maggior parte dei requisiti nelle prime iterazioni del progetto. Man mano che vengono ottenuti commenti e suggerimenti dalle prime versioni, verranno aggiunti nuovi requisiti o modificati quelli esistenti.

Risorse aggiuntive

Per ulteriori informazioni, vedere le risorse Web seguenti:

• A Practical Guide to Feature Driven Development, Stephen R. Palmer e Malcolm J. Felsing; Prentice-Hall PTR, 2002.

• Streamlined Object Modeling: Patterns, Rules and Implementation, Jill Nicola, Mark Mayfield e Mike Abney; Prentice Hall PTR, 2001.

• Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, Scott Ambler; Wiley, 2002.

• Domain Driven Design: Tackling Complexity in the Heart of Software, Eric Evans; Addison Wesley Professional, 2003.

• Object Design: Roles, Responsibilities and Collaborations, Rebecca Wirfs-Brock and Alan McKean; Addison Wesley Professional, 2002.