I requisiti scelti per l'iterazione 1 per l'applicazione POS NextGen sono i seguenti:

• Implementare lo scenario di base del caso d'uso Elabora Vendita (Process Sale): inserire gli articoli e ricevere un pagamento in contanti
• Implementare il caso d'uso Avviamento, necessario per gestire le esigenze di inizializzazione per questa iterazione
• Non c'è niente di strano o di complesso da gestire, semplicemente uno scenario di "percorso felice", con la relativa progettazione e implementazione
• Non c'è collaborazione con i servizi esterni, come una base di dati dei prodotti oppure il sistema esterno di contabilità
  Nella prima iterazione dovrebbero anche essere trattate la progettazione e implementazione dell'interfaccia utente di supporto a queste funzionalità, della base di dati, ecc.. ma qui non vengono trattate.

I requisiti scelti per l'iterazione 1 per l'applicazione POS NextGen sono i seguenti:

• Implementare uno scenario di base del caso d'uso Gioca una partita a Monopoly i giocatori si spostano fra le casella del tabellone.
• Implementare un caso d'uso di Avviamento necessario per gestire le esigenze di inizializzazione per questa iterazione.
• Possono giocare da due a otto giocatori.
• Una partita consiste in una serie di giri. Durante un giro, ogni giocatore gioca a turno. In un turno, un giocatore lancia due dadi (a sei facce) e fa avanzare il proprio segnalino lungo il tabellone, in senso orario, di un numero di caselle pari al punteggio ottenuto dalla somma dei due dadi
• Il gioco ha una durata di 20 giri.
• Dopo che sono stati lanciati i dati, vengono utilizzare il nome del giocatore e il punteggio ottenuto. Quando il giocatore si sposta e si ferma su una casella, vengono visualizzati il nome del giocatore e il nome della casella su cui il gioatore si è fermato.
• Nell'iterazione 1 non ci sono soldi, non ci sono vicnitodi o perdenti, nessuna proprietà da acquistare o affitti da pagare e nessuna casella speciale di alcun genere.
• Ogni casella ha un nome. Ogni giocatore inizia il gioco con il proprio segnalino collocato sulla casella dal nome "Go" (Via). I nomi delle caselle saranno Go, Square 1, Square 2, ... Square 39.
• Il gioco viene eseguito come una simulazione che non richiede input dell'utente, tranne l'isnerimetno del numero dei giocatori.

Ecco i requisiti per il Monopoly scelti per questa iterazione, scritti come storie utente:

• Creare tabellone, i dadi e quant'altro serve per lo svolgimento della simulazione di una partita, fra un numero di giocatori compreso tra due e otto.
• Consentire a un giocatore di lanciare i dadi e di muovere di conseguenza il proprio segnalino sul tabellone
• Tutti i giocatori si muovono a turno, per 20 giri
• Visualizzare la traccia di gioco del turno effettuato da un giocatore

Si noti che questi requisiti per l'iterazione 1 sono dei sottoinsiemi dei requisiti o dei casi d'uso completi. Per esempio, i requisiti dell'iterazione 1 per il POS sono solo una versione semplificata del caso d'uso completo Elabora vendita; molti altri non sono stati ancora analizzati.

Questo è fondamentale: si inizia la programmazione e il test per un sottoinsieme dei requisiti e si inizia quello sviluppo prima che l'analisi di tutti i requisiti sia stata completata.

Non tutti i requisiti del caso d'uso Elabora Vendita vengono implementati nell'iterazione 1. Lavorare su diversi scenari dello stesso caso d'uso per più iterazioni è comune, estendendo il sistema in modo graduale per gestire, alla fine, tutte le funzionalità richieste. D'altra parte i casi d'uso semplici e più brevi possono essere completati in una sola iterazione.

Navigazione:

• Come si incastrano Ideazione ed Elaborazione
• Fase di elaborazione
• Pianificare l'iterazione successiva
• Verso l'analisi a oggetti