Sviluppare requisiti

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

Creando requisiti in TFS è possibile ottenere i seguenti vantaggi:

• 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 rapporti 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'utilizzo degli strumenti di Visual Studio in modo conforme a CMMI. Per ulteriori 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. Utilizzare l'esperienza con codice scritto e dimostrato in scenari che devono essere ancora implementati.

Quando sviluppare i requisiti

TFS supporta il lavoro iterativo e questa pratica è più efficiente quando le iterazioni iniziali vengono utilizzate per ottenere feedback da parte di potenziali utenti e di altre parti interessate. Tale feedback può essere utilizzato per migliorare i requisiti che sono stati 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à utilizzato 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 una modifica improvvisa nelle 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.

• Utilizzare elementi di lavoro richiesta di modifica 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 di modifica agli elementi di lavoro requisito appropriati.

• Rivedere le richieste di modifica quando si rivede il prodotto prima ogni iterazione. Esaminare l'impatto della richiesta su utenti e progetti dipendenti e stimare il costo relativo alle modifiche nel codice. Se una richiesta di modifica viene accettata, 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ù robusta. 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.

• Utilizzare 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 requisito, 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 l'attore principale o gli attori principali vengano indicati e che l'obiettivo sia chiaro. Un titolo appropriato potrebbe ad esempio essere il seguente:

Il cliente acquista un pasto.

È possibile scrivere uno scenario nelle forme seguenti. Talvolta può essere utile utilizzare più di una forma:

• 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 utilizzare 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 utilizzare un stile a 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 utilizzare 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 ulteriori informazioni, vedere Diagrammi di sequenza UML: linee guida.

Scenari specifici

Iniziare scrivendo scenari specifici che seguono un particolare set di attori lungo 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 utilizza 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 è gestita 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 avvicina 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 contesto utile per il team di sviluppo.

Negli scenari più dettagliati sviluppati all'inizio di un'iterazione è possibile descrivere le interazioni dell'interfaccia utente e tramite gli storyboard è possibile mostrare il layout dell'interfaccia utente.

Organizzazione degli scenari

È possibile organizzare gli scenari utilizzando i metodi seguenti:

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

  • Connettere ogni caso di utilizzo all'elemento di lavoro che definisce lo scenario. Per ulteriori 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 quale "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 elementi di lavoro dello scenario. È possibile visualizzare la gerarchia in Team Explorer. Per ulteriori 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'utilizzo del prodotto. Utilizzare 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.

Numerosi 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à utilizzato 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 utilizzata in più di un progetto.

Salvare il modello nel controllo della versione.

Per ulteriori informazioni, vedere Modellazione dei requisiti utente.

Modellazione dei comportamenti

Disegnare diagrammi di attività per riepilogare gli scenari. Utilizzare corsie per raggruppare le azioni eseguite da attori diversi. Per ulteriori 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.

Nella figura seguente viene illustrato un semplice esempio di digramma di attività.

Nei casi in cui lo scambio di messaggi è importante, potrebbe essere preferibile utilizzare 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. È inoltre possibile scomporre sequenze comuni ed estensioni facoltative in nodi di casi di utilizzo separati. Per ulteriori informazioni, vedere Diagrammi casi di utilizzo UML: linee guida.

Nella figura seguente viene illustrato un semplice esempio di digramma caso di utilizzo.

Modellazione dei concetti

Disegnare 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 ulteriori 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 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.

Nella figura seguente viene illustrato un semplice esempio di digramma classi.

Vincoli statici

Aggiungere ai diagrammi classi vincoli che governino 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 utilizzati i termini definiti nel modello e tali descrizioni sono coerenti con le relazioni definite. Se il modello definisce voci di menu, gli scenari non devono riferirsi allo stesso elemento con il termine prodotti. Se nel diagramma classi viene mostrato che una voce di menu appartiene esattamente a un menu, negli scenari non si deve parlare di condivisione di una voce tra menu.

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

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

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 misurazione. È 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à, rapporti/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. Tramite query e rapporti è possibile 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 un'evidenza 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 è oscurato da soluzioni proposte per il problema.

• Tutte le interazioni rilevanti degli utenti con il prodotto sono identificate.

• 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 di requisiti, in base ai commenti e suggerimenti delle parti interessate relativi a tale distribuzione.

La convalida garantisce che il prodotto sia appropriato per l'utilizzo 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 del 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 e Alan McKean; Addison Wesley Professional, 2002.