Con questo articolo concludiamo la nostra analisi dei requisiti funzionali e in particolare la comparazione tra la notazione dei casi d’uso e l’approccio delle storie utente. Nel corso dell’articolo evidenziamo ancora una volta come queste due notazioni abbiamo ben poco in comune ed evidenziamo alcuni elementi a cui prestare attenzione per non aggiungere ulteriori rischi al progetto.

Introduzione

Nel corso del precedente articolo [1] ci siamo soffermati a investigare similitudini e differenze tra la notazione degli use case e l’approccio basato sulle user story. Sebbene l’argomento possa sembrare assodato, non appena si comincia a scendere nei dettagli, ci si rende conto che la questione è tutt’altro che ovvia.

Si tratta di un territorio non privo di confusione dovuta anche all’evoluzione del concetto delle user story. All’inizio si trattava di una versione ridotta dei casi d’uso: Goal and Main Scenario. Secondo Alistair Cockburn [2], si trattava della versione “a soli 2 bit di precisione”. Tuttavia, con il passare del tempo il concetto di user story si è evoluto, minimizzando le similitudini con la notazione degli use case e massimando quelle con la lista di feature.

Quest’ultimo è un manufatto (classico documento, foglio elettronico o modello UML [3]) prodotto tipicamente all’avvio di un progetto/iterazione, costituito da una lista di descrizioni concise, corredate da poche informazioni aggiuntive, utilizzate per specificare le esigenze dell’utente, che non dovrebbe includere soluzioni tecnologiche (a meno di vincoli legati a questioni di budget, soluzioni preesistenti, etc.), nè entrare nel dettaglio del comportamento del sistema.

Così come nel caso delle user story, queste esigenze investono varie parti del sistema: requisiti funzionali, requisiti non funzionali, aspetti dell’interfaccia utente, vincoli legali, e così via. Ancora, come nel caso delle Use Story, il loro utilizzo prevede la definizione del dettaglio nelle fasi successive del processo. Insieme a queste similitudini, ci sono anche alcune differenze, tra le quali elenchiamo le principali.

Differenze tra lista feature e storie utente

Anzitutto, le feature hanno un formato libero (codice, titolo e descrizione), mentre è fortemente consigliato che le user story rispettino la struttura delle user story (card):

In qualità di
desidero
in maniera da

La lista delle feature viene poi investigata in dettaglio dal team dei business analyst, supportato dal team di architettura, per dar luogo a un modello completo dei requisiti, che include diagrammi degli use case e relative specifiche, Business Object Model, Business Rules, e così via.

L’evoluzione delle user story, prima della relativa codifica, dipende invece molto dall’impostazione del team. Non è infrequente la scrittura di un flusso sommario su wiki o addirittura la codifica diretta in codice.

Per quanto attiene a questo aspetto relativo alle storie utente, sebbene in linea di principio nulla vieti che anche team votati a un alto grado di agilità decidano di far evolvere le user story in notazioni più formali, come per esempio quella degli use case, in realtà si tratterebbe di una decisione abbastanza unica nel suo genere. Verosimilmente verrebbe percepita come “aliena”, contraria alla natura dell’approccio agile. Inoltre, tale strategia non garantirebbe quella coerenza e riutilizzo dei diagrammi/modelli dei requisiti ottenibile attraverso una maturazione organica del modello dei requisiti rispetto a un approccio ad hoc: requisito definito e modellato nel meeting che precede lo sviluppo.

INVESTiamo

Una delle raccomandazione più seguite nel redigere le user story consiste nell’applicare le direttive INVEST [5], in cui questa parola è l’acronimo ottenuto dalle iniziali dei seguenti concetti:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Vediamo questi aspetti nel dettaglio.

Independent: “indipendente”

Storie indipendenti sono ovviamente più facili da gestire. La situazione ideale si ottiene quando i concetti catturati dalle varie storie non si sovrappongono ed è possibile quindi pianificarne lo sviluppo liberamente. Pertanto, storie indipendenti forniscono un maggiore grado di libertà sia al team di sviluppo sia al Product Owner.

Negotiable: “negoziabile”

Storie ben scritte sono negoziabili. Ciò fa sì che non si tratti di un contratto esplicito per l’implementazione di determinate feature, ma di una necessità i cui dettagli possono essere discussi e concordati dall’utente/cliente e dal team di sviluppo. Storie di buona qualità si occupano di descrivere l’essenza della necessità, non i relativi dettagli. Con il passare del tempo, la relativa card può arricchirsi di appunti, idee, e così via. Tuttavia, questi dettagli non sono necessari per definire priorità o pianificarne l’implementazione. Realizzare storie negoziabili è un elemento cardine della scrittura delle user story in quanto fa sì che la definizione dei dettagli possa essere posticipata. In questo modo il Product Owner e il team di sviluppo possono concentrarsi sulle necessità più immediate, rimandando le altre all’inizio attuazione. Ovviamente, si tratta di un approccio che tuttavia può avere dei rischi, per esempio di posticipare l’implementazione di un elemento di fondamentale importanza che richiede la rivisitazione dell’intera architettura e/o delle scelte tecnologiche. Spesso elementi killer sono nascosti in alcuni dettagli ritenuti inizialmente non cruciali. Per questo l’attività di prioritizzazione assume un ruolo fondamentale come parziale mitigazione di questo rischio.

Valuable: “di valore”

Ogni storia deve avere un proprio valore. In linea con i cardini dell’agilità, una storia non deve necessariamente essere “preziosa” per tutti gli stakeholder; lo deve essere però per l’utente. Questo è lo stakeholder principale che deve essere in grado di vedere il valore aggiunto di ogni storia.

Non è infrequente il caso in cui il team di sviluppo abbia delle preoccupazioni o approcci di tipo “divide et impera”. In questo caso è necessario che le varie sottoparti siano tradotte in modo tale che l’utente continui a percepirne il valore. Questo accorgimento è particolarmente importante quando una storia viene suddivisa in sotto-storie per via della parte del sistema che essa va a influenzare: per esempio la parte relativa alla GUI, quella relativa alla business logic, quella relativa alla persistenza e così via. Questa naturale propensione del team di sviluppo deve essere organizzata in modo che l’utente riesca a vedere la situazione nel suo complesso e quindi continui a percepirne il valore.

Questo approccio è ritenuto importante come argine alla creazione di user story di tipo infrastrutturale. Processi agili richiedono che la necessaria infrastruttura, per esempio lo schema del database, sia realizzata solo quando strettamente necessaria per risolvere il problema attuale. In sostanza, si differenziano e si oppongono ad approcci architecture driven.

Estimable: “valutabile con una stima”

Una storia utente scritta bene deve poter essere facilmente quantificabile. In questa fase non viene richiesta una stima esatta, ma una di massima necessaria per pianificare la relativa implementazione. La facilità di stima è una caratteristica legata alla comprensione della storia e supporta anche la fase di negoziazione: è ovviamente difficile stimare o negoziare una storia che non si capisce. Inoltre, ha a che fare con la dimensione della storie: storie più estese sono più difficili da stimare. Chiaramente questa caratteristica dipende anche dall’esperienza del team. Nei casi in cui il team non disponga delle necessarie competenze per stimare una storia, i processi agili suggeriscono di procedere con PoC (Proof of Concept) che nel linguaggio agile sono dette “spike“.

Small: “piccola”

Nel contesto delle storie utente, le dimensioni giocano un ruolo importante: in particolare è bene che il lavoro richiesto da una storia sia di dimensioni contenute. Ogni storia dovrebbe richiedere una o due settimane di lavoro. Qualora il lavoro richiesto da una storia ecceda questi limiti, si entra in un contesto in cui è difficile sapere cosa c’è nello scope della storia. Storie dalla portata più contenuta sono più facili da stimare e quindi tendono a essere più precise.

Testable: “verificabile con test”

Storia scritte bene devono essere facilmente testabili: in effetti si tratta di un principio fondamentale dei processi più agili. Scrivere una user story card implica una promessa implicita da parte del team: “sono in grado di capire la specifica esigenza utente sufficientemente bene da poter scrivere il relativo test”. Se un utente non sa come testare una caratteristica, questo può indicare sia che la storia non è abbastanza chiara, sia che non riflette qualcosa di veramente di valore per l’utente. Una sfida interessante consiste nel tramutare requisiti non funzionali, come ad esempio prestazioni e usabilità, in storie da verificare.

Un diverso modello per INVESTire: i casi d’uso

Analizziamo ora se e come la strategia INVEST possa essere applicata anche alla notazione dei casi d’uso. In realtà questa analisi ha una validità esclusivamente conoscitiva visto che si è già appurato che l’approccio delle storie utente e la notazione dei casi d’uso vivono a diversi livelli di astrazione.

Independenti

Questo principio rappresenta una pratica decisamente non ideale nel contesto dei casi d’uso. La sua applicazione porterebbe a scrivere vasti use case omnicomprensivi: use case utilizzati per rappresentare elementi, come la descrizione della GUI per esempio, che invece non dovrebbe essere presente, con un elevato livello di ridondanza (leggasi “copy & paste”). Se da un punto di vista di alto livello (per esempio i famosi Business Use Case) i vari casi d’uso possono (quasi) sempre essere visti come indipendenti gli uni dagli altri, poi, quando si scende nel dettaglio, sia il framework dei requisiti software, sia lo stesso approccio, portano a evidenziare le similarità e quindi le interdipendenze. Dal punto di vista del framework gli use case hanno interdipendenze strutturali con altri modelli, come per esempio il Modello ad Oggetti del Business, le Business Rule, la rappresentazione della GUI, etc. E questo evidentemente porta anche ad un grado di interdipendenza degli stessi use case.

Dal punto di vista poi della modellazione degli stessi, gli use case sono normalmente organizzati in un grafo di elementi collegati tra loro per mezzo delle relazioni previste: Include, Extend e Generalisation. L’idea consiste proprio nell’evidenziare ed estrarre parti comuni e/o atomiche. La logica conseguenza è che si creano delle parti comuni, degli use case indipendenti e altri dipendenti. Ciò, tuttavia, dovrebbe portare a uno sviluppo più rapido e a un piano con parti comuni.

Negoziabili

Gli use case sono negoziabili, ma con modalità e significati diversi rispetto a quanto descritto dalle user story. Nel contesto degli use case, l’utente, a meno di importanti vincoli, può decidere di implementare solo una parte di un caso d’uso, per esempio il main scenario, rimandando l’implementazione delle restanti parti, o addirittura dell’intero use case, a iterazioni/versioni future. L’utente e il Business Analyst devono anche concordare circa il comportamento ottimale richiesto al sistema e possono anche definire use case di tipo tattici/Plan B. Tuttavia, una volta che un use case sia definito, questo rappresenta un contratto formale tra l’utente ed il team di sviluppo. Qualora l’utente decida di cambiare il comportamento sancito da un case d’uso, deve avviare un processo Change Request.

Di valore per l’utente

L’idea alla base dei casi d’uso consiste proprio nel conferire grande importanza all’utente e ai servizi richiesti. E ciò dovrebbe essere chiaro anche ai Business Analyst che li scrivono. Tuttavia, non è infrequente il caso in cui gli use case siano utilizzati per descrivere servizi di tipo strutturale e di minore impatto per lo stesso utente.

Valutabili con una stima

Gli use case dovrebbero risultare più facilmente, o se si preferisce meno difficilmente stimabili. Per loro costruzione gli use case presentano una descrizione dettagliata di ciò che è richiesto al sistema, con un minimo grado di ambiguità. Pertanto, a parte fattori esterni come use case modellati incorrettamente, ambigui, ridotte conoscenze tecnologiche, problmi di fattibilità, e così via, gli use case, con gli altri modelli dei requisiti, dovrebbero fornire molte informazioni necessarie per dar luogo ad una stima abbastanza corretta.

Piccoli

In questo contesto, le dimensioni non si riferiscono allo use case stesso ma alla portata del lavoro richiesto per l’implementazione. Cercare di creare tutta una serie di use case affinchè la relativa implementazione non richieda troppo tempo potrebbe portare ad approcci e risultati sconsigliati, come per esempio la decomposizione funzionale dei casi d’uso, la creazione di un numero elevatissimo di use case e di una rete fittissima di interdipendenze, e così via. Gli use case devono essere chiari, concisi e descrivere completamente il servizio richiesto “utilizzando”, se necessario, altri use cases. Quello che però si può fare, e generalmente si fa, è organizzare l’implementazione di use case complessi suddividendoli in parti, come per esempio Main Scenario, Alternative Scenarios, e così via.

Verificabili con test

Gli use case forniscono un supporto elevatissimo alla fase di test. Infatti, dato uno use case è immediato quasi meccanico implementare il corrispondente caso di test, come mostrato nella seguente figura.

Figura 1 – Dagli use case ai test case.

Inoltre tra gli use case e i relativi test case esiste un’interessante relazione: dall’analisi dei casi d’uso è meccanico generare i corrispondenti test case, e tale generazione equivale, di fatto, ad un debug dei casi d’uso. Se questi sono ben definiti e chiari, allora la generazione dei test case procede speditamente, altrimenti si incorre in tutta una serie di intoppi, ritardi e problemi vari. Gli use case, inoltre, permettono di definire sia test positivi (Main e Alternative Scenario), sia quelli negativi (Error Scenario).  Detto questo, tutto quello specificato per le user story rimane assolutamente valido anche nel caso degli use case.

La qualità dei casi d’uso

La letteratura informatica correntemente disponibile offre molti trattati che forniscono direttive e consigli su come produrre requisiti software di elevata qualità. Uno interessante è il risultato di un lungo progetto denominato CREW [6], finanziato dalla Unione Europea, che ha prodotto un significativo contributo nella definizione di casi d’uso di elevata qualità.

In particolare, è stato prodotto una serie completa di linee guida susseguentemente verificate e convalidate attraverso una serie di studi su progetti reali. Studi successivi, come quelli Cox & Phalp [7] hanno dimostrato che specifiche dei requisiti prodotte seguendo le regole proposte dal progetto CREWS permettono di produrre use case e quindi requisiti di alta qualità. Il tentativo di applicare tali regole alle user story, tuttavia, fallirebbe fin dall’inizio e questo essenzialmente per via del fatto che si passa da un modello a maggiore dettaglio ad uno a più alto livello di astrazione.

User story a confronto con le qualità dei casi d’uso

Allora… proviamo a vedere come si comportano le user story con le qualità dei casi d’uso descritte nel secondo articolo della serie. In particolare, in quella sede avevamo riportato le caratteristiche dei casi d’uso che riportiamo brevemente di seguito

Semplicità ed immediatezza

In merito a semplicità e immediatezza, le user story sono sicuramente ben posizionate.

Elevato supporto per la fase di test

Uno degli elementi qualitativi fondamentali di una user story consiste nell’essere facilmente verificabile. Tuttavia, di per sè, le storie non fornisco un diretto supporto alla definizione dei test, che devono essere definiti in base all’evoluzione della storia stessa, la quale, spesso e volentieri, è definita per mezzo del codice.

Tracciabilità dei requisiti iniziali

Per quanto riguarda la totale tracciabilità sia dei requisiti iniziali sia dei successivi modelli fino al codice, non è esattamente una pratica considerata agile. Certo nulla vieta di cercare di utilizzarla insieme alle user story, tuttavia non è una pratica correntemente utilizzata

Efficienza

User story di buona qualità permettono elevate efficienze: basti menzionare le qualità di indipendenza, di limitate dimensioni e di essere facilmente verificabili. Tutte queste caratteristiche permettono uno sviluppo in parallelo e quindi potenziali efficienze.

Supporto a processi iterativi e incrementali

Per quanto siano generalmente associate al mondo lean/agile, le user story sono nate proprio nel contesto dei processi iterativi e incrementali: supportano pertanto intrinsecamente questi processi di sviluppo del software.

Semplificazione della consultazione dei requisiti

Le user story permettono di produrre requisiti più semplici da consultare e da verificare e validare? Qui si potrebbe aprire un dibattito. Da un certo punto di vista è vero, da un altro tuttavia non lo è. Certo, le user story aiutano a immaginare il sistema in termini di una serie di necessità dell’utente relativamente piccole. Tuttavia, le user story, tipicamente, non portano a una formulazione tradizionale in termini di requisiti funzionale, non funzionale, modello a oggetti business, etc. Quindi, non è detto che permettano di produrre requisiti più semplici da consultare, verificare e validare.

Supporto da parte dei tool

Da qualche anno si assiste a tutto un fiorire di tool commerciali che supportano le user story.

Un elemento di rischio

Come analizzato nell’articolo introduttivo della serie [4], la notazione dei casi d’uso è una componente, molto importante, di un modello dei requisiti più ampio che prevede altri (sotto)modelli come per esempio Business Rules, NFRs, Modello ad Oggetti del Business, modello GUI, etc. In particolare, un buon modello dei requisiti software prevede una stretta integrazione tra le sue varie componenti costituenti.

In termini di casi d’uso questo si traduce in riferimenti alle Business Rules, anche al fine di evitare continui che copy & paste, riferimenti al modello della GUI, onde evitare descrizioni/disegni dell’interfaccia utente embedded, flussi degli eventi completamente compatibili con le entità presenti nel Modello a Oggetti del Business, etc.

In particolare, è fondamentale che il modello dei casi d’uso sia perfettamente sincronizzato con quest’ultimo modello.

Per esempio, supponiamo che il modello a oggetti di un sistema di investimenti sancisca una struttura di un Trade (struttura ripresa dallo standard FPML) come quella riportata di seguito:

In questo caso è strettamente necessario che la modellazione dei servizi che agiscono in qualche misura su un Trade ne rispettino e rinforzino la struttura. Ciò, per esempio, fa sì che un servizio destinato alla costruzione dinamica di un portfolio di Trade (per esempio, select counterparty portfolio) si riferisca esclusivamente dell’intestazione del Trade, TradeHeader, e che quindi la relativa selezione menzioni esplicitamente i relativi attributi. Ancora, fa sì che un servizio di calcolo dell’esposizione del portfolio di una determinata controparte agisca essenzialmente sulla parte economica del Trade, TradeEconomics, citandone esplicitamente gli attributi coinvolti.

Figura 2 – Frammento semplificato di un Trade secondo il modello FPML.

Il modello a oggetti del business come elemento mitigante del rischio

Ora, modelli ad oggetti del business sono tipicamente del tutto assenti in processi molto agili e ciò finisce per generare un rischio spesso importante. Questo perchè, come visto nel primo articolo della serie [4], il Modello a Oggetti del Business è la radice di tutta una componenti fondamentali di un sistema:

• Lo schema del database. Si tratta della rappresentazione fisica delle entità manipolate dal business oggetto di studio.
• L’API del sistema, inclusi eventuali messaggi. I sistemi della stessa area e i singoli processi dell’applicazione oggetto di studio, si scambiano messaggi con incluse entità business o sue parti.
• Il disegno della GUI. L’interfaccia utente mostra i dati delle entità business.
• Il dettaglio dei vari processi. I vari processi e algoritmi agiscono sui dati presenti nelle entità business manipolate nell’area oggetto di studio.
• L’organizzazione del sistema in componenti con le relative interfacce. Se il sistema si occupa di definire il portfolio di trade da analizzare è legittimo attendersi componenti del tipo: PortfolioManager, TradeManager, TradeVO, con interfacce assolutamente riconducibili alle entità business.
• I grafi di oggetti utilizzati per scambiare informazioni tra i vari layer dell’architettura. Si tratta dei vari VO.
• Le strutture dati da implementare.

Il punto centrale è che questo modello ha un impatto cruciale sull’intero ecosistema da implementare/estendere e questo è un dato di fatto. Problemi importanti nella definizione del Modello a Oggetti del Business possono generare danni notevoli o addirittura irreparabili.

Si consideri, per esempio, l’impatto che può avere un errore importante, o semplicemente l’aggiunta di una parte analizzata a posteriori del modello di business sull’architettura del sistema: è necessario modificare tutti i layer dell’architettura a partire dall’interfaccia utente fino al disegno del database. In casi più estremi poi, potrebbe generare danni irreparabili.

Si consideri il caso, non infrequente (soprattutto considerando sviluppi fortemente iterativi), di un sistema messo in produzione che inizia a funzionare, inizia a produrre e memorizzare informazioni sul proprio database e tutto procede tranquillamente. Finchè, dopo qualche mese che il sistema funziona in produzione, ci si rende conto che la struttura era errata o magari alcuni importanti informazioni non sono state acquisite. Nel primo caso è possibile risolvere la situazione con faticose e rischiose procedure di ristrutturazione del database di produzione. Nel secondo caso invece, potrebbe essere semplicemente impossibile recuperare la situazione: i dati persi non sono più recuperabili.

Allora, quale approccio è veramente “agile”? Quello che trascura la realizzazione del Modello ad Oggetti Business per concentrarsi esclusivamente sulle user story e relativa implementazione, dove le strutture dati business emergono come reverse engineering del codice? Oppure un approccio che alle user story abbini anche la definizione del Modello a Oggetti Business?

Le business rules

Le business rules possono essere “catturate” e documentate ricorrendo a diverse soluzioni: documento, pagina Wiki, foglio Excel, database, etc. Nella produzione ed evoluzione delle user story è consigliabile evitare di descrivere le varie business rules all’interno delle stesse. Probabilmente un approccio migliore consiste nel mantenere un manufatto delle business rules e riferirsi ad esso. Ciò rende il processo di generazione dei requisiti software decisamente più agile ed evita sia i classici problemi di copy & paste, sia problemi più seri di mancanza di coerenza.

Cosa rimane alla fine?

Un elemento spesso trascurato è che una buona analisi dei requisiti è un’ottima documentazione: chiaramente non è sempre vero il contrario. Quando si termina un progetto, producendo i modelli fondamentali, come per esempio il modello ad oggetti del business, il modello dei casi d’uso etc., si è prodotto un insieme di informazioni di grandissimo valore.

Certo, alla fine il sistema deve essere consegnato, nel tempo e budget previsto, con le funzionalità stabilite, e questo è il principio indiscutibile per sancire se un progetto ha avuto successo o meno.

Però, modelli dei requisiti corretti e completi rappresentano a loro volta formidabili deliverables… Non a caso, non è infrequente la situazione in cui alcune software houses finiscono anche per vendere tali modelli. Un’analisi dei requisiti di buona qualità sopravvive diverse implementazioni del sistema.

Conclusione

Con questo articolo abbiamo concluso la serie dedicata ai requisiti funzionali e in particolare alle due principali notazioni: use case e user story. Nel corso dell’articolo abbiamo evidenziato ancora una volta come queste due notazioni abbiamo ben poco in comune e operino a due diversi livelli di astrazione. Tanto che le user story, molto probabilmente, presentano maggiori similitudine con le feature.

Una logica conseguenza delle divergenze intrinseche delle due notazioni è che le regole di qualità definite per una notazione mal si adattano all’altra e viceversa. E questo dovrebbe essere lapalissiano.

Per finire, ci siamo soffermati su un rischio che si può generare in un progetto trascurando il modello ad oggetti del business. Si tratta di un modello, realizzato per mezzo della notazione delle classi, che cattura i tipi di oggetto più importanti nel contesto del sistema. Questi oggetti di dominio rappresentano le “cose” che esistono o eventi che traspaiono nell’ambiente in cui il sistema funziona. Pertanto, le classi di questo modello possono emergere nelle loro tre forme tipiche: oggetti di business che rappresentano le cose che sono manipolate dal business stesso, oggetti reali e concetti di cui un sistema ha bisogno di tenere traccia, ed eventi che esistono o trapelano. Non definire tale modello, o magari definirlo attraverso il codice solo quanto la relativa storia lo richiede, può causare problemi di un certo rilievo al progetto: necessità di rivedere completamente l’architettura del sistema con faticose e rischiose procedure di ristrutturazione del database di produzione e, in casi estremi, impossibilità recuperare dati non catturati dalle versioni precedenti.

Allora, quale notazione risulta migliore? L’approccio delle user story o la notazione dei casi d’uso? Sicuramente… la Gazzella.

Riferimenti

[1] Luca Vetti Tagliati, “Use Case vs. User Story – III parte: Uno sguardo a similitudini e differenze”, MokaByte 197, luglio/agosto 2014

https://www.mokabyte.it/cms/article.run?articleId=H68-52J-CNQ-MFK_7f000001_33025293_1faa09fe

[2] Alistair Cockburn, “The new user story is a real story”

http://alistair.cockburn.us/The+new+user+story+is+a+real+story

[3] RUP project template

http://ibm.co/1w15Wcp

[4] Luca Vetti Tagliati, “Use Case vs. User Story – I parte: I requisiti funzionali”, MokaByte 192, febbraio 2014

https://www.mokabyte.it/cms/article.run?articleId=UOP-DOQ-ESE-SHH_7f000001_10364476_11630062

[5] Bill Wake, “INVEST in good Story, and SMART tasks”, XP123, August 2013

http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

[6] CREWS 1998, “Cooperative Requirements Engineering With Scenarios”, 25 agosto 1999

http://sunsite.informatik.rwth-aachen.de/CREWS/reports.htm,

[7] K. Cox – K.T. Phalp, “Replicating the CREWS Use Case Authoring Guidelines Experiment”, Int. J. Empirical Software Engineering, Issue 5 (2000) 245-267